1. Product A - on stock 5 pcs.
2. SO - 7 pcs. of A
3. Generated picking has reserved 5 pcs.
4. Increase stock to 7 pcs. (Update qty on Hand)
5. Run procurement scheduler
6. Picking still has reserved 5 pcs.
The scheduler should take into account the moves partially available.
Fixes#27874
opw-1895622
closesodoo/odoo#28136
The utility function xml_to_json, which is mainly used by the views to
parse their arch (from string to xml tree) had a peculiar behaviour: it
tried to process some attributes as json. If by chance, these
attributes are valid json, then they are replaced by their parsed value.
It is difficult to say why it could be useful. Maybe this was done to
prevent using pyeval many times later on. But if that is the case, it
should be done by the view code and not the utility function (the view
can precompute all attributes once).
Also, this behaviour is annoying for code later in the chain, which
needs to check if what it gets is an object or a string. With this
change, attributes are always returned as string (at this point).
closesodoo/odoo#28133
In a multi-currency company, the delivery price of a quotation was
wrongly converted when the currency used by the pricelist was not
the same as the currency used by the company.
This PR correct that behavior by correcly compute the delivery
price according to the pricelist currency.
To reproduce:
1) Install the accounting, sales and delivery modules
2) Set the company as a multi-currency company in the accounting
settings
3) Change the currency rate so the one used by the company is 1
and the other one (the one that will be used on the pricelist)
is anything else than 1
4) Create a pricelist with that other currency
5) Create a quotation using the new pricelist, select a deliver
6) Click "Set Price", the delivery price shown on the form isn't
the same as the price on the quotation.
opw-1894422
Use case to reproduce:
- create a BoM of 50 finished products:
- Add a routing with an operation time of 1h
- Set a 1$/h cost on workcenter
- Set unit price from BoM
It will be 1$ for one product. It should be 0.02$
since it will take 1h for 50 products, so the price
should be 1/50
It happens because the system add the operation time by unit instead
of adding it only once.
related to commit 17b6256955
opw-1890005
Adds 3 smart buttons with count to see :
- Groups
- Access Controls
- Record Rules
Buttons available in debug mode only
Every user that have access to user form has at least admin / Settings or Admin / Access rights.
Admin / Settings includes Admin / Access Rights
Create and delete are not allowed for those views.
Indeed users may think they are modifying current user's access
whereas they are modifying the whole group access.
To avoid confusion, the user's access rights list is now not editable.
Clicking on a row redirects to form view that can be edited.
A warning has been added on access rights form to be sure the user
is aware of what he is doing.
Task ID : 1830142
Closes PR #25587
Co-authored-by: David Beguin <dbe@odoo.com>
Co-authored-by: FMDL <florent.mirieu@gmail.com>
Before this commit:
If an user has multiple session on a database (eg: he is connected both on his
smartphone and his laptop on the ecommerce), and there is a cart in these
session, confirming the cart on one of the session will make other sessions
unable to use the checkout anymore.
This is because other sessions will still contains the Sale Order that is now
'sent' and updating the cart will raise an error:
`It is forbidden to modify a sales order which is not in draft status.`
Now:
If the SO to be updated is not in `draft` anymore, we create a new one.
Step to reproduce:
- Login on ecommerce from device A
- Add product in cart, the SO will be added on session
- Login on ecommerce from device B
- Pay the cart (it will retrieve the SO from device A)
- At that point, the cart is paid and the SO is removed from session on
device B but other devices won't be able to use the checkout anymore
as they still have the SO in session which is in `sent` state.
Thus, any action on cart will raise the error
Note:
1. We can't implement that behavior in `sale_get_order()` as it is supposed to
return SO in `sent` state after checkout.
2. We can't implement that behavior in `_cart_update()` as it is inherited in
some module. Thus, implementing that behavior in `cart_update()` would change
`self = order` but inherited methods would still have initial `self`.
3. Implementing the behavior in the controller it is already done (differently)
in `cart_update_json()`.
Fixes#27508, closes#27794
Spamming the save button when creating a new custommer in point-
of-sale create duplicate users. This PR disable the button once
clicked and re-enable it when all the processing is done.
opw-1895302
close#23919
This commit adds a compatibility file which can be added on demand by
enabling its associated view. This will basically map old BS3 classes
and structures to the related style with BS4.
closesodoo/odoo#27981
For some unknown reasons, the text-primary class was added on each
card-header of that snippet... while the default link color is already
primary by default.
This was however breaking some themes whose primary color would not fit
in card-header while the link color (different from the primary one)
would.
closesodoo/odoo#28627
Let's consider a customer C with payment terms P1 set on it
Steps to reproduce the bug:
- Create a SO for C with payment terms P2
- Confirm the SO and generate the invoice
Bug:
The payment terms on the invoice was P1 instead of P2
This fix allows to keep the same behavior as in 11.0
Introduced by: f1b2d165fb
opw:1905710
closesodoo/odoo#28585
The new product configurator introduces the possibility to create
variants dynamically. One of the main goal is to be able to create
product templates with **many** attributes and values, but not generate
all variants automatically. Only the necessary variants are created
on-the-fly.
However, it turns out that **many** dynamic attributes and values still
fails. For example, create a product with 10 attributes, 10 values for
each. This allows 10^10 theoretical combinations; although the variants
are not created, the creation of the product template fails.
The reason is that the `variant_matrix` contains the list of all
combinations, which causes a `MemoryError`.
An easy modification to improve the process is to keep an iterator
instead of generating the list. This avoids the `MemoryError`, but it
remains necessary to go through all combinations three times, which
would take too much time.
Therefore, some refactoring is necessary in order to keep the same
logic, but avoid going through any huge list. Here are the improvements:
1. Skip the creation part if nothing will be created.
If any attribute is dynamic, no variant is created. Therefore, we can
perform the check upfront and skip the variant creation part if
possible.
2. Stop the creation loop as soon as possible.
There is an hardcoded limit of maximum 1000 variants to create. We
can perform this check along with the list creation instead of
checking at the end.
3. Determine if a product has valid attributes in a different way.
The existing logic is safe but expensive: we check that all attribute
values of a product are part of the possible combinations. This can
be simplified by checking if (1) all attribute values of a variant
are part of the accepted attribute values of the template and (2) a
variant uses all attributes of the template. The second check is
mandatory to delete existing variants when an attribute is added to
the template.
Thanks to these modifications, we at worst go through 1000 possible
attribute values combinations. It might still be possible to optimize
step 3 with a fancy SQL query which would retrieve all (in)valid
products at once. Hopefully this won't be necessary and the optimized
logic will be enough.
opw-1902392
closesodoo/odoo#28530
This optimizes the confirmation of a sale_order in the ecommerce by ~73%,
for a cart with 160 unique items, the processing time goes from
7m46s to 39s, which is roughly the same amount of processing time if the
module `sale_coupon` is not installed.
This optimization is achieved in two steps:
1. By validating promotional/discounted products in batch instead of
validating each product one at a time.
2. By performing an unlink() on invalid reward lines instead of sending
a delete command by writing to the one2many, as delete commands are not
(yet) performed in batch, which means record recomputation after every
delete.
opw-1893277
closesodoo/enterprise#2905
For the special case of is_blacklisted, and due to
the size of the tablers to handle, it's faster to
filter some records rather than searching the whole
res.partner table
closesodoo/odoo#28028
Compatibility: rebuilding a correct modal from user database content.
Since the first version, the modal is saved in databases directly but
has never used a correct structure. While it was working with BS3, it is
not with BS4. This was breaking the design and prevented the modal to
be able to close.
task-1889341
closesodoo/odoo#28589
When opening the customize menu as soon as the page became visible, an
RPC crashed and the toggable options did not appear anymore. This
happened:
1) DOM is ready.
2) The user click on the menu.
3) At the same time, the customize menu is initialized (`attachTo`),
its event handlers are bound and the async `willStart` method is
called.
4) The event handler for the user click is called... and crashes as
requires a variable which would have been set in the `start` method.
The bug did not appear in previous versions as the handler was not using
the standard system and bound the event handler "by hand" in the `start`
method.
Maybe `attachTo` should not bind event handlers before the `willStart`
method is completed; this would be a subject for the master branch. This
commit solves the problem by setting the required variable in the
`willStart` method instead of the `start` method.
closesodoo/odoo#28578
In a multiple company account, when a parter is doesn't have a
company, the mails he revieved have "Send by using odoo" as footer.
This PR correct that by setting the footer to "Send using odoo" when
there is no company.
opw-1894825
In a multiple company account, when creating an event without
company, the emails sent contain "Send by False" as footer, this
PR correct that by disabling the footer in case there is no company
opw-1894825
On res.config.settings for website, when removing a language from language_ids, if this language is defined as default_lang_id, the default language will be updated by an onchange to prevent any inconsistency.
The same should happen when doing this directly on the form view of a website record.
closesodoo/odoo#27727
Until v12, doing this is wrong. The currency_id field of account.journal should only be used if the journal is in a different currency. Otherwise, this field should stay empty.
//NOTE FOR FORWARD-PORT: this commit should not be ported to 12.0 and further.
xmo-odoo