When using:
```
t-field="res_company.logo" t-options="{'widget': 'image'}"
```
the widget generates a `/web/content/` URL, which ultimately checks the
access rights in method `binary_content`. This means that if the user
doesn't have the `read` access rights on `res_company`, the logo won't
be displayed.
We use the `/logo.png` route instead since it bypasses the access
rights.
opw-1913665
After making improvement to allow user to choose first day of week per
language, it was not taken into account that calendar view uses
different weekdays indexing than newly added field `week_start`. The
difference is in Sunday, where in calendar view it has index 0, but
week_start index is 7 (other days' indexes match).
opw 1916666
closesodoo/odoo#29471
Without this fix, the test does not work at the start of the year, because it is
reliant on a date that is hard-coded on the currency rate demo.
Instead of changing the demo, this commit will make the test stronger by not
depending on it.
PR: #29850
opw-1916935
Before this commit, when a next activity was closed, the message said
that the action was performed by the assigned person.
Now, the message say that the action was performed by the person who
closed the activity.
closesodoo/odoo#29678
Purpose
=======
When changing the leave type on a leave request, reset the technical
fields that only have a visual purpose to avoid mismatch on the leave
duration compute method.
closesodoo/odoo#29789
1/ self.date_from on a for loop on self won't work
2/ When calling get_work_hours_count with self.date_from=False or self.date_to=False,
this will lead to a traceback when looking the timezone on the date.
Closes#29697
We wanted to make it possible to manually mark records from the partner_autocomplete service as 'ignored' so that they wouldn't appear in suggestions.
Previously, this was done by removing, in the service, records that were marked as 'ignored' from returned suggestions.
The problem is that, since the record was not present in odooSuggestions, the data from this company was retrieved from clearbitSuggestions and the company was still present in the dropdown.
We fix this problem by also returning ignored companies from the service, marked as 'ignored', so that they can be filtered out after getting additional suggestions from clearbit.
closesodoo/odoo#29785
The information of the active model and record was not given in the context
Records created from the Manage Messages and Manage Attachements in the debug
menu were not linked to the current records
Add context in test too
closesodoo/odoo#27766
Before this commit, there was a slight chance that the "add to wishlist" button
would flicker `disabled` off, which caused the tour to go next step too early.
The flicker was because the `_onChangeVariant` could be triggered by the
`website_sale` code before the variable `this.wishlistProductIDs` was actually
set, so it wrongly computed the state and enabled the button.
Now the RPC is done on the `willStart` instead of `start` to solve this issue.
The tour has been edited to check the button is actually disabled initially.
The view has been edited because the existing condition was too lazy: it checked
if any variant of the current template was in the wishlist, instead of checking
for the variant actually displayed. That also caused a flicker when the JS
correctly computed the state for the variant afterwards.
The widget has also been edited to trigger `input.product_id` instead of
`input.js_variant_change:checked` to avoid calling `get_combination_info` twice
from `website_sale` code.
PR: #29675
task-1920036
This step was meant to be "check" but did "click" instead because no empty
function was provided.
This caused a nondeterministic issues where an unwanted RPC generated a warning.
Indeed by clicking "add to cart" when checking if the button is disabled, that
called `create_product_variant` on non-dynamic product.
PR: #29675
task-1920036
Some features are common to portal and backend, such as the sign modal in
enterprise.
This commit uniformize the width of the modal to make it more consistent between
the two by default. Of course themes can still customize this behavior.
closesodoo/odoo#29521
The commit a35df8d371 changes the odoo object
of "rules" from stock.location.path to stock.rule. The field on the first
object to store the destination location was location_dest_id but is location_id
in the second one.
This commit fix the variable name that refers to the destination location
opw : 1919655
closesodoo/odoo#29755
Pingen validates the format of documents before sending them. These are the elements that it checks and how when ensure that the constrains are validated:
- The recipient's address should appear in a predefined area
--> Move the address to this area and reduce the font-size if the address is too long
- The destination country should be the last line of the address
--> Sometimes, the Tax ID was in this zone, so we add a margin after the address
- Above the Address Area, there should be a Postage Area that should be completely empty
--> Make the background white to avoid having a background image in this area
--> Crop the header if it takes too much space
- There are margins of 5mm all around the document
--> Crop the footer 5mm above the bottom of the page if it takes too much space
- There is a square in the bottom left of the document that should be empty
--> Add a margin on the left of the footer
closesodoo/odoo#29522
In `test_enable` mode, `render_qweb_pdf` fallbacked to `render_qweb_html`. We add a context key to be able to force the rendering of the pdf, even in `test-enable` mode.
The "customer invoice" and "vendor bill" string was untranslated.
Instead of adding a _ call, properly translate it.
No need to try saving bytes by splitting the sentences, this makes it very
difficult to translate in some languages where the order of words are not the
same as English
closesodoo/odoo#29690
f8dad1bb4 added the terms in the .pot with an incorrect syntax in the comment
The pulled translation have this incorrect syntax as well which produces a warning
closesodoo/odoo#29729
With multi-website, activating a customize option (customize_show view) will
actually duplicate the customize view to make it specific.
By doing so, the duplicated view will have a higher ID than the original, and
the original's siblings customize options.
Before this fix, two issues could be seen:
1. When toggling a customize option, it would appear last in the dropdown
afterward. This is because of the views being sorted by (priority, id)
(if the views have the same priority).
2. When toggling, sometimes the views header would be duplicated. This comes
from the JS code that loop through the returned views and create the DOM
by adding a header when the view inherit_id is different than the previous.
Obviously, as 2 views with the same inherit_id could not be grouped together
now that the specific one has a bigger ID, it will create twice the DOM.
=> Check tests in this commit, they have schemas that will explain it clearly
Note: We don't take priority into account for customize menu view order as it
would create the same problem as (2.)
We could have sorted by (inherit_id, priority, name) to avoid the issue
and give the user possibility to order options in header but it was
decided we dont.
Closes#29347
Before this comit:
The `_views_get()` method would be called recursively for every
`inherit_children_ids`.
At the end of the method, we would get the complete view hierarchy, including
duplicate hierarchies for website specific copies (COW).
Then, the `get_related_views` that is calling `_views_get()` would be overriden
in website module to keep only most specific views.
But this would not be enough as it would leave orphans from other trees:
- Have a base view 'B'
- That has an inherited view 'I'
- That has itself an inherited view 'II'
- Now make the hierarchy specific on a website from 'I'
- And add another inherited view to 'I' on the generic tree
This become:
B
/ \
/ \
I I'
/ \ |
II II2 II'
As explained, filtering duplicates would not be enough as it would correctly
remove 'I' and 'II' from the generic tree but would not remove 'II2'.
At the end, it would return "B", "II2", "I'" and "II'".
Now, we correctly return only "B", "I'" and "II'" by ignoring generic trees
when there is a specific one.
Closes#29347
Before this commit, self.env.ref would always find the generic view loaded from
the assets.
Disabling a customize_show view on a website would not hide completely the
feature as the self.env.ref would retrieve the active generic one and not the
inactive specific one.
Step to reproduce (on one of the module):
- Install website_sale_wishlist
- Disable "Wishlist" on the Customize menu of /shop
- Go to a product page, the wishlist hearth icon is still there
opw-1914576
Closes#29347
In a particular case, `_views_get` was mixing apples and oranges, ir.ui.view
and theme.ir.ui.view.
This was the case if a theme has a theme.ir.ui.view t-calling another
theme.ir.ui.view.
(Only theme's sale bridge cause this issue, eg theme_kea_sale.products)
Then, having that theme installed on a website would make all other website
without that theme to crash when opening the /shop customize menu.
Indeed, the theme.ir.ui.view would have the xml_id theme_kea_sale.search.
The generic view `website_sale.products` would have `theme_kea_sale.products`
as inherit child which is website specific and t-call `theme_kea_sale.search`.
Then, on a website witout theme_kea installed, opening the customize menu would
call `get_related_views` that would call `_views_get` that would loop through
inherit children calling `_view_obj` that would not find a view with that key
and would fallback on self.env.ref, finding the theme.ir.ui.view.
Note: `_views_get` might return specific view for another website but that will
be filtered on `get_related_views` override in website.
Step to reproduce:
- Have at least 2 websites and website_sale installed
- Install theme_kea on a website, it will also install theme_kea_sale
- Go on the website that has not theme_kea installed
- Go to /shop
- Open Customize menu, it won't load because of python crash
opw-1914576
Closes#29347
This reverts commit 5f4a945182.
The cure is worse than the original disease.
The main installation cursor often holds exclusive locks (due to DDL
changes) on vital tables such as res_users. As a result, using
another cursor to perform changes while the main cursor is waiting
is extremely deadlock-prone. And these deadlocks can't be detected by
PostgreSQL as they mix Python-SQL locking, which leads to deadlocked
HTTP workers.
Related to:
- opw-1916918
- #29528
Same as ea747d23e4 for Belgium and Canada
If somebody chose nl instead of nl_BE as the language (e.g. on the SaaS on
odoo.com, only nl is proposed on startup), the chart of account was not
translated.
Now it will be in both languages.
Rename the translation file so it is loaded by any nl_* language
Add multiple spoken_languages to be sure to load each one via the
process_translation mechanism.
Apply same logic for fr_CA
closesodoo/odoo#29682
When there is a website with traduction (for exemple, Spanish and
French). In the Spanish website, at the SEO menu, you can add keywords
using any of the languages (Spanish or French), but these keywords are
only added to the Spanish website.
To avoid misunderstanding between the website language and the keyword
language a tooltip is added.
closesodoo/odoo#29683
Have a one2many display records in a kanban subview,
which opens a form view when edited.
Edit a field displayed only on the form view.
A call to _applyX2ManyChange is done without giving it the viewtype argument,
therefore the fieldinfo is taken from the wrong view, traceback ensues.
opw 1914163
closesodoo/odoo#29607
On a form view of model A, if a many2one field (model B) has a [tree|form]_view_ref in the context
(to display a custom 'Search More...' tree view dialog for example),
when clicking on this field to display the model B form view, the context key *_view_ref is passed
when loading subviews (model C) making them crash because the view ref corresponds to the model B.
After this commit, '*_view_ref' keys in the context are dropped when loading subviews
closesodoo/odoo#29022
This commit has several parts:
- fix ordering of attributes and values
- fix/create python logic (notably for checking the possibility of a combination
and for price computing)
- fix currency
- display correct info on the views without the need of JS (prevent flickering)
- fix various issues with website and SO
- add a lot of tests (both unit and tour)
================================================================================
*** Make consistent the filtering and ordering of product variants ***
Filter & Check possibility
==========================
The first variant shown on the website should always be possible.
When activating the customize "list view of variants", we don't want to show
impossible combination on the list.
We also don't want the user to be able to add to cart an impossible variant.
Show appropriate messages when no combination is possible.
Order
=====
We want the variant order to be consistent with what the user selected with the
sequence fields. The display order on the website should be the same than the
display on the various backend views.
This implies also fixing the order of:
- product.attribute
- product.attribute.value
- product.template.attribute.line
- product.template.attribute.value
The general order is now: (parent,) sequence, id.
Before, it was already a mix of those, but not always in the same order, and not
every key for every model. The name has been removed from the order: either we
sequence them correctly, or we want them in the creation order.
On the website, the first combination shown by the python should be the same as
the one that will be computed by the JS to prevent flickering.
Ideally there should be no RPC at page loading if the python has computed
everything correctly, but it is currently not possible to achieve because the
view logic for website_sale_stock is only in JS.
================================================================================
*** Fix product template and variant price computation ***
Move and improve the get_combination_info method:
- take into account tax included/excluded settings (B2B/B2C)
- take into account pricelist discount policy (striked price)
- fix inconsistencies when price after pricelist would be 0
- use proper rounding and discount compute with the currency helper methods
- fix an issue where context "partner" would have a mix of id and recordset
================================================================================
*** Fix currency conversions ***
The list_price and lst_price of a product are always encoded using the currency
of the product.
The results of "combination info" are always returned using the currency of the
pricelist if given, or the currency of the product.
The prices on an order (line) are encoded with the currency of its pricelist.
================================================================================
*** Fix dynamic variants access rights ***
Public users on the e-commerce should be able to create product variants if the
configuration of the attributes of the product template is set as "dynamic".
This uses "sudo" to bypass create security rules for public users.
Multiple checks are done to ensure that it creates a valid product variant.
================================================================================
*** Miscellaneous bugs, tracebacks and necessary improvements ***
In general:
- correctly show warning when no variant is possible
- don't let user add to cart an impossible variant (from optional product
modal or from any RPC), both in interface and controller logic
- fix as much flickering as possible by correctly pre-computing in python/views
- move business logic from controllers to models
- correctly add no_variant and is_custom values on the SO line description
Sale order:
- fix traceback when emptying the product_id field from configurator
website_sale:
- correctly compute first image / carousel, and correctly swap images when
changing variants, without duplicate image or zoom problems
- don't use list view of variants when it doesn't make sense
- added missing product info when adding a no_variant attribute to cart
- fix cart accessory product computation
website_sale_wishlist:
- fix it with dynamic variants, no_variant and is_custom
website_sale_comparison:
- fix it with dynamic variants (comparison and alternative products)
website_sale_stock:
- fix it in general (some flickering still present)
================================================================================
Authored by @seb-odoo with contribution from @awa-odoo
task-1910821
closesodoo/odoo#28079
The product image zoom was computed in the start method, and an "on load" event
was set in some but not all cases.
This commit makes sure the load event is always set, to correctly recompute the
zoom feature when the image is later changed (for example, changing variant).
This is important if the mouse must stay on the element after it has been
clicked. This is the case for the product image zoom, which will be tested in
the following commit.
Activate variant by default with demo data: since we have demo data creating
variants, the database will be more consistent if the option is also activated
by default. It also allows to gain time when making a demo or testing feature
using them on a new database.
Nicolas Martinelli