Before this commit, when having a calendar notification, the buttons to snooze/cancel
This was because the API of the widget notification changed with 07cd24b1ec
The widget "text" has been changed to "message"
After this commit, the buttons are present and work
OPW 1923132
closesodoo/odoo#30946
Before this commit, the website menus were created only on write on an event
After this commit, the menus are created at create time too
OPW 1914343
closesodoo/odoo#30919
data creation is faster when done through a CSV file compared to an XML file. Hence doing it through a CSV
This commit is related to task_id : 1909961.
closesodoo/odoo#28909
data creation is faster when done through a CSV file compared to an XML file. Hence doing it through a CSV
This commit is related to task_id : 1909961.
closesodoo/odoo#28902
data creation is faster when done through a CSV file compared to an XML file. Hence doing it through a CSV
This commit is related to task_id : 1909961.
closesodoo/odoo#28901
data creation is faster when done through a CSV file compared to an XML file. Hence doing it through a CSV
This commit is related to task_id : 1909961.
closesodoo/odoo#28899
data creation is faster when done through a CSV file compared to an XML file. Hence doing it through a CSV
This commit is related to task_id : 1909961.
closesodoo/odoo#28898
data creation is faster when done through a CSV file compared to an XML file. Hence doing it through a CSV
This commit is related to task_id : 1909961.
closesodoo/odoo#28897
data creation is faster when done through a CSV file compared to an XML file. Hence doing it through a CSV
This commit is related to task_id : 1909961.
closesodoo/odoo#28896
data creation is faster when done through a CSV file compared to an XML file. Hence doing it through a CSV
This commit is related to task_id : 1909961.
closesodoo/odoo#28894
data creation is faster when done through a CSV file compared to an XML file. Hence doing it through a CSV
This commit is related to task_id : 1909961.
closesodoo/odoo#28893
data creation is faster when done through a CSV file compared to an XML file. Hence doing it through a CSV
This commit is related to task_id : 1909961.
closesodoo/odoo#28892
data creation is faster when done through a CSV file compared to an XML file. Hence doing it through a CSV
This commit is related to task_id : 1909961.
closesodoo/odoo#28890
data creation is faster when done through a CSV file compared to an XML file. Hence doing it through a CSV
This commit is related to task_id : 1909961.
closesodoo/odoo#28889
purpose of this task:
Create all account.account.template from csv file.
after this commit:
all account.account.template of country 'Belgium' will be created from csv file, instead of xml.
This commit is related to task_id : 1909961.
closesodoo/odoo#28879
- data creation is faster when done through a CSV file than an XML file, hence doing it through a CSV
- also, created account_tax_template_data.xml file and moved account.account.tag and account.tax.template data in that file from l10n_syscohada_chart_data.xml file
was task# 1909961
closesodoo/odoo#28875
data creation is faster when done through a CSV file compared to an XML file. Hence doing it through a CSV
This commit is related to task_id : 1909961.
closesodoo/odoo#28871
The onchange on serial number aims to track any duplicates. The issue
comes from the fact that `.mapped()` removes the duplicates when it
returns a recordset. We use a list comprehension instead.
Opw : 1910963
closesodoo/odoo#30913
Before this commit, when creating a partner automatically when creating
a message with a template, the company on the partner was wrongly set
After this commit, we try to retrieve the company from the model on the template
OPW 1934392
closesodoo/odoo#30893
Make a return on a pos_order. A new pos_order is created.
On the latter, remove a pos_orde_line.
Before this commit, there was a traceback, due to a KeyError
It was introduced by 5f6a491265
which intended to optimize migration process
We keep the logic of that commit here, in a new helper method
while restoring the original onchange,
since it wasn't compliant with onchange specs
OPW 1934129
closesodoo/odoo#30897
- When merging leads that creates a partner, an error could be thrown
due to the `res.partner` `default_get` method that reads values from the
lead that creates the partner.
The issue is due to the fact that the `crm.lead` record is merged (and
unlinked), trying to read it will cause an error since the records
doesn't exists anymore.
This fix checks that the `crm.lead` we are trying to read from exists.
closesodoo/odoo#30895
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
Lucas Perais (lpe)