Now that the RelationalModel is based on unity, datapoints expect
to receive their data as returned by unity read (i.e. x2many values
are list of records, not ids, and many2one values are objects with
keys id and display_name, not tuple, or simple ids). As a
consequence, the Record component needed to be slightly adapted for
current usecases to continue working (e.g. using a Record component
for a Many2ManyTags field, and providing the value of the many2many
as a list of ids, like in the studio action editor sidebar).
This commit completes the relational values received by the Record
component with the related records, like if they were read by
unity.
The Record component's API will be reworked soon, now that the
new RelationalModel has been merged, to be more compliant with the
new unity concept.
Part of~3179751
Part-of: odoo/odoo#114024
Have a many2many field with widget many2many_checkboxes. Before
this commit, the widget notified the model (i.e. called replaceWith
on the static list) for each change of one of its checkboxes. This
means that if the was an onchange on the field, the onchange rpc
was done once for each click. With this commit, we debounce the
call to replaceWith, which allows to tick/untick multiple
checkboxes, and a single onchange is done with the resulting value.
This allows to mitigate another issue, which is that consecutive
calls to replaceWith are error prone, because they might send a
list of ids which isn't up to date with the one of the last call
to replaceWith (if the list is computed from the value in the
datapoint), as replaceWith uses the model mutex and thus updates
the datapoint in an async way. This specific issue will be tackled
later.
Part of~3179751
Part-of: odoo/odoo#114024
This commit adds an option to _updateConfig which allows to specify
a callback to apply the new values obtained from the updated config
e.g.
1) a dynamic list updates its offset (calls _updateConfig)
2) a web_search_read is done and returns some records
3) the new config (with the new offset) is applied on this.config
4) record datapoints are created for the returned records and set
on this.records of the list
Before this commit, step 3) was done in _updateConfig, and step 4)
was done by the called of _updateConfig. As _updateConfig is async,
step 4) was actually done in the next microTick after 3). As a
consequence, those two mutations could trigger owl renderings.
To avoid this situation, _updateConfig now takes a "commit"
function, which allows it to execute 3) and 4) in the same tick.
Part of~3179751
Part-of: odoo/odoo#114024
Have a field x2many without relation_field.
Before this commit, a server error was raised because, we send changes
for the non-existing field (relation_field).
Now, we only send to the server the changes for relation_field only if
they exist.
Note that, this commit will also add an exception on the server mock
onchange if we sent changes for non-existings fields.
Part of task~3179751
Part-of: odoo/odoo#114024
Have a view with many2many_checkboxes field (e.g. product.template
form view with inventory installed, and some routes). Tick a
checkbox. Before this commit, a read was done, but the field spec
was empty (there was no field to read). So basically the read only
returned the id. This is obviously useless. This commit prevents
from doing read rpcs when the spec is empty.
Part of task~3179751
Part-of: odoo/odoo#114024
Have a form view with an x2many field A displayed as a non editable
list view. In A's form view, there's an x2many field B, which isn't
in the list. B is itself displayed in the dialog form view as a
list, which contains an x2many fields C displayed as many2many_tags.
A contains a record. For this record, B contains also a record,
which contains two tags for C.
Have an onchange on the main record which triggers an update command
for the record in A, such that the command also updates the record
in B, which deletes (or forgets), i.e. commands 2 or 3, a tag C.
Before this commit, if the user opened the x2many record of A after
the onchange, it didn't displayed the remaining tag in C. The
reason is that we received commands to remove the tag before we
actually fetched them (as we don't need them for the list of A).
The tags were then fetched when we opened the record in a dialog,
but we didn't correctly merge the values read from the server with
the commands we received earlier.
With this commit, we properly store the commands and apply them
after reading the values.
Part of task~3179751
Part-of: odoo/odoo#114024
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>
Aaron Bohy