Have an x2many list or kanban with several page, and an onchange
on the main record that returns forget or delete commands for
x2many records that aren't on the first page. Before this commit,
it crashed, because the code expected the records to be in
this.records (the record of the current page).
Part of task~3179751
Part-of: odoo/odoo#114024
With the image field widget, the image is reloaded each time the record
is updated (when `write_date` is updated). This is not always desirable
as some images are not supposed to change.
This commit adds an option to bypass the image reloading. This option
is called `no_reload` and is set to `false` by default.
Part-of: odoo/odoo#114024
- On an one2many;
- drag and drop two records;
- a resequence is called, with an onchange;
- click save;
Before this commit, if the network was a little too slow, the return of
the onchange wasn't taken it into account for the save.
Now, we await the onchange of the resequence before executing another
action.
Task 3179751
Part-of: odoo/odoo#114024
Before this commit, going into a view with a record that had no properties displayed a crash.
Why ?
If no properties exist, the value is false and was not handled.
Part-of: odoo/odoo#114024
Before this commit, there was a hook, named useModel, which eases
the use of a model in views. The main (and almost only) role of the
hook was to deal with sample data (determine whether or not they
can be enabled, fallback on the sample orm when necessary, leave
sample mode at reload...). This hook is used by all views except
form and activity as they do not implement sample data.
This commit renames that hook into "useModelWithSampleData" and
introduces a new hook "useModel", which is a lot simpler that the
other one, as it's only goal is to do the plumbing between the
component using the hook and the model (i.e. spawning required
services and loading the data on willStart and willUpdateProps).
This new hook is used in form and activity views.
Note that useModel doesn't trigger deep renderings, as it is only
used on the RelationalModel which is based on fine-grained
reactivity.
Part-of: odoo/odoo#114024
...when using the pager.
When a record is dirty and the user clicks on the pager to go to
the next/previous one, it is automatically saved. Before this
commit, the record was reloaded after the save, which is useless
as we're leaving it anyway. This commit ensures we only save, and
we do not reload.
Part-of: odoo/odoo#114024
Before this commit, the x2m present in a record's evalContext was
represented by the resIds defined in the config. It therefore did not
contain the current changes. It should therefore be represented by the
currentIds of non-virtual records.
How to reproduce:
- Create a new record with a m2m field having at least one default record
- Edit a field which triggers an onchange with a context depending on the
value of the m2m
Before this commit:
The domain and context used contain an empty list for the m2m.
After this commit:
The domain and context used contain a list with the default id for the m2m
Part-of: odoo/odoo#114024
In form views, the "display_name" field is automatically added to
the list of activeFields as we need its value to display in the
breadcrumbs. However, this isn't necessary when there's no control
panel, in particular in dialogs. Without this commit, the test
"test_addremove" of addon test_apikeys didn't pass.
Part of task~3179751
Part-of: odoo/odoo#114024
Be on an existing record containing an x2many field. Add a row
or click on an existing one to edit it. The changes sent for
onchange done for the subrecord contains a key with the changes
in the parent record. Before this commit, this object didn't
contain the id of the parent record. As a consequence, the
onchange (in py) couldn't correctly link the sub record with
its parent to compute field values. This commit ensures that we
always provide at least the id when the parent record exists.
Part of task~3179751
Part-of: odoo/odoo#114024
Before this commit, when a field of type one2many or many2many, was
added and afterward deleted, on the onchange or write call to the server
the field wasn't added as a change (because the add and delete command
cancel each other). This can cause issues because when adding the x2many
field, the onchange on the server can have side effects that we want to
remove when deleting the x2many.
Now, we follow the following rule : If a field has been modified, its
value must always be sent to the server for onchange and write.
This commit also avoid to call update on the parent record if the chil
record didn't have changes.
Task 3179751
Part-of: odoo/odoo#114024
Before this commit, the save button in the x2m form view dialog does
not wait for ongoing updates.
Why is this?
When you click on the "Save and Close" button of a form view dialog
in an x2m, you check the validity of the record to know whether you
should save or not. The askChanges function called does not wait for
ongoing updates.
Solution:
Just wait until the model mutex has finished processing all the current
functions. This ensures that the record has applied all its updates.
How to reproduce:
- Go to a form view with a non-editable x2m
- Add a line
- Edit a required field with a slow onchange
- Click "Save and close" before the onchange is complete
Before this commit:
The form dialog remains open and a notification appears telling us that
a required field is invalid.
After this commit:
The dialog is closed and the change has been applied.
Part-of: odoo/odoo#114024
Before this commit, it crashed if an x2many field inside another
x2many field had a context with a key referencing the parent
record:
```xml
<form>
<field name="foo"/>
<field name="outer_x2many">
<tree></tree>
<form>
<field name="inner_x2many" context="{'key': parent.foo}">
<tree></tree>
</field>
</form>
</field>
</form>
```
The crash occured because we tried to evaluate the context of the
static list representing inner_x2many before setting the parent
key on the eval context.
Part of task~3179751
Part-of: odoo/odoo#114024
Have a required many2manytags field and a slow network. The field
is initially empty. Add a tag to the relation and directly save.
An invalid field notification is displayed, because the field is
still considered empty. This commit ensures that we wait for the
operations done in the static list before saving.
Part of task~3179751
Part-of: odoo/odoo#114024
For char/text fields, the server can return false or "" (empty
string) depending if the field isn't set in db (NULL) or set to
the empty string. This makes no difference in the UI, but it
matters when evaluating modifiers.
Before this commit, the value of char/text fields was automatically
set to the empty string if it was falsy, as it doesn't impact the
UI, and it is cleaner type-wise. Unfortunately, we cannot do that
for the eval context, as we must be able to make the difference
between False and "" evaluating modifiers. A solution would have
been to stop fallbacking on the empty string when the value was
false, but we wanted to keep the clean API. So this commit fixes
the issue by keeping an internal structure in Record to track
the exact values we received from the server for those fields, and
use that structure to generate the eval context.
Part of task~3179751
Part-of: odoo/odoo#114024
Have an x2many field displayed with a kanban view containing sub
fields with widgets (widget="..."). Click on a record to edit it
in a form view dialog. Before this commit, the fields of the kanban
card displayed in the background were switched to "edit" when the
dialog was open. With this commit, we ensure they always remain
displayed in "readonly".
Part-of: odoo/odoo#114024
From a list or kanban view, open a form view with a statusbar
field (e.g. in crm.lead). Go back to the list. Open another record
for which the domain of the statusbar is different. Before this
commit, it crashed, because the component bound to the orm service
used by the specialData cache (i.e. the previous FormController)
is destroyed.
Part-of: odoo/odoo#114024
Have an x2many with an x2many editable list inside the form view
containing at least a row. Open a record, click discard. Open it
again, and click on a row of the x2many to switch it to edit mode.
Before this commit, the row could never be switched back to
readonly. This was the list renderer didn't correctly compute its
active element (it must wait for a micro tick for the mounted hook
of the dialog, its ancestor, to be called).
After fixing this issue, a second one arise: the row can now be
unselected, but it disappears if it is a new record. This is
because we lost the dirty flag when clicking on discard. This is
fixed by storing the dirty state alongside changes in the
savepoint.
Part-of: odoo/odoo#114024
Before this commit, x2m in list mode with several pages did not work
correctly when sorted. The order was lost when the page was changed and
any values not used for sorting were missing.
How to reproduce:
- Go to a form view with an x2m in list mode with at least 2 pages
- Sort on a column
- At least one record not present before sorting is displayed
Before this commit:
This record only contains the values used for sorting
After this commit:
This record contains all the values
- Click on next page
Before this commit:
The records displayed on the page are not ordered and contain only
the values used for sorting.
After this commit:
The records displayed are the correct ones for the sort and contain
all the values.
Part-of: odoo/odoo#114024
Before this commit, go to a form view with an x2m displayed in list mode.
If you sort the x2m on two differents fields, a crash is displayed.
How to reproduce:
- Go to a form view with an x2m in list mode with at least 2 columns sortable.
- Click on a column to order
- Click on a second column to order
Before this commit:
We have a crash
After this commit:
The list is ordered correctly
Part-of: odoo/odoo#114024
This commit adapts the code in addons w.r.t. the introduction of
the RelationalModel.
Main changes that were requested are:
- record datapoints no longer always have an "id" key in their
data (they still do if the id field is in the view), so we use
record.resId instead
- the new model is based on fined-grained reactivity, so several
components that previously relied on onWillUpdateProps to update
their internal state no longer worked. Typically, using the hook
"observeRecord" is the way to go now.
- specialdata are no longer handled in the model, so the components
needing specialData can use the hook "useSpecialData"
- more generally, all overrides of models (RelationalModel or
KanbanModel) needed to be reworked.
Part of task~3179751
Part-of: odoo/odoo#114024
Co-authored-by: Aaron Bohy <aab@odoo.com>
Co-authored-by: FrancoisGe <fge@odoo.com>
Co-authored-by: Jorge Pinna Puissant <jpp@odoo.com>
Co-authored-by: Pierre Rousseau <pro@odoo.com>
Before this commit, we had several implementations of a relational
model. The form view used the BasicRelationalModel, which was a
wrapper around the BasicModel. The list view used the
RelationalModel (a simpler version that didn't support complex
usecases of x2many fields). The kanban view used the KanbanModel,
an extension of RelationalModel.
This commit removes all these, and replaces them by a single model.
It is called RelationalModel, and as a similar structure as its
predecessor (with datapoints). It now handles tricky x2many usecases
of the form view though.
This commit also comes with several important changes:
1) The new model is based on unity reads [1]. This means that all
data required by the view is fetched at once, and datapoints are
created with their data (whereas before, they were responsible to
fetch their data). There's an exception for special data: they are
no longer handler by the model. A hook "useSpecialData" has been
created, and it allows fields (components) to fetch additional
data they require.
2) The new model uses onchange2 [2]. With onchange2, we send and
receive a diff, instead of the whole state of the record. Morever,
onchange2 uses unity, which means that returned commands for x2manys
(e.g. command 4, LINK) contain the values of the corresponding
records, so we don't need to fetch them in a separate call
afterwards.
3) The new model no longer triggers deep renderings (render(true)).
It is instead based on fine-grained reactivity (i.e. only what
depends on what has changed is re-rendered). We introduced a hook
"observeRecord" which allows a component to subscribe itself to
some keys in a record datapoint, and register a callback to
execute when those keys change (e.g. to fetch data).
[1] odoo/odoo@7d2baaa0c7
[2] odoo/odoo@f5e6494da3
Task~3179751
Part-of: odoo/odoo#114024
Co-authored-by: Aaron Bohy <aab@odoo.com>
Co-authored-by: FrancoisGe <fge@odoo.com>
Co-authored-by: Jorge Pinna Puissant <jpp@odoo.com>
Co-authored-by: Pierre Rousseau <pro@odoo.com>
This completes 96a98f4f4c in the case
where a many2one field has a new record as value, even when that
many2one field is not a delegate field.
Part-of: odoo/odoo#114024
This commit improves the selection of records in list view using the
SHIFT and arrow keys. In task 2039894, it has been made possible to
select a range of records using the keyboard, but the experience was
confusing. So, the latest task aims to improve the situation regarding
selection with keyboard and navigation.
A test has been added to verify the behavior when selecting multiple
rows, using multiple ways of interaction (SHIFT + arrow, click,
navigate and select).
task-3418715
closesodoo/odoo#128995
Signed-off-by: Florent Dardenne (dafl) <dafl@odoo.com>
The dark mode assets were mistakenly loaded in the default backend
assets, effectively overriding the light theme for spreadsheet 100% of
the time.
closesodoo/odoo#129339
X-original-commit: 97cf8bf7f757b82bdecd6a4531d6b00fcd591bd9
Signed-off-by: Lucas Lefèvre (lul) <lul@odoo.com>
Signed-off-by: Rémi Rahir (rar) <rar@odoo.com>
If a user goes from "Access Rights" (base.group_erp_manager) to
"Settings" (base.group_system) he gets an error telling him he did not
belong to Access Rights group.
The reason was that the modification of accesses on the user profile
page was doing
write({'sel_groups_2_4': 4})
which was transled, after the _remove_reified_group call into
write({'groups_id':[(UNLINK, [2, 4]), (LINK, [4]]})
so the user was temporary in a state where he was in the group_system
but no in group_erp_manager.
When the implied groups where computed, an access error was raised as
the administrator was not allowed to modify res.users record (need
group_erp_manager).
Simplify the _remove_reified_group call to only convert the call to
write({'groups_id':[(LINK, [4])]})
closesodoo/odoo#129335
Task-id: 3265053
X-original-commit: 0ed2fa018a7716f0fb3abe587983209403445fc8
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
This commit is part of the refactoring and improvement of the html and css of account_reports (enterprise).
Here we:
- Remove blank_if_zero default value of True, it is now False by default. The zeros are now shown in a muted gray color.
- As we had a level of hierarchy 0 that allows for some further styling we needed to adapt _compute_hierarchy_level to take it into account when calculating the increase level. So if the level is 0 or 1, the child will have a level of 3 either way.
- Removed some UPPERCASE column styling.
Task-id 3251726
closesodoo/odoo#129232
X-original-commit: 56a7f7745c5df9b70e6fe5b78f401085ce46284c
Related: odoo/enterprise#44436
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
before this commit, in the import module wizard the
end user can select any type of file in the upload
file field and clicking import it will say only zip
format is supported.
after this commit, on clicking upload files, only
zip files will be shown to the end user to select,
which will make easy to select the files from
directory
closesodoo/odoo#128484
Related: odoo/enterprise#44089
Signed-off-by: Luca Vitali (luvi) <luvi@odoo.com>
We currently convert rgb colors to hexadecimal, but not rgba colors.
Unfortunately since many Bootstrap border colors are defined as rgba,
this meant that these were not properly converted for Outlook (which
doesn't support rgba).
To convert rgba while losing the transparency information we need to
"flatten" it by taking in consideration the background color.
closesodoo/odoo#129153
X-original-commit: dc56506cffa5a13508ca24018d4f0a25c5353cca
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Signed-off-by: Antoine Guenet (age) <age@odoo.com>
The `font-family` style can sometimes include double quotes. This isn't
really a problem since these get escaped (`"`) but emailonacid
currently has a bug where the double quotes cause every subsequent style
to be ignored, and the rendering to be incorrect. For the sake of future
testing, this converts them to single quotes. It also removes the style
entirely from image elements since they don't make sense there.
X-original-commit: 03c7e69db63f326c7a3b3085debc5d3a5c95966d
Part-of: odoo/odoo#129153
A semi-colon unfortunately took the place of a double pipe in code that
retrieves an image's width in order to set its width attribute. This led
to some images being wrongly sized.
opw-3299392
X-original-commit: 0a21da39f05ef9ec9d202424e0e648849f44e164
Part-of: odoo/odoo#129153
Customer reported an XML file with an UBL_version 2.2
reported <cbc:UBLVersionID>2.2</cbc:UBLVersionID>
at the beginning of the XML file.
As reported on the wikipedia page of the
'Universal Business Language' (UBL):
- the version 2.2 has been approved&published on July 2018.
- the version 2.3 has been approved&published on June 2021.
opw-3316684
closesodoo/odoo#129043
X-original-commit: 5b011440eb96ab02aaaa3b3754d0475a01a2ef16
Signed-off-by: Baptiste Vergote (bve) <bve@odoo.com>
Steps to reproduce
==================
- Go to documents
- Click on a document
- Add a tag
-> Nothing happens
Cause of the issue
==================
Since https://github.com/odoo/enterprise/commit/e35017719d0996279f362423a7b4b1c6e30b9766 ,
the documents app uses the _multiSave method from the relational_model.
If the selection is of only one record, the changes passed to the method
are ignored.
opw-3393862
closesodoo/odoo#128515
X-original-commit: 7e361761d20ddc64c62b85f3496e1596dc42987b
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Hubert Van De Walle <huvw@odoo.com>
This commit remove the way we display the price on the same line as the product name.
It was only used in few cases and most of the time the price was display on another line because we have to add information.
So now, we just use only one generic case that can handle all of them.
closesodoo/odoo#127575
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Complement to commits:
290465e57dfcb8503e382a418e0ba4498ea5693b
72c62dbf157dfb353caf13a228921e3f81036885
Prevent synchronization between applicant
and partner if partner information changes.
The partner must be changed to update the applicant.
When someone applies for a job via a platform,
the "generic" email is used to create the applicant.
As a result, all applicants have the same partner.
The different commits and this one ensure that
the partner's email is not overwritten
if we update the applicant's email address.
Because changing the partner's email address
synchronized it with all applicants.
All applicants had the same e-mail address.
opw-3166630
closesodoo/odoo#129277
X-original-commit: 397e5ee79b46631040eb71c89b1f7e2891a3da52
Signed-off-by: Sofie Gvaladze (sgv) <sgv@odoo.com>
Signed-off-by: Thomas Lefebvre (thle) <thle@odoo.com>
Fix various issues that appeared when working with registrations. When converting
registrations to leads using rules some convert flows have issues or can crash. This
PR fixes several issues, see sub commits for more explanations.
Improve test suite to cover more use cases.
Task-3431124
closesodoo/odoo#129269
Forward-port-of: odoo/odoo#129111
Forward-port-of: odoo/odoo#128823
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Avoid issues when generating lead description based on linked registrations
notably with formatted emails.
Task-3431124
X-original-commit: 471025a7bd227d334ac5b450c93a2ee99c22517a
Part-of: odoo/odoo#129269
Partial backport of odoo/odoo@94fa8d9625 keeping only event_crm part as
other changes were done only for Odoo16.
In this commit we try to compare formatted phones of registration and
partner, before checking the actual phone numbers. If only formatting
differs then it is not a different number.
Task-3431124
X-original-commit: 4589eebe4978ac0746fa4bc5c8664cb30d912cc1
Part-of: odoo/odoo#129269
When checking updated values of a registration to propagate to its linked lead
we may compare a recordset to IDs. This commit fixes that by always comparing
IDs.
Task-3431124
X-original-commit: 874c2cf44c9f42d928b646c86c974251dd95cfc0
Part-of: odoo/odoo#129269
Co-authored-by: Jeremy Hennecart <jeh@odoo.com>
When checking if partner and registration have the same email, better compare
normalized versions if possible as it filters out formatting differences
e.g. if one input has a formatted email with another name.
Task-3431124
X-original-commit: 1f2a08e6b0880d20f877a73badd3b071939bcc13
Part-of: odoo/odoo#129269
When having rules creating leads from registrations, email and phone are
copied from the registration if the linked partner has no value for those
fields. However an error in the code lead to setting phone into email which
is not really correct.
This commit also add tests for event_crm who allowed to spot other issues
which are fixed in the next commits.
Task-3431124
X-original-commit: 9bbf621e8e9cda90a0d29fd44e21cd4b61a54d73
Part-of: odoo/odoo#129269
To reproduce
============
on journal items add filter (Analytic contains something) and group by Account, no lines will be shown.
Problem
=======
`analytic_distribution` is a Json field stored as string in database as follows: `{"id" : "percentage"}`, which explains why no result is returned as there is no trace for Analytics name.
Solution
========
following same [fix](https://github.com/odoo/odoo/commit/bc5b72937a1c79688f7f6dc1c8aeaa7eb4cb6744), we replace `analytic_distribution` by `analytic_distribution_search` in the domain of `read_group`.
opw-3391182
closesodoo/odoo#129263
X-original-commit: 05209fd295727cbbb5bf6a316f3c8873de6b2bed
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Abdelouahab Laaroussi (abla) <abla@odoo.com>
Since [this commit], when the user configures a new website, he can
set an unknown industry. Unfortunately, if he does so, by default, we
set the industry to abbey, which is not very good for the default images
the user will see and for internal IAP stats. This commit permits to use
the new industry called Unknown, which is used for unidentified
industries. When the industry is unknown, we leave the default theme
images.
[this commit]: https://github.com/odoo/odoo/commit/e82a1cb2ef1bcb413d99e7eb7521405d1d2e88d2
IAP PR: https://github.com/odoo/iap-apps/pull/635
task-3337894
closesodoo/odoo#129154
X-original-commit: 17dd3a84d9d9d42b04fde9aac708c032a472b13b
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Guillaume Dieleman (gdi) <gdi@odoo.com>
Before this commit:
When changing the tag name, e.g applying a new format, the other styles
applied are removed
After this commit:
We no longer remove already applied styles of the text and only change
the tag name
Reproduction:
1. Install Email Marketing, create an email with a template
2. Drag a text block and set the background color of the whole block as
yellow
3. Set one line of the text body as Header 1, the background color is
cleared
Reason: it’s a normal result of removeFormat, it clears the background
color of the parent element and re-apply the color to the text not
selected
Fix: After checking a few most popular editors, the common behavior is
to keep the other styles applied to the text and only change the tag.
Thus this fix will remove the format removing steps. Because of this
change, the test case to check if the gradient text background color is
modified. Other specified styles are kept after the tag change.
Note: If the background color is the 5 colors at the first row, it won’t
be cleared by setting the format because the color is set as a CSS class
task-3245698
opw-3165587
Related PR/Fix:
Adding the gradient background color removal
https://github.com/odoo/odoo/pull/83065closesodoo/odoo#129285
X-original-commit: 17f90e304537e517233b8762d4fd2b7f75bfa642
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Purpose:
--------
Currently, a crash occurs if a portal user tries to open the colorpicker
(for example in project_sharing, or in knowledge portal introduced in
16.3 [1]).
This commit fixes this by adding the group `base.group_portal` to the
groups of the colopicker template.
Task-3429053
[1] https://github.com/odoo/enterprise/commit/1badfeae8d5c93c8bba8dafd56f94f6433888590closesodoo/odoo#129274
X-original-commit: 94e3211aa84feab28ac03902d9af849967ab125c
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Steps to reproduce:
-------------------
- being in a multi-company context;
- select a company that is not the user's default company;
- add a manager to an employee;
Issue:
------
We don't see the organization chart.
Cause:
------
There is no "allowed_company_ids" key
in the context of the rpc call.
Solution:
---------
If a context is passed explicitly
in the call rpc kwargs, it must be used.
Otherwise, use the default context of call rpc.
opw-3422642
closesodoo/odoo#129233
X-original-commit: 32353bcf94fa4f7378f61c22664267e1e8a34a1f
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Signed-off-by: Thomas Lefebvre (thle) <thle@odoo.com>
In saas~16.3 the field `tax_audit` was removed from the account_move_line model.
This PR is to remove an update to that field from a localization upgrade script since it doesn't exist anymore.
PR where the field was removed: https://github.com/odoo/odoo/pull/114616closesodoo/odoo#129246
X-original-commit: 041c68ea7b40dfad124f19d04498783da3b53a91
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
Aaron Bohy