The library moment.js does not support custom date formats anymore.
The following warning is given:
Deprecation warning: value provided is not in a recognized ISO format.
As a result, the moment contains 'Invalid Date',
which would remove possibility to complete a survey containing a date
in any format different than the default.
opw 1930152
closesodoo/odoo#30894
For many2one fields, 'default_get' only returns the id, whereas
'onchange' (like 'read') returns an array with id and display_name.
Before this rev., when creating a new record, we always called
'name_get' for all many2ones, whether or not their value was
obtained by 'default_get' or 'onchange', i.e. even if their
display_name was already known.
It may just look like unnecessary RPCs, but those RPCs could
actually cause a crash when the user has access to the main model
(and thus can access the display_name of the many2one thanks to
related sudo), but doesn't have access to the many2one comodel.
closesodoo/odoo#30892
In the overrides of _name_search we should avoid creating domains with
huge lists of ids as it is inefficient.
We can also make sure that we optimize the empty search as in this case
the custom domain doesn't make sense, we can simply search on an empty
domain and, thanks to the limit argument, still keep a fast query.
Linked to task 1918906
Thanks to @odony and @nseinlet
closesodoo/odoo#30155closesodoo/odoo#30887
Fine-tuning of commit 50217184d2
The selection of the cart recovery mail template would fail if there was more
than one sale order selected.
opw 1921714
closesodoo/odoo#30885
When editing a record, if it cannot be saved (b.e. due to required
fields) and the user clicks on save, then on discard
Before this fix, the window did nothing (seems like it is unresponsive)
After this fix, the user is able to discard the form.
task-id: 1937142
closesodoo/odoo#30871
When the edit mode is entered, some elements receive
data-editor-message attributes. These were not removed on save which
could in some cases make the attributes be saved in the database. For
this to happen it would require an `.oe_structure.oe_empty` element to
be put *inside* an editable element (instead of being the one which is
editable). In that case the `.oe_structure` content would be saved in an
inheriting view but the parent view would also be COW'd for no reason
because of that attribute.
Difficult to say if such a case exist in the current views but as it
technically possible and that some of our tests use that configuration,
it is worth fixing.
Note: this fix was in fact done in the new editor in master and allowed
to detect that one of our test was not testing a feature correctly
because of that. This will be adapted in a different commit of this PR.
closesodoo/odoo#30834
Commit https://github.com/odoo/odoo/commit/29075a8e2c734624cec4f6009185616634f70dea
was written while there was an incorrect behavior related to
multi-website, oe_structure_ID and edit mode in a rare specific case
(see the second commit from this PR for detailed explanation
https://github.com/odoo/odoo/pull/30834).
That rare case was detected in 12.0 since the tour did not work on
master with the new editor (that fixed the incorrect behavior).
Basically, it was COWing the edited view even if only an oe_structure_ID
was touched.
Indeed, when saving a specific view in the HTML editor, we should also
search for its possible new ID as it could change if we also edited its
generic parent. In that case, the view will be copied and then unlinked
to preserve inherit order on the new specific tree.
Previously, it was only possible to make a return in
- the location the move was coming
- a return location that is child of the parent_location, actually
meaning a return location in the warehouse
This commit now allows making return in all return location, even one
located in another warehouses.
closesodoo/odoo#30836
Before this commit, the email aliases on hr.jobs did not take into
account the department.
Hence, when receiving an email for an applicant through an alias,
the object applicant was created in the wrong company
after this commit, the alias is created with the right values, and the
applicant is created in the right company and department
OPW 1920085
closesodoo/odoo#30818
Go on the crm activity view
Have your user operate in another language than en_US
Bafore this commit, the activity types were not translated
This was because the context was not passed to the function
After this commit, the terms are translated
OPW 1924232
closesodoo/odoo#30837
This is a regression from: 10f0766b3. In it the visual side was solved,
but unexpectedly the functional side still worked on unescaped content.
Thus visually a @partnèr could be seen as a link, but it was no anymore
added as follower.
Without change, modified test fails with:
mentioned partners are sent to server (expected: [1], result: [])
note: change is partial backport of 12.2 e2f20ffa9
opw-1931247
closes#30846
- Create a SO with 2 lines of the same product (set route as Drop Ship)
- At validation, both lines are merged into a single line in the PO
As a result, one SO line will be over-delivered, and the other
under-delivered.
Two lines should be kept in the PO.
opw-1928702
closesodoo/odoo#30800
Purpose
=======
A date field not marked as "mandatory" could not be left blank in the survey.
That was caused by the form returning "Invalid date" instead of an
empty value when submitting.
closesodoo/odoo#30788
When creating a leave, we usually check/create activities for the
concerned users, this is fine when creating one leave.
However it starts to become a problem when trying to create leaves in
batch using the by company or by department holiday_type as the number
of leaves created in batch can become quite big.
Now when we create leaves in batch, we do not check for the activities,
which will fasten a lot the creation.
Another problem is that when someone defined a leave on the very day you
want to create such a request, then it will crash, this can lead to
waste of time and resources.
Now we raise an error before trying to create the leaves in case of
conflict.
NB: Tested with +- 320 records, took 20 seconds instead of more than 10 minutes.
Task: 1934383
--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
closesodoo/odoo#30625
When creating a leave, we usually check/create activities for the
concerned users, this is fine when creating one leave.
However it starts to become a problem when trying to create leaves in
batch using the by company or by department holiday_type as the number
of leaves created in batch can become quite big.
Now when we create leaves in batch, we do not check for the activities,
which will fasten a lot the creation.
Another problem is that when someone defined a leave on the very day you
want to create such a request, then it will crash, this can lead to
waste of time and resources.
Now we raise an error before trying to create the leaves in case of
conflict.
Task: 1934383
When uninstalling a module, the messages linked to the records
of that module are not deleted leading to ghost messages when
reinstalling the module.
This is due to the lack of foreign keys in the definition of the
chatter making it impossible to cascade delete.
opw-1928208
closesodoo/odoo#30798
Activate multi-company, deactivate the common contact book.
Create a PO P with user U1 in company A. Switch to company B.
User U2 in company A tries to send P by email.
Rendering of the template fails, because it tries to access object.create_uid,
which breaks multi-company record rules.
We add a sudo in the template so that it works as intended.
opw 1930521
closesodoo/odoo#30789
- Create a product P with:
Costing Method Average Price
Inventory Valuation Perpetual (automated)
- Create a component C with, costing 10.
- Create a BOM for P:
1 Unit of C
- Create a MO for P, validate
=> a journal entry of 10 is created
- Modify the BOM for P:
2 Units of C
- Create a MO for P, validate
=> a journal entry of 15 is created
The journal entry should be 20.
opw-1928342
closesodoo/odoo#30766
The function _compute_parent_rating_percentage_satisfaction used the creation
date of the rating to compute the percentage.
However when a client give a new rating, it updates the old one.
As a result it doesn't give the recent satisfaction percentage,
but the satisfaction percentage of recently created tickets.
In other words recently angry clients from old projects would not appear.
Similarly this method is somewhat reimplemented directly in SQL in the rating
route, which happens to be in the project controller.
opw 1921486
closesodoo/odoo#30752
Priority's star, Kanban State's bullet and name fields should be well aligned
and take less space (specially for small devices).
Related to task 1929034
closesodoo/odoo#28965
Revision on https://github.com/odoo/odoo/commit/0d87b1ccea07b952d9079008cfa3cddaf1ccdbee
The commit above prevents opening a chat window when we do not have
access to messages of the conversation. This may happen when
receiving a notification from a document we do not have access
rights.
However, the changes in the code above has an unintended side-effect
of opening a chat window twice when clicking on a channel preview
from the systray messaging menu.
This happens because when clicking on a preview, it detaches the
thread and opens the chat window. Meanwhile, there is a RPC to
notify that the chat window is detached, and the new window state of
the channel is received on the longpolling. Two concurrent attempts
to open a chat window occur at the same.
It was working fine before the commit above, because the registering
of a newly open chat window was synchronous.
This is however no longer the case, because it fetches messages
beforehand: it has become a requirement to open a chat window. Since
the registering of a newly open chat window is now asynchronous,
it was fetching messages and opening the chat window twice.
This commit fixes the issue by aborting attempt to open a chat
window if it's currently opening a chat window, as this process may
take some time due to the `message_fetch` RPC.
closesodoo/odoo#30741
Before this commit, if the first website in the select was not in your current
company, it raises a traceback.
Now with filter on your own company, and support empty website selected
removing required on related field and using attrs dynamic to make it required
closesodoo/odoo#30769
Open the customers followup report
on a line, click on its contextual menu (the down arrow next to invoice name)
click change expected payment date
Before this commit, there was a traceback, because the new date was a string
which has no strftime function
from 03c40e3104 we learn that it can
either be a string or a date object, as Odoo in v12.0 supports this
After this commit, there is no traceback
OPW 1933953
OPW 1933979
closesodoo/odoo#30756
When we search a partner, there is a system that show partner who match
exactly the searched term with non-alphanumeric character removed.
But since a6e1eb9f0a there is an issue that wrong partner match if:
- they have an empty string as VAT in the database (odd but can happen)
- if the searched term only contains non-alphanumberic characters
eg. i search 'é' -> all partner with empty string vat are found since
the empty search '' matches empty VAT ''
With this changeset, if there is no alphanumeric character we will check
depending on the operator `vat=NULL`, `vat like NULL`, `vat ilike NULL`
that all will not match any result (and in the query plan does not take
time).
opw-1929563
closes#30732
Create a tax of type "group of taxes".
Put taxes in its children_tax_ids field.
Change the type to something else.
The view hides the field children_tax_ids, since it doesn't make sense anymore.
However it doesn't actually remove the children_tax_ids.
As a result the child taxes are use in the computation.
We add on onchange to avoid that unfortunate situation.
opw 1931089
closesodoo/odoo#30727
Through many design refactorings, the community caret position was
broken while the enterprise was not. This commit removes the breaking
rule to put it in enterprise only.
closesodoo/odoo#30799
Nans Lefebvre