Reproduction:
1. Install Sales
2. Go to the quotations
3. Drag the column “name” and change the size
4. Check any sale order in checkbox
5. The column size is reset to default
Reason: the keepColumnWidths parameter isn’t set to True after changing
the size. This happens to all the list views
Fix: we freeze the list after resizing the columns. Remove the extra
keepColumnWidths setting in reordering since it's already set to true
after resizing. Also added tests to check the column size is kept after
toggling the checkboxes
A similar fix is here: https://github.com/odoo/odoo/pull/10902
opw-3113822
closesodoo/odoo#113607
X-original-commit: 30a346a90b633dd73fa823de2cdaf37a0e52c526
Signed-off-by: Julien Mougenot (jum) <jum@odoo.com>
Signed-off-by: Liu Jinjiu (jili) <jili@odoo.com>
Starting from [1], the `_updateColorpicker` method was added on the
"link tools" widget to update colorpickers with the selected link colors
(and it will create the colorpicker for each CSS property on widget
`start`).
Following this update, the code on [2] and [3] added some fixes to
handle the async parts of `_updateColorpicker`. [3] was done very
recently, more than one year later after the introduction of [1]. It
turned a synchronous method into an asynchronous one (rightfully
considering the async calls to `_updateColorpicker` that were inside).
As a fix, this commit will try to re-made it a synchronous method, and
other parts related to `_updateColorpicker` too.
The goal of this commit is to separate the link tools colorpicker
"creation" code (`_addColorPicker` now) from colorpicker's "update"
code. These changes are supposed to fix a race condition issue that
appeared on 16.0, but since the code is the same on 15.0 and subject to
the same issues, we target 15.0 with this fix. Hopefully, this prepares
for an easier refactoring in master.
[1]: https://github.com/odoo/odoo/commit/26d37812f0217ae913c8ddf761bcb26b5c44bff5
[2]: https://github.com/odoo/odoo/pull/78301/commits/6f1a6b76642db2e4f81cf3474ad0ec745a4bb3c9
[3]: https://github.com/odoo/odoo/commit/d15fdca644ef9ed1dfb011d3790f403e0157f55b
runbot-5753
closesodoo/odoo#113510
X-original-commit: 2d4a3efe0d7c9618c388575b4bb652a26913fe68
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Co-authored-by: qsm-odoo <qsm@odoo.com>
This commit intends to add information about the number of slides,
as well as the time needed to finish said slides to the slide sections.
We now also round completion time values up to minute when getting said values
from youtube, google drive or vimeo.
In addition, we add responsible, course and tags options in the search bar.
Task-3054391
closesodoo/odoo#107507
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
If one of the theme was not migrated to the new tx api, still support
the previous notation.
Happened on the design-theme repository
closesodoo/odoo#113571
X-original-commit: a8355ba3dddb5f3c8a8e8e777aff85d558410971
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
A set iteration was creating a random number of queries on some tests.
This was noticed in TestEventPerformance were a random additionnal query
could appear in default_get depending on _get_description and
_get_default_stage_id order.
This commit uses a list to get a deterministic order. It looks like
the set was not useful anyway.
closesodoo/odoo#113563
X-original-commit: 13572df256ccc6351588851d385c381ace155e0d
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
This commit is part of the preliminary work to rewrite the form,
list and kanban model. We want this new Model to only be aware of
field related information it needs (whereas in its current
implementation, the model stores all the information extracted
from the field node in the arch). This would allow to properly
manage multiple occurrences of the same field in views, that is,
each occurrence would be represented by a field component (if
visible of course), and that field component would use the field
information of the arch node it represents. To this end, we want
fields from not using anymore information stored in activeFields
in the record datapoint. Instead, we now call extractProps with
the whole fieldInfo (the information extracted from the arch), s.t.
each field can generate the props it needs from those information
(e.g. sub views for x2manys).
This commit doesn't remove the use of record.activeFields in
concrete fields (this will come later), but reworks the fieldInfo
object generated by parseFieldNode, and provide it to the calls of
extractProps. In fieldInfo, the `options` key is no longer inside
`attrs`, as it is now top-level, alongside several other generic
keys that have been processed (like on_change, modifiers...). For
that reason, a lot of extractProps definitions had to be adapted.
Part of task 3179751
closesodoo/odoo#113092
Related: odoo/enterprise#37266
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
Current behaviour:
When trying the resend a snailmail that had a format error, by
adding a cover we get an error that a record we trying to access is
deleted.
Expected behaviour:
We shouldn't delete the letter that we are trying to resend.
Steps to reproduce:
- Install Invoicing
- Add an IAP account with some credits
- Create a contact with a reallllyyyy long address, to overfill the
fields.
- Create an invoice for that customer, try to print/send a snailmail
- It should fail without a message, then scroll down to the red
paperplane, add the cover and update resend, you get an error
about the missing record.
Reason for the problem:
This legacy code, so maybe in the past it used to work a bit
differently. When trying to resend the letter, we are unlinking it's
attachment (reasons for that are unknown to me), which is linked
with a `Many2One` with letter with a cascading delete, so we end up
deleting the `snailmail_letter` that we are iterating over, then
when trying to write, it throws the error.
Fix:
Remove the link between the attachment and the letter before the deletion
of the `attachment_id`, so the letter is not being deleted.
Affected versions:
- 14.0
- 15.0
- saas-15.2
- 16.0
- saas-16.1
- master
opw-3111774
closesodoo/odoo#113596
X-original-commit: 5cfbfa8e1103081dab89a3114b20edfe9c724c26
Signed-off-by: Piryns Victor (pivi) <pivi@odoo.com>
Using a lazy `?` quantifier lead to poor matching performances and
was not needed technically.
Using `*` instead of `+` lead to a lot of false positives when trying
to write records with an empty value for `data-last-history-steps`.
It is currently unclear how to reach such a case but in the meantime
it is better to allow people to write the record as such rather than
being completely locked with no possibility of saving.
closesodoo/odoo#113540
X-original-commit: 0a370758972e6a0c399471f9982f3898da92ef68
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Co-authored-by: Olivier Dony <odo@openerp.com>
Because the `selectionchange` event is async, the selection can
be null if the node has been removed between the moment the
selection was moved and the moment the event is triggered.
X-original-commit: 3232edb1ccb196c992f75858fe81d08a5af58ab9
Part-of: odoo/odoo#113540
The form view currently reads its data as follows:
1) read the main record, which returns [id1, id2...] for x2manys
and [id, display_name] for many2ones.
2a) read x2manys records, with the context set on the x2many field
node, which returns records like 1)
2b) call name_get for many2ones with option "always_reload" set to
true, with the context set on the many2one field node
3) same as 2), but for records returned by 2a)
The context set on a field node is a string, and needs to be
evaluated (some placeholder values need to be replaced by actual
values), e.g. "{'partner': partner_id}" -> { partner: 4 }.
For 2a and 2b, the context sent is evaluated with the main record
as eval context. For 3, there an additional key "parent" in the
eval context which contains the values of the parent record.
The rationale of this commit is that those data related keys in the
eval context are useless for read-like rpcs.
In the future, the data of the form view will be fetched with a
single rpc, returning the main record and its related records, with
all the values required by the UI. To achieve that, we must ensure
that sub records are never read with a dynamic context depending
on the parent record.
This commit thus directly imposes the limitation, by removing from
the eval context the record related data when it is used to evaluate
the context to send to read-like rpcs.
Part of tasks 3171453 and 3179751
closesodoo/odoo#113527
Signed-off-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
Bug
===
If the Reference field is in a list view, and has a default value, an
error is raised if we create a new record without editing the reference
value. This is because the ORM return a string "model,id" in the
onchange method and this value is wrongly parsed in that case.
Task-2234179
closesodoo/odoo#113392
X-original-commit: b1a35d1b95612bc449b68ed38749d8b3755287ed
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Stéphane Debauche (std) <std@odoo.com>
Before this PR, all this localisation was written in Spanish, but all the localisation have to be written in english and then translated back in the native language. This PR correct that.
closesodoo/odoo#112803
Task-id: 3179209
Signed-off-by: Nicolas Viseur (vin) <vin@odoo.com>
Before this commit, the name and report name of document type for latam localization had been added in each latam localization. Since they depend on l10n_latam, we decided it would be better to just add translate=True to already existing field (name and report_name) instead of adding new field in those module. This commit corrects that.
Task-id: 3179209
Part-of: odoo/odoo#112803
As the tour `shop_editor` is very small, it finishes before the editor
itself is fully loaded.
As a consequence, some threads are remaining on the server side and can
lead to a complete failure of the test.
This seems to particularly affects builds on Bookwork with werkzeug
2.2.2 and python 3.11 as it leads to werkzeug requests timeout.
With this commit, a step is added at the beginning of the test to ensure
that the editor is loaded before beginning the test by itself.
closesodoo/odoo#112698
Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
Rework of the hr.expense workflow so that:
- expenses paid by employee generate purchase.order
- expenses paid by company generate entry that look like payments
Main reason being that purchase.receipt are not active by default.
That makes the entry hard to find, holes in sequences, inconsitency
with payment states.
It also remove the refusal of expenses as this was dead / inaccessible code, only reports can be refused.
task-id: 3126550
[community](https://github.com/odoo/odoo/pull/110518)
[enterprise](https://github.com/odoo/enterprise/pull/36090)
closesodoo/odoo#110518
Related: odoo/upgrade#4266
Related: odoo/enterprise#36090
Signed-off-by: Laurent Smet <las@odoo.com>
Steps to reproduce:
- Make sure language preference is 'en_US'
- In accounting, in the dashboard click on bills
- Filter 'due_date' by week
Issue: The start day is Monday and should be, for 'en_US', Sunday as it
is the case in the dashboard view in accounting (see appendix).
Cause: The query uses the `date_trunc('week', date)` which in Postgres
retrieves the first day of the week as Monday (ISO week).
Solution: Create an offset in the query depending on the first day of
the locale variable.
Note: the `web/tests/test_read_progress_bar.py` has been modified: since
the default language is 'en_US' there will be an offset of one day. To
make it less confusing, I used only two anglo-saxons countries so the
day offset is not the variable tested. (for this matter, pleaser refer
to `test_read_group/tests/test_read_group_process_groupby.py`)
Appendix:
Language (english-US)
VIEW (per week) | DASHBOARD
___________________________________________________________________
W23 -> 06/05 | 05/29 -> 06/04
W24 06/06 -> 06/12 | 06/05 -> 06/11
W25 06/13 -> | 06/12 -> 06/18
(Monday - Sunday) (Sunday - Saturday)
Language (french-BE)
VIEW (per week) | DASHBOARD
___________________________________________________________________
W22 -> 06/05 | 05/30 -> 06/05
W23 06/06 -> 06/12 | 06/06 -> 06/12
W24 06/13 -> | 06/13 -> 06/19
(Monday - Sunday) (Monday - Sunday)
opw-2747066
closesodoo/odoo#93053
Related: odoo/enterprise#29539
Signed-off-by: Raphael Collet <rco@odoo.com>
This commit revamps the UX of the StateSelection field widget. Now, instead
of filtering the options by removing the current selected value, the field
displays the entire list in the dropdown, and the selected item has a
checkmark to indicate its status.
This allows us to remove the tooltip, since its presence was not useful
anymore, and was unintuitive to use. This changes required to adapt some
tests asserting its presence, as well as the number of items shown in the
dropdown menu.
task #3177182closesodoo/odoo#113203
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit the message was only containing a message 'Personal
information update.' but it was not clear why the person was receiving
this message nor why he was receiving it.
closesodoo/odoo#113550
X-original-commit: de0061326bbd9e2fc5319c05448395afa5b71afe
Related: odoo/enterprise#37492
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
This commit only adds the missing test from the original PR
since the feature was added back in without the test
opw-3032052
closesodoo/odoo#113562
X-original-commit: 542516b6b07c44e08b21271fbc9129c446e12c1b
Signed-off-by: Tiffany Chang <tic@odoo.com>
Signed-off-by: Stefan-Calin Crainiciuc (stcc) <stcc@odoo.com>
There was an error in the XML template of the 'department_chart', the
opening tag was a <div> but closed with a </t>
sentry-3951803776
closesodoo/odoo#113543
X-original-commit: 2ea1efb20861c1cbd1d3a19ef9b4ef54385effed
Signed-off-by: Adrien Widart <awt@odoo.com>
In one of the previous commits from v15.5 the account code was improved but it
created a bug for Account Payment Terms .As we know odoo has defined default
Decimal Accuracy for Payment Terms is 6 and even on changing the decimal
accuracy for Payment Terms. The field Value in account_payment_term only
showed 2 decimal points because of the changes made in a previous commit.
We have fixed it by removing the digits attribute from the
account_payment_term view
Commit link-
https://github.com/odoo/odoo/commit/3dad4b3cb1cb823ae6ccbf56b990012ceca61d99
opw-3200888
closesodoo/odoo#113542
X-original-commit: 049c628945278477b35984864cfb19128892142f
Signed-off-by: Josse Colpaert <jco@odoo.com>
When loading a module, the code in the tests directories should not be
loaded.
One does not need freezegun on a server without running the tests.
closesodoo/odoo#113536
X-original-commit: 705c5d5dd9b76850638bd5d36b8395314ba78248
Related: odoo/enterprise#37481
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Sale Analysis report shows prices in company currency, converting foreign currency into the company currency according to the currency exchange rate.
Currently, the currency conversion is done incorrectly.
For example let's say 1 EUR = 25 CZK OR 1 CZK = 0.04 EUR.
Sales order: 39 EUR = 975 CZK.
Sales Analysis report shows 1.56.
This is because we are trying to multiply the order amount by 0.04, while it should be divided.
It used to be divided up until 16.0.
This commit changes the operator to convert the currency correctly.
opw-3167522
closesodoo/odoo#113525
X-original-commit: ef57d53866dc1d404138809132176c79d60a3b51
Signed-off-by: Aliya Tastemirova (alta) <alta@odoo.com>
RATIONALE
Remove _onchange_template_id / defaults usage for composer fields. It
lacks control and make value computation hard to understand and predict.
PURPOSE
Split _onchange_template_id + default_get + get_record_data usage into editable
computed stored fields. Each field should have its own method with its triggers
(template, composition mode, ...).
SPECIFICATIONS
Improve composer to correctly compute field ``email_add_signature`` in
compute method.
When having a template, consider it defines completely body and do not add
signature. Without template, add signature by default in comment due to post
processing for notification emails. Mailing mode does not handle signature.
Followup of odoo/odoo#107356
Task-2088884 (Mail: Use editable computed stored fields in composer)
closesodoo/odoo#113522
Related: odoo/enterprise#37478
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Inactive users should not be added in followers of records, especially using
automated subscription. Indeed they mainly generate noise in notification
process and are generally skipped.
Few use case exists of inactive users creating records. One use case is the
mailgateway running as root but a context key 'mail_create_nosubscribe' is
used to avoid it. Other use cases include automated action for example who
are also generally protected.
Anyway better be sure and consider this is a standard use case. To extend
this rationale, inactive people are currently not added when posting. It
therefore makes sense to keep this behavior coherent through the mail stack.
Task-3046371 (Mail: Better Language Support in Composer)
Part-of: odoo/odoo#113522
Currently an inactive user that creates records is added in followers. Standard
use case is the mailgateway but it has the 'mail_create_nosubscribe' context
key that avoids the mailgateway user to be added in followers automatically.
A test is added without the context key that shows that inactive users are
added as follower when creating a record. This is due to the direct call
to '_insert_followers' that does not perform any filtering on inactive users.
Task-3046371 (Mail: Better Language Support in Composer)
Part-of: odoo/odoo#113522
Allow to return <mail.mail> records and found outgoing emails when using
asserts. It eases doing checks in some specific tests e.g. checking
notification layout usage in emails. Indeed this is quite low level and
does not really deserves its own assert tooling methods.
Task-3046371 (Mail: Better Language Support in Composer)
Part-of: odoo/odoo#113522
In this commit:
- project tasks kanban view: if partner_is_company, we display partner_id
else commercial_partner_id -> this information is useless so we decided to
display partner_id in both cases.
- manager_id is not used in any view -> drop the field
- when creating a task by mail, email_from is set to the sender email then will
be changed depending on partner_id and parent_id, the field name is not significant
as it change and no more contain the original email sender, it's also a duplicated
information that can be got from partner / parent -> delete the field and create
a new partner if no one already exist with the same email.
- when project.analytic_account_id is changed, only tasks that have the same old
analytic_account_id will follow the name value -> we decided to change the behavior
and apply the new value for all tasks.
- project_analytic_account_id not used in any view and in only place in python
-> delete field
- project.project: partner_email, partner_phone are not used in any view ->
delete field
- project.task: partner_email not used -> delete field
- ancestor_id is no more used in any view or python reference as it's a complicated
field to understand by users -> remove ancestor_id from project.task and remove also
ancestor_task_id that is related it to it in timesheet context and replace it with
parent_task_id which is more simpler to understand by users.
task-3103701
closesodoo/odoo#110101
Related: odoo/enterprise#37246
Related: odoo/upgrade#4269
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
As with fieldsToFetch in commit 25bf5a3fabfa9da5367e82d1c5713425c77bc373,
we will convert fieldDependencies into an array of fields.
We did it because it's easier to use and more natural to has an array.
Part of task 3179751
closesodoo/odoo#113482
Related: odoo/enterprise#37449
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
When using the ControlPanel's bottom-right slot in another component, if
`viewSwitcherEntries` wasn't defined in `env.config` it would raise a
traceback, as the template would try to check an `undefined`'s length.
Removed the workaround that added an empty `viewSwitcherEntries` in the
forecast report and the bom overview report since it's no longer
necessary.
closesodoo/odoo#112415
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
This commit adds an icon on hover of sections inside the questions ListView
to indicate more clearly to the user that they can edit these lines.
task-2988062
closesodoo/odoo#108731
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Add an external code field on the hr_work_entry model to have
a custom code when exporting the work entries to another system.
task-2929493
closesodoo/odoo#104326
Related: odoo/upgrade#3998
Related: odoo/enterprise#33337
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Finland is comprised in the EAS list but is not currently supported in
Odoo. This commit makes UBL Bis 3 available for Finnish companies.
opw-3178684
closesodoo/odoo#113509
X-original-commit: 6ade738c2fc63c824adee570886376019459ab73
Signed-off-by: Nicolas Viseur (vin) <vin@odoo.com>
Signed-off-by: Julien Van Roy <juvr@odoo.com>
Steps to reproduce:
- Create a new journal Bank
- In Sequence, find the 'New Bank Check" and edit it so the sequence can be 10 number digits long
- Create a Vendor Payments with the the New Banck and Check as a method
- Click on Print a check
- Set any number > 2147483647 and validate
Issue:
Traceback
Cause:
The query SQL make a check to verifiy that the number is correct ('025'::integer == '25'::integer but '025'!='25)
But using INTEGER limits the number up to 2147483647 (https://www.postgresql.org/docs/current/datatype-numeric.html)
Solution:
Use BIGINT whose limit is 9223372036854775807
opw-3140973
closesodoo/odoo#113499
X-original-commit: 49dd9dffd7b96fd90860123f8b3f0e623979b246
Signed-off-by: Yolann Sabaux (yosa) <yosa@odoo.com>
Signed-off-by: John Laterre (jol) <jol@odoo.com>
Currently, when editing a report line, it's possible to create
a new expression with a label already used on the same report line.
This is problematic as the columns are using the expression label
to select the right expression. Indeed, one expression is going
to be selected but there isn't any obvious way to guess which one.
The solution is to add an SQL constraint on the report line expression.
task-3199014
closesodoo/odoo#113222
Signed-off-by: John Laterre (jol) <jol@odoo.com>
This commit aims to simplify the extractProps api by removing "field".
The Field will need to go into
this.props.record.fields[this.props.fieldname] to access the information
previously stored in the "field" parameter.
Part of Task: 3179751
closesodoo/odoo#113214
Related: odoo/enterprise#37469
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Allows model to provide default values for auto creation of related res_partner
such as name, title, ... It avoids the user to enter the information twice.
Use the newly introduced mechanism for crm.lead to prepopulate auto created
res_partner:
- when selecting a suggested recipient, by prefilling the simplified form (job
position, phone, ...) along with non modifiable data that will also be used to
populate the res.partner like the address, website, ...
- when selecting a template for a message on a lead without a partner, the
partner is automatically created with values from the lead: email, phone,
address, ...
Task-3024050
closesodoo/odoo#105111
Related: odoo/enterprise#33687
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
This fixes the problem of the full res_partner form being displayed instead of
the simplified one in some cases (and vice-versa).
The problem can be reproduced by the following steps:
- launch odoo without xml dev_mode enabled (otherwise the cache is disabled)
- in helpdesk, go to an existing ticket and click on an existing customer (this
will load the full form for the customer into cache)
- create a new ticket by first completing name and customer name, save it
- complete the email address, save it
- go to "Send message" and click on the email checkbox
- the full form is loaded instead of the simplified one
(base.view_partner_simple_form)
It is also possible to get the simple form instead of the full form by
reversing the order of the visited forms.
Technical note: The problem has been fixed by adding the context key
"force_email" as cache key using _get_view_cache_key override. Indeed,
_get_view_cache uses _get_view which result depends on that context variable in
its redefinition in res_partner.
Task-3024050
Part-of: odoo/odoo#105111
When the contact name was not yet set, the email was displayed twice in the
composer: first as the contact name and then as the email in parentheses. Now
when the contact is the same as the email, nothing is displayed in parentheses.
Technical note: the regexp in the mail util parseEmail method has been slightly
modified because it was returning in some cases the name surrounded by quotes
(ex.: "newlead3@ex.com" <newlead3@ex.com> --> name: "newlead3@ex.com"). This is
no longer the case with this change. That change was needed for comparing the
name and the email to avoid to display the same thing twice (when the email and
the name are the same). Note that the method is only used once, where we have
done the change.
Task-3024050
Part-of: odoo/odoo#105111
Selecting a recipient for which there exists no partner trigger a partner form
dialog creation. For some model (ex.: crm.lead), some default values can be
prefilled from the current record. This is what we do here by calling a generic
mechanism that allows each model to define default value for related partner.
Note that we don't provide a more detailed form to the user because some will
otherwise feel obligated to fill it out entirely.
Technical note: As there is no need for a custom form per model from which the
data are extracted to populate the related partner, the simplified partner form
(view_partner_simple_form) is just augmented with additional invisible field by
modules that add fields to partner and need to populate them automatically from
values of another model.
Technical note: In TestCRMLead.test_message_recipient_partner_auto_creation, we
test that the _message_get_suggested_recipients returns the correct default
values to copy some fields from the lead to the partner to avoid the user to
reenter them. But we don't test specifically that it also work when using mail
composer and template (which generate the partner) because it has already been
tested when introducing the mechanism. Although, we verify that it should
behave the same because we verify that the default values returned by
_get_customer_information, that is used in mail template when using the
composer, are the same as the ones returned by _message_get_suggested_recipients
which is tested here.
Task-3024050
Part-of: odoo/odoo#105111
Define information taken from the lead when a partner is automatically
created from it. It avoids the user to enter the information twice and
automated partner creation now correctly takes information when possible.
Task-3024050
Part-of: odoo/odoo#105111
Allow model to provide default values for auto creation of related res_partner
such as name, title, company_id, ...
It is used when claling 'Partner._find_or_create_from_emails()' that now
accepts custom data when creating partners based on a given email_normalized.
This allows notably to flatten a loop due to multi-company when creating
partners from emails in template management. It is now done using this email
based dict allowing to create all partners at once.
Task-3024050
Part-of: odoo/odoo#105111
Allows to rate any record extending mail_thread. This change was needed because
the rating template could be sent on any record (with some minor changes like
removing reference to specific record) and if the record was not extending the
rating mixin, it was crashing when the controllers using rating mixin features
were used.
This commit moves the code from the mixin rating.mixin to mail.thread and
adapts the test for testing rating submission with and without the mixin.
Technical notes
- rating_ids field has been added in mail.thread instead of using a simple
query because it improves performance while getting rating token in mass.
- the rating mixin now inherits from mail.thread to add features on top
of basic rating support in mail.thread.
Task-2674649
closesodoo/odoo#103966
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
This task integrate the rating feature in mail.thread which adds one query in
the unlink method (for deleting the related rating) on model that were not
inheriting from rating.mixin.
Task-2674649
Part-of: odoo/odoo#103966
Victor Feyens