Before this commit, the nav-tabs IDs/urls/... were the same when that
snippet was added multiple times or duplicated. Now, the IDs are
recomputed everytime a new .nav-tabs appears.
This commit hides some labels depending of the avalaible size
of the graph.
We had to skip some test because 'renderEnd' is not triggered
for line chart. We need to update nv.d3.
As building a custom filter on 'Blacklist is false' is creating a filter '!= True'
instead of '= False', the assumption that operator must always be '=' is wrong.
This commit inverts the value and operator if the operator is '!='.
Fix for Task ID 33224
PR #27334
- Create the following products in FIFO costing method and real-time
valuation:
Prod Final (F); Invoiced on Delivered Quantity
Prod Comp1 (C1); Cost = 20
Prod Comp2 (C2); Cost = 10
- Create the BOM Kit for F:
2 Unit(s) of C1
1 Unit(s) of C2
- Create a SO for 3 Unit(s) of F
- Validate SO and picking
- Create the invoice and validate
The price unit taken into account for F in the anglo-saxon accounting
entry is:
20 + 10 = 30
=> entry in Stock Output Account is 3 * 30 = 90
while it should be:
(2 * 20) + (1 * 10) = 50
=> entry in Stock Output Account is 3 * 50 = 150
This should finally fix issues corrected with:
9a7ed7c: price unit multiplied by the qty sold (*)
f1fdb97: price unit taking into account only 1 unit of each
component
(*) In the use case solved, the price unit was:
(6 * 20) + (3 * 10) = 150
=> entry in Stock Output Account is 3 * 150 = 450
opw:1886216
Targets commit d3530eb
Purpose
=======
[Follow up AL review]
Removed the default_get override in the sale_order_line model.
- The default values to create records are now specified by pefixing them with "default_" in the JS.
That will use the built-in framework method, which is more simple/clean.
- The "list_editable_renderer.js" file for the product configurator was removed and its content is now merged within
the SectionAndNoteListRenderer.
Updated fields:
- [sale_order_line in sale/sale.py] "product_no_variant_attribute_values" to "product_no_variant_attribute_value_ids"
[Follow up JCR testing]
Various bug fixes including:
- optional products dont show when they have variants configured on them
- when no variant is created, you cant choose the product one first time in the ecommerce
- when in debug, attribute and attribute value menu is double
- fix design of default picture in cart summary / product comparison
- fix missing href tag on product comparison "add to cart" buttons
- fix button "Configure Variants" is always shown even if there are no variants
Targets commit d3530eb07e
Purpose
=======
[Follow up JCR testing]
Various bug fixes including:
- optional products dont show when they have variants configured on them
- when no variant is created, you cant choose the product one first time in the ecommerce
- when in debug, attribute and attribute value menu is double
- fix design of default picture in cart summary / product comparison
- fix missing href tag on product comparison "add to cart" buttons
- products with the "Can be sold" box unchecked should not appear in the product configurator
Targets commit d3530eb07e
Purpose
=======
[Follow up AL review]
Removed the default_get override in the sale_order_line model.
- The default values to create records are now specified by pefixing them with "default_" in the JS.
That will use the built-in framework method, which is more simple/clean.
- The "list_editable_renderer.js" file for the product configurator was removed and its content is now merged within
the SectionAndNoteListRenderer.
Updated fields:
- [sale_order_line in sale/sale.py] "product_no_variant_attribute_values" to "product_no_variant_attribute_value_ids"
* web_editor, website
Add an opacity slider and an opacity input to control opacity over
the chosen color.
task-1887571
Closes https://github.com/odoo/odoo/pull/27289
Install base_vat_autocomplete and base_address_extended.
Try to create a contact with VAT: BE0477472701 (or any valid one)
Before this commit, there was a traceback because the split of the address string into fields
contained a field that is set in base_adress_extended, and not handled by the current module
After this commit, there is no traceback
OPW 1887288
closes#27291
On a form view, click on set defaults, select a value for a field,
then save
Before this commit, there was a traceback because the model on which we apply
the defaults was not found
After this commit, it works as expected
OPW 1887032
OPW 1888715
closes#27148
Before this commit, when using the website editor, modifications were
saved in place in the original view. The view was also marked as non
updatable so that when an user migrates its database, he does not lose
its modifications.
The problem with this system is that users were able to keep their
modifications at the cost of having views which are not up-to-date with
the latest odoo updates.
Now, the views' content which is inside an oe_structure element is saved
in an inheriting view instead of the original view. The original
view is not marked as non updatable anymore.
Note 1: we only consider elements with the 'oe_structure' class which
also have an id containing the 'oe_structure' string.
Note 2: if a non oe_structure but editable content is edited, the
original view is still marked as non updatable (however, with the new
multi-website feature, this may not be necessary as the edited view will
be duplicated to be website-specific... we may want to disable the
behavior in a future update).
Future update will allow to save oe_structure editions in an inherited
view instead of editing the original view in place. The condition is
to have an id on the .oe_structure element which contains the
'oe_structure' string.
* web_editor, website_blog, website_crm_partner_assign, website_links,
website_livechat, website_mail_channel, website_mass_mailing,
website_slides
Calling a model's method thanks to an RPC will now always send the
web_editor context automatically, making sure the method gets the
website_id all the time, removing the need to guess the current website
(now the get_current_website method uses the context website_id if any).
Note: other routes already have the website_id via request.env.context
if they correctly set website=True (this commit also adds website=True
for scss files customization routes).
With this we can test the invoices properlly in other environments where
we do not depend on sale due to the fact of this incorrectly set test we
hade collateral damage in the localizationsfor example (also related to
doesn't have a new created field called correctly in invoice_open and
the method action_date_assign was not called propperly.
With this fix we do not need to make defensive programming in the
localizations in order to allow us to test it properlly.
closesodoo/odoo#27316
Previously, for multi-websites it was decided that:
- creating a new website would not get already existing apps menu (shop,
blog, forum..).
- installing a new app would create the app's menu on existing website
This was decided mostly for technical reason but it is a weird behavior.
This commit saves the installed apps menus in order to copy them on new website
If this default menu got deleted, we ensure a minimalist tree menu for new
website
Note: This also fixes the bug where installing a website_module more than once
(with -i website_module in command line) would create the menu (blog, shop,
forum..) on the first website a second time.
This was because the website.menu.create() overrided in website would
return the last created record in the self loop, thus the last one created
would be the one set to the xml_id (ir.model.data).
This commit closes#27253
Up until now, when we wanted to post a single document, it's base64 blob
was uploaded to the snailmail server to estimate the cost of the
transaction. We now use the 'batch' apporach that will estimate the
price based on 1 page per document.
because of some changes on the FieldText widget to correctly compute the
size of the eidt box, the SmsWidget can no longer extend that widget since
we work with a DIV and not a single TEXTAREA. For the future, we
might change the way FieldText works but since we only need the basic
functions from InputField in this case (no need of resize nor
translations) we chose to extend InputField.
Several quick fixes:
- repair malformed SQL queries and injection problems
- proper token comparisons (consteq)
- better translatable terms (less context-lessplaceholders)
- basic testing of case-(in)sensitivity of blacklist
- safety check for non-implemented cases in search methods for computed
field
More testing and review is needed for case-sensitivity and email
extraction from generic "addressing fields".