Usecase to reproduce:
- Install a database with demo date and mrp or purchase
The buy/manufacture rules have a wrong company for warehouses
in company 'My company, Chicago'
It happens because the warehouse is not specify in the create
values. In this case it creates the rules and set the user current
company as default.
This commit specify the company during the create call.
closesodoo/odoo#28682
This commit allows for not copying the currency_field attribute
of a monetary field when the monetary field is related,
and when the currency_field attribute is not explicit
Before this commit, the currency_field attribute on the related monetary
was set as the one on the distant model
After this commit, the currency_field attribute takes the field on the
current model
Though the test may appear like an incoherent use case,
it is on the contrary totally legit, as web_studio allows it
OPW 1903113
closesodoo/odoo#28144
This is related to revision
71f188082f
This is nice to have a meaningful explanation
for the user to understand why his mail is not sent,
this is better to not interrupt the mail queue when doing so.
Because of the above revision,
when the mail queue iterated on a mail failing because
of an ASCII encoding issue,
the mail queue was interrupted,
and on the next cron call it failed again and again
on the same mail, therefore leading to the mail queue
to never be processed.
Fixes#27804
If a recipient has a formatted email address like 'A <a@b.com>', the returned
opt_out list must contain normalized email ('a@b.com') in order to be comparable
during the get_mail_values of the mail.compose.message.
Otherwize, It won't match.
Task ID : 1909314
Closes PR #28667
* web_editor
- Restore the preservation of Odoo text-muted color (the rule became
!important with BS4 and had thus to become !important in the
preservation mixin).
- Preserve base design in the "new content" menu (which now uses
text-muted). Indeed, in some themes, the "new content" links were not
even visible anymore.
closesodoo/odoo#28666
Before this commit, when the user is in a form view (edit mode) and
click on a stat button, a new action is added to the action stack. When
the user then comes back to the form view by clicking on the breadcrumb,
it is supposed to be in readonly mode. Before this commit, this was not
the case.
This bug comes from the action manager refactoring, which removed the
view manager. With this commit, we add a new action lifecycle method
which is called when the action is restored.
Note that this commit implicitely changes the semantic of actions with
'target=inline'. As far as I can tell, this only applies to the settings
form view, which can easily be fixed by overriding the restore hook.
closesodoo/odoo#28663
The use of the `deploy` command always fails because of an incorrect
CSRF token since commit 9bae56acd4. Indeed, the latter
re-introduces the session rotation, i.e. the session ID is changed at
authentication.
Practically, what happens server-side is:
- authentication
- generate CSRF token
- create the response with the token and a change of session ID
At this point, the token generated is not correct anymore since it is
based on the 'old' session ID. Therefore, when it is reused at
uploading, an error is raised.
It is actually possible to simplify the process by performing the
authentication and the file upload in a single request. There is indeed
no real use of extracting the authentication, since the request is then
only used to upload the module.
opw-1902863
closesodoo/odoo#28653
This commit fixes two tests that became meaningless after tweaks
in production code:
- form_tests: use two char fields, as integer fields can't be
unset since rev. c62a4edcb
- pivot_tests: the button is disabled since rev. 4f4f111, but
simulating a click with jQuery bypasses the disabled attribute
This commit also removes unecessary overrides of mockRPC. Those
overrides existed because the attachments part of the sidebar
used to make a search_read RPC, but this has been removed at rev.
1dbb555.
closesodoo/odoo#28650
Usecase to reproduce:
- Create a product with a vendor and mto/buy route checked.
- Create 2 SO and confirm them
The system generated 2 RDF instead of a single with 2po lines (same than
v11). It happens because the propagation option of buy rules is
leave empty in v11 and Propagate in v12. It was unintentionally removed
by commit 1e160dffd3
This commit set leave empty as default value for buy rules.
opw-1904165
closesodoo/odoo#28637
In some case, this view was used to perform a search of product.product.
Before, this modificiation all the search view had the same priority
which means that depending on some situation, the wrong search view was
loaded.
opw-1903611
closesodoo/odoo#28634
The uom unit of a product on a sale order line was not with the product uom.
As a result, an error would be triggered when trying to edit the SO, without the
possibility to fix it (as the field is not in the view).
Odoo takes a stand against incorrect demo data.
opw 1906315
closesodoo/odoo#28641
Steps to reproduce the bug:
- Go to Website > Dashboard > Analytics and click on "Link my analytics account"
- Enter some data and save
Bug:
A traceback was raised: TypeError: website_set_ga_data() missing 1 required
positional argument: 'website_id'
opw:1905874
closesodoo/odoo#28636
Because the JS cannot handle 1 or 0 being equivalent to true or false, the views should comply
Issues specifically arise in the kanban view when, instead of reloading every record with python,
the JS actually computes which record should be displayed by reinterpreting the domain
From a user point of view, on a fresh db with CRM installed, go to the app kanban view
Click on the contextual menu of the CRM kanban label, click uninstall
The modal opens, but click cancel. The kanban label of the kanban view has disappeared
This is due to commit 33ba61bfdb, which prevents reloading all the view
for performance purposes
This commit prevents the label from disappearing
OPW 1903534
closesodoo/odoo#28484
This fixes two issues relating to previews in the systray messaging menu
that are not linked to any document:
1. Clicking on such preview now redirects to Inbox
There was a traceback, because it was attempting to open a document.
2. Marking a read one of those previews now only marks this preview
It was marking all previews not linked to a document as read.
Task-ID 1891350
Task-ID 1907159
closesodoo/odoo#28462
Inspired from this commit: 90219a7e0a
It's not possible to modify the shipping area description on a product in
the e-commorce.
opw:1908308
closesodoo/odoo#28624
When the qunit tests runs they are expecting the new line to be the character 10,
but in windows the new line is 10+13.
The test has been updated to ignore the character 13.
closesodoo/odoo#28599
Before this commit, when there was several previews
on the messaging menu that were not linked to any
document, marking one of them as read had the unintended
behaviour to mark all of them as read.
Steps to reproduce:
- Admin with notification management as 'Handle with Odoo'
- Demo assign Admin to two different tasks
- Admin mark one preview as read
> Both previews notifying assignment to a task have been
marked as read
This is caused by the fact that messages of those previews
are not related to any document. As a result, when marking
one preview as read, it maps related messages to mark as
read, which was taking into account all messages that are
not related to any document.
With this commit, previews now tracks message IDs, so that
marking one preview as read only mark the related messages
as read.
Task-ID 1907159
Before this commit, when the user clicked on a preview in the systray
messaging menu that is not linked to any document, there was a
traceback.
Steps to reproduce:
- Admin sets notification management to "Handle with Odoo"
- Demo user assigns Admin to a task
- Admin clicks on preview from being assigned to a task
Those are previews from notifications received from the inbox,
which are not related to any document. It attempts to open a
document that does not exists (i.e. no model/id).
With this commit, when such a preview is not linked to any
document, it now opens Discuss with Inbox.
Task-ID 1891350
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
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
Before this commit, RTL on frontend was only enabled for connected user.
To have RTL, we add the direction on the element, and the RTL version of
the stylesheet for the applicable languages are generated thanks to rtlcss.
opw-1892757
closes#28434
Odoo 12.0 does *not* officially support any python version below 3.5,
but no effort had been made to gracefully announce this to the end user
if they were to run Odoo in an unsupported python version.
This is done because Odoo 12.0 uses py3-only constructs which can
and will raise different errors if ran in python 2.
With this patch, Odoo will display an appropriate error message and won't
launch at all unless it is being run with python 3.5 or greater.
closesodoo/odoo#28502
Suppose you are editing a SO to add a new line. Depending on the configuration,
a sale order line wizard may open (e.g. if packages are activated).
This wizard is a form view, opened from the tree view of the sale order lines.
We have commit 8e5156938a
that adds extra fields from the originating view.
(However it doesn't work if the other view is inlined, so we modify this part to
add the extra field even in this case.)
Then we need the field info from the origin view in the target view;
we do so by extending the former with the content of the latter.
opw 1904337
closesodoo/odoo#28441
Stock moves show a detailed operations icon if the tracking, locations, or
consignment allow to be configured.
However it did so on a per move basis, only displaying it if the considered move
has some of these features.
This fix makes it that the "detailed operations" icon is always displayed if at
least one group of group_tracking_lot, group_stock_multi_locations, or
group_tracking_owner is active, or the move is tracked,
unless the move picking type already does show detailed operations.
opw 1893106closesodoo/odoo#28072
Create an automated action to create a new activity on update of a record
(e.g. a CRM lead).
At update, many fields recompute may be triggered, triggering as many write.
Thus it would generate many activities.
We simply do nothing if we are in a recompute.
Coauthored by rco
opw 1904156
closesodoo/odoo#28498
c5dc0b2f39 disabled send button on composer sent.
But this is only needed for chatter composer, other composers directly
send the message and are not refreshed asynchronously.
So for other composer, the send button worked one time but then was
disabled and the only way to sent was ENTER (on basic composer) or
CTRL+ENTER (on extended composer).
With this fix, disabling the button is done only for chatter composer.
Also the behavior of not clearing the message if there was an error is
introduced back.
Without change in code, added test fails with:
"Should keep unsent message in the composer on failure" (result: "")
"Send button should be re-enabled on message post failure" (result: true)
issue found when checking opw-1904029
closes#28475
- When creating an eCommerce cart using the Public User, the code tries
to access all the sale orders linked to it.
Depending on the count of sale orders linked to the partner, the
loading can take a lot of time.
To avoid this, we only search for the sale orders of connected users
and we only retrieve the last one.
Arnold Moyaux