If model is already an ir.attachment we don't need to do a new search_read.
We can use it record directly.
After this commit, we don't do extra request if we already have the info,
else we don't change the behavior.
task-2211013
The dispatching layer of Odoo (common to any call) can avoid a query on website
if those 3 values are cached.
Note that for complex business flows, there won't be any gain since website
infos will have to be fetched at some point.
About user_id:
In most cases, for a website page you will need to browse the website btw so
we don't remove this request previously. But in case of a simple image, the
controller /web/content need the public user just to set the request.uid in
auth_public but no other info from website.
With this commit, we don't do the 'select * from website where id in()'
request on each controller declared in auth='public' but use the user_id
from the cache. (Invalidated by the write on website_id)
task-2211013
Co-authored-by: Jérémy Kersten <jke@odoo.com>
Co-authored-by: Romain Derie <rde@odoo.com>
Most of the time, the record exists, but we still ensure it does, every single
time, making an SQL query.
Doing a try catch will result in the same behavior, but won't make that query
most of the time.
task-2211013
If we are rendering a page, the menus will most likely be rendered as well.
Note that even in a 403 case when the page is found but is not visible, the
menus will also be shown on the 403 page.
Fetching the menus before accessing the requested page will prefetch that page
as well in one go if that page is in the menus, without any costs for the pages
not in the menus.
There is a tradeoff for 'non-layout' pages, which only occurs in advanced
technical cases:
1. Create a page with specific extension as name suffix (page.css) in which
case the page will be bootstraped accordingly, without call to layout.
2. Remove the call to layout in HTML editor or backend
3. Remove the call to submenus template in HTML editor or backend
For those cases, the menus will be prefetched for no reason.
Note that homepage '/' is rendered through a controller, same logic is applied
there.
task-2211013
Render page flow:
- Search website.page in _serve_page for requested URL
- Check if the page is visible with `is_visible`
- `is_visible` will get the `ir.ui.view` of the page
Note that this is not 'cachable' as being visible depends of now() for the
publishing date
- Render layout which is getting the website menus
Note that this can't be cached either as a menu visibility might also
depends of it's website.page visibility which depends of now()
- Checking menus `is_visible` fetch the menus pages and those pages views.
Before this commit, every level of menu hierarchy would add 2 queries.
This can be avoided by prefetching everything in once during the dispatch if we
know we will render the website menu.
In such a case, read `is_visible` on every website menus will fetch every
pages, views and menus in the lowest SQL queries possible, eg one query for
every table.
For a 3 level menus, requests goes from 20 to 12 to load a untracked page.
task-2211013
- Refactor for easier readability
- Add a test to ensure menu hierarchy scale correctly.
- Add tests for image controllers
- Add test for assets controllers
task-2211013
When creating a website, we:
1. Create the website
2. Bootstrap a homepage
3. Copy the generic menu hierarchy tree for that website
But since we just bootstraped a homepage for the website, the home menu was not
using that page but the generic one from the xml data instead.
That's an issue for tests recently introduced in master that needs the relation
to be correctly set for the query count to work as expected.
task-2211013
# Purpose
**Add tags and category of tags in event and make various improvements in event app**
# Specs
- Add tags that users will be able to filter events with.
- Light design improvements in /event page
- Improve event registration in front-end
# Links
Task ID 2188807
closesodoo/odoo#44690
Related: odoo/upgrade#998
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Before this commit the documentation had quite some samples with 'customer', '=', True. Since in V13 this field on the res.partner model no longer exists we've removed it.
closesodoo/odoo#48453
X-original-commit: 2215d803aa35cdd13ab7f989c807bc7f575aaa8e
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
On event cards of the /event page, the "bubble" with the date would appear
blank in bootswatch theme.
This commit forces the text to be black and therefore visible.
LINKS:
TaskID:2162438
PR: #43856
Before this commit, no location was shown on the event page
if the event was online.
This commit changes that so that it clearly displays that the
event is online.
LINKS:
TaskID:2162438
PR: #43856
Purpose:
Fix a few minor issues with the design and make some light
UX improvments.
Specs:
- In customize menu, show templates should be set as False as templates
are more of a technical thing anyway.
- In location filter, fix the alignment for the "online" option.
- Fix card design in case "show templates" is True and the event is online
- Make the whole event card clickable
LINKS:
TaskID:2162438
PR: #43856
Purpose:
Improve the registration on front-end by allowing the manager
to customize it and display more informations to users about the tickets
and the status of the event.
Specs:
For event manager:
Allow users to decide wether or not they want to unfold/fold
ticket details on their event. The reason behind this is that
some events might have 5+ different tickets and having them unfolded
would bloat the UI quite horribly.
By default, ticket details should be unfolded with no possibility for the end users
to fold it back.
Always display a button for the manager to go configure the event in back-end
For users in general:
Show price range in case the ticket details are folded.
Clearly show the user that a particular ticket is sold out/expired
Cleary show the user that registrations are open/closed/sold out
LINKS:
TaskID:2162438
PR: #43856
Before this commit, _compute_sale_available would only take into account
the dates to set the field sale_available.
This commit makes it take into account the number of available seats
for the ticket as it is wrong to consider a sold out ticket as
being available for sale.
LINKS:
TaskID:2162438
PR: #43856
This commit changes the display name for the model event.type from
"Event Category" to "Event Template"
This change was needed before introducing the new model event.tag.category
which will be used to group tags (event.tag)
This commit introduces two new models: event.tag.category & event.tag
The tags will be grouped by category and will be used to filter events.
In the front-end, if the user activates the "filter by categories", each
event.tag.category will generate a new dropdown of related tags.
Clicking on one of these tags will add a new "tag badge" above the events
(same way as in eLearning).
LINKS:
TaskID:2162438
PR: #43856
Confirms and plans the manufacturing order created for table (MTO) in
demo data to have already a work order.
task-2199747
closesodoo/odoo#46464
Related: odoo/enterprise#8922
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Sets the currency of supplier info (purchase price) in demo data on USD.
The reason is the default company currency is EUR, so the supplier info
created use the company currency by default.
But once account is installed, the company currency is switched for USD.
As multi currency is inactive by default, the user can't see the product
purchase prices aren't in the same currency than all the other prices.
task-1970460
Adds quantities in starting inventory and adds a "Starting Inventory"
for the Chicago Warehouse. The purpose is to avoid to have negative
values in demo data.
Task #1970460
Rename warehouse of compagnies as following:
- YourCompany -> San Francisco
(WH) (WH)
- My Company (Chicago) -> Chicago 1
(MyCo) (CHIC1)
- Chicago Warehouse -> Chicago 2
(Chic) (CHIC2)
Also, can pass a default code through the context when create a new
company to set the `code` value when creating the default warehouse for
the newly created company.
Task #1970460
Before this commit, some tracked product quantities didn't have a SN/LN.
To avoid some issue at the use, it's better all demo data fulfill
requirements like that.
Task #1970460
Demo data product's quantities are no more put in sublocation as by
default, multilocation aren't active.
Also, adapts `test_location_usage` because as we moved quantities from
sublocations to the main stock location, the stock warehouse will have
reserved quantity due to a backorder created by demo data.
In this test, we try to change location as a scrap location, what we
can't do if this location has some reserved quantities.
Task #1970460
<h2>Description of the issue/feature this PR addresses</h2>
Update UX for blacklist management of "mass mailing" and "mass mailing sms" by:
- Making phone and email blacklisting text / UX more consistent
- Making it easier to remove a phone/email from blacklist
- Improve GDPR compliance by adding in a "Reason for unblacklisting" via a wizard for traceability
<h2>Current behavior before PR:</h2>
A blacklisted phone number or email address can only be removed from their respective blacklist by going to the corresponding blacklist view [in mass_mailing_(sms)] and manually archiving the entry. All users could see that an email was blacklisted via an fa-ban icon added next to their corresponding field in the modules: crm, mass_mailing, mass_mailing_sms, and contacts (via extension). Some UI inconsistencies between the Phone Blacklist and Email Blacklist implementation exist.
<h2>Desired behavior after PR is merged:</h2>
Add additional fa-ban icons next to blacklisted phone numbers and make all instances of these icons clickable to remove their corresponding field value from blacklist using a wizard. When submitting a value to be unblacklisted, a "Reason for unblacklisting" is possible to help with GDPR compliance. Additionally use same wizard as a "Unblacklist" button within form view in phone/email blacklists.
Task ID: 2117635
Upgrade PR: https://github.com/odoo/upgrade/pull/939closesodoo/odoo#45315
Related: odoo/upgrade#939
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Previously a blacklisted phone number or email address could only be
removed from their respective blacklist by going to the corresponding
blacklist view [in mass_mailing_(sms)] and manually
archiving/deactiviting the entry. All users could see that an email was
blacklisted via an fa-ban icon added next to their corresponding field
in the modules: crm, mass_mailing, mass_mailing_sms, and contacts (via
extension).
This commit adds additional fa-ban icons next to blacklisted phone
numbers and makes all instances of these icons clickable to remove them
from their corresponding blacklist using a wizard. There are several
limitations to this implementation including:
1. If both a mobile and phone number field appear within a crm lead
instance, then only the mobile field will indicate if it is blacklisted
(due to current implementation of PhoneMixin which only checks 1 phone
value against the blacklist and "sms" which returns mobile numbers first).
I.e. if a phone field value is blacklisted, but a value is typed into the
mobile field, then the phone field will never indicate that it is blacklisted.
2. If someone clicks on a unblacklisting icon after changing the
corresponding field value without clicking off the field input, then the
latest typed in value will be the one submitted for unblacklisting,
which may not actually be blacklisted (due to "is_blacklisted" flag
being a computed field and it not having a chance to re-compute to hide
the button).
3. If someone changes values in the blacklist, then someone who already
has a form open will not see icon disappear until something triggers a
re-compute of the "phone_sanitized_blacklisted" flag (this was already the
case with the icon, but now a user may try to unblacklist a value that is
already unblacklisted.)
4. Since the icon needs to be visible by everyone to indicate whether or
not a phone/email is blacklisted, users without corresponding unblacklist
permissions will be able to click on the icon. When they click on it, they
will be informed they do not have permission to unblacklist. A wizard was
determined to be the best way to implement this unblacklisting for the
following reasons:
- A "Unblacklisting Reason" is needed and will not be stored as a field.
- A field widget is unable to do this due to security settings +
inability to refresh view after unblacklisting with a
"Unblacklisting Reason" without wiping unsaved changes.
Additionally, to better align with GDPR, the corresponding form view for
the phone/email blacklist has been updated to use the same wizard to
track "Reason for unblacklisting". Unfortunately there is no
straightforward way to prevent direct "Archive" action, so users are
still able to bypass unblacklisting without being asked for a "reason
for unblacklisting".
Supports task: 2117635
Upgrade PR: odoo/upgrade#939
COM PR: odoo/odoo#45315
In 13.0, as of 369c20a9 there is some style that will show an event with
bigger font-size and spacing in calendar day view.
In this commit, if an event is short (less than 30 pixels, so less than
45 minutes) we will decrease the spacing to have the same as in week
view and see the event title more easily.
opw-2216654
closes#48391closesodoo/odoo#48409
X-original-commit: a4d170ad9e73d1d63404532b161911df020b5c36
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
After d3ddcc613f l10n_it_edi started to
fail its tests because not adapted, porting the code from the same commit
fix the issue
opw-2214185
closesodoo/odoo#48397
X-original-commit: 33e80333b84d71ae0f61d4ab0e3aa7fdfcdf0f78
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
When user apply half day leave in Leaves, the approver should be able to check
whether it's morning or afternoon on the approval page.
closesodoo/odoo#48429
X-original-commit: 3d3de2bf991bf4a10566599d3bb9011e4c09d21f
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Signed-off-by: Alex Tuyls <alt-odoo@users.noreply.github.com>
Minor UX tweaks for more consistent and correct wording, visualization,
and editing ability for mass_mailing and mass_mailing_sms. Specifically:
- Fix all "This email is blacklisted for mass mailing" => ".. mass
mailings" typos
- Make phone blacklist not editable (to align w/ email blacklist)
- Add "Archived" ribbon to phone and email blacklist
- Update menu items and actions
- "Phone Blacklist" => "Blacklisted Phone Numbers"
- "Blacklist" => "BLacklisted Email Addresses"
Supports task: 2117635
Simply create an SO with more than 1 Qty and deliver. An untaxed amount
is shown on the SO.
Check in Sales > Reporting > Sales > Pivot view, the Untaxed amount
Invoiced and Untaxed amount to invoice Measures. They show the right
amount.
Make a partial return from the original SO and validate.
Reduce the quantity on the sale order line.
The sales report is not updated with the right untaxed amount to
invoice. This occur because when the sale order line have an increased
qty_ordered a chain of event is triggered which included the
recomputation of the untaxed_amount_to_invoice which does not occur on
decrese.
Adding the product_uom_qty to recompute triggers fix the issue
opw-2213996
closesodoo/odoo#48282
X-original-commit: f8a5366ea650c1a2ac4ad3a42da7da4a34758d60
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
This happened:
- The user clicks on a parallax snippet
- For each option, call onFocus then updateUI:
- The BG position is first, so update its UI
- The parallax option is last, onFocus changes the BG position target
... this is broken since the BG position option was updated before the
parallax one was able to change its target. So the BG position was
updated by checking the background type of the snippet instead of its
internal parallax <span/> element.
This was working in 13.0 as changing the target automatically re-updated
the related option UI, now this is left to the dev to update the UI
afterwards or not.
In this case the fix is simple: the onFocus of all options should be
called, before calling the updateUI of all options. This actually
allows to make the code cleaner.
closesodoo/odoo#48428
X-original-commit: 912e849207709b31aa11b7a2bec9ed8dd8b43203
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
It is possible to define required fields from the Authorize.net backend
without which no customer profile can be created. These fields include
data that Odoo sometimes does not have at all (fax number, anyone?);
however including the phone number is a meaningful option.
Before this commit, if the 'phone number' was required by the
Authorize.net configuration and was correctly set in Odoo, this still
did not work because we did not include the phone number with the
customer profile creation request payload.
We do now.
opw-2215332
closesodoo/odoo#48420
X-original-commit: 034c04efa4ccecd40f657eae97ef2b04934d570c
Signed-off-by: Damien Bouvy (dbo) <dbo@odoo.com>
Steps to reproduce the bug:
- Let's consider a product P
- Let's consider that a draft SO has been created for P with analytic account AA
- P can be sold (sale_ok=True) and Re-invoicing policy = 'At cost'
- Untick the option 'Can be sold' on P
- Create an expense E for P with the analytic account AA
- Submit E and try to post the entries
Bug:
A UserError was raised saying that SO with analytic account AA must validated but
P is no more salable.
opw:2217773
closesodoo/odoo#48408
X-original-commit: 3db629cbcde9c4c3bbe2874c18e01dd31abe092d
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
The 'vendor bills' stat button on purchase order, once clicked, will
have a specific behavior depending on the invoice count :
0 : open a new invoice with pre filled fields (not saved yet)
1 : open the form view of the invoice
2+: open the list view of the invoices.
Before this commit, the invoice count was computed with an environment on
the current user. That means a record rule could make the invoice count
lower than the real count and so give an unwanted behavior. Ex: create a
new invoice even if there is already one created because the user cannot
see the other people's invoices.
After this commit, the action_view_invoice with make an explicit read()
in database to fill the cache with all the purchase order's invoices and
make sure the count is the real one.
Task : 2206969
closesodoo/odoo#48274
X-original-commit: e3101d92187946b2bd539e05956e4e83cd9c9097
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
This commit ensure the user have to minimum rights to post invoices
The 'Post' button was already hidden but the post() method is public
Task : 2206969
X-original-commit: 28ae3fb5366d61d3f5f9067cda962b047105199e
Before this patch, the purchase users get an access violation error
at the invoice creation from a purchase order. This was due to
some missing ACL between v12 and v13.
Task : 2206969
X-original-commit: 4c4fb33e4bbc78a85ad309baf5df906cf16566ea
When the value is the same for all records, the write can be done in
batch, this can lead to a "slight" performance improvement, depending on
write overrides, and how the value was computed for each line.
Correction of the position of the buttons when editing bg-image
position with a parallax effect other than "fixed".
task-46147
closesodoo/odoo#48419
X-original-commit: 0919b11c9a78a97345b42bf0fe0f1f9939c2b214
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
- before this commit the product was set to EXP_GEN
but nothing if EXP_GEN is not in db anymore
- now it will pick the first "expensable" product if EXP_GEN doesn't exist.
closesodoo/odoo#47678
X-original-commit: ee35c662768c6f27dff88e9c4597695c17b3b67b
Signed-off-by: Florian Daloze (fda) <fda@odoo.com>
Signed-off-by: Thomas Carlier <Explicitapps@users.noreply.github.com>
Jeremy Kersten