pos*: l10n_ae_pos,l10n_co_pos,l10n_gcc_pos,l10n_in_pos,
l10n_sa_pos,pos_adyen,pos_discount,pos_epson_printer,
pos_hr,pos_hr_restaurant,pos_loyalty,pos_mercury,
pos_restaurant,pos_restaurant_adyen,pos_restaurant_stripe,pos_sale,
pos_sale_loyalty,pos_sale_product_configurator,pos_six,pos_stripe,
The POS has a large number of add-on modules. As such, it is
important that they all respect strict guidelines when it comes
to file structures.
Before, each module had more or less it's own rules when it came to
this, apart from the fact that code was mostly organised into
`js` and `xml` folders.
In this PR, we move to a much more structured approach,
in which each module follows the following pattern:
src/
|-- app/ <-- the module's own new logic
|-- overrides/
| |-- components
| | |-- overridden_component_a
| | | |-- overridden_component_a.js
| | | |-- overridden_component_a.xml
| | | |-- overridden_component_a.css
| |-- models
| | |-- overridden_model.js
Apart from the structural changes, this PR introduces changes
to file names, such that they respect the default pattern of
snake_case naming.
In this commit, we move the files. In the following one we
make the needed changes in the code, such as adapting imports.
Task: 3394192
closesodoo/odoo#127056
Related: odoo/enterprise#43594
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
pos*: l10n_ae_pos,l10n_co_pos,l10n_fr_pos_cert,l10n_gcc_pos,
l10n_in_pos,l10n_sa_pos,pos_adyen,pos_discount,
pos_epson_printer,pos_hr,pos_hr_restaurant,pos_loyalty,
pos_mercury,pos_restaurant,pos_restaurant_adyen,pos_restaurant_stripe,
pos_sale,pos_sale_loyalty,pos_sale_product_configurator,pos_six,
pos_stripe
In the previous commit, we moved and renamed files such that they
better follow certain guidelines.
In this commit, we adapt imports accordingly.
In order to efficiently accomplish this task, i used the following [script](https://github.com/vlst-odoo/tools/blob/main/fixImports.py)
Task: 3394192
Part-of: odoo/odoo#127056
pos*: l10n_ae_pos,l10n_co_pos,l10n_gcc_pos,l10n_in_pos,
l10n_sa_pos,pos_adyen,pos_discount,pos_epson_printer,
pos_hr,pos_hr_restaurant,pos_loyalty,pos_mercury,
pos_restaurant,pos_restaurant_adyen,pos_restaurant_stripe,pos_sale,
pos_sale_loyalty,pos_sale_product_configurator,pos_six,pos_stripe,
The POS has a large number of add-on modules. As such, it is
important that they all respect strict guidelines when it comes
to file structures.
Before, each module had more or less it's own rules when it came to
this, apart from the fact that code was mostly organised into
`js` and `xml` folders.
In this PR, we move to a much more structured approach,
in which each module follows the following pattern:
src/
|-- app/ <-- the module's own new logic
|-- overrides/
| |-- components
| | |-- overridden_component_a
| | | |-- overridden_component_a.js
| | | |-- overridden_component_a.xml
| | | |-- overridden_component_a.css
| |-- models
| | |-- overridden_model.js
Apart from the structural changes, this PR introduces changes
to file names, such that they respect the default pattern of
snake_case naming.
In this commit, we move the files. In the following one we
make the needed changes in the code, such as adapting imports.
In order to efficiently accomplish this task, i used the following [script](https://github.com/vlst-odoo/tools/blob/main/rename.py)
Task: 3394192
Part-of: odoo/odoo#127056
General guidelines for adaptations:
- include 'demo data' inside the report (e.g. `<span t-field='o.name'>INV/2023/001</span>`)
- include div.oe_structure elements in several places - these elements take no space in the printed report if empty, but allow users to 'hook in' several places of the reports
- modify the base report layout to include several placeholder blocks (for company address, etc.) that make it clear what goes where (since demo data are a bit unclear for bigger blocks, like address blocks)
- add branching or re-order some t-if/t-else conditional blocks. The report shows the first `t-if` content by default, so it makes sense to have it be 'the default value' (e.g. instead of showing the options table all the time in the editor for a quote report, only show is as a t-else) - the goal is to have the report editor open on a report that looks as much as possible as the default, vanilla version of the report
- whenever possible, try to avoid `<t>` nodes insise `table/thead/tbody/tr` nodes, as this is not allowed by the hml spec and browser parser will not agree with those. Since the problem is known, the report editor will convert such tables to div elements (and preserve the layout as much as possible) - but making sure the table is 'correct html' (e.g. by moving qweb directives on legal nodes, like tr or td) will preserve the layout and will also allow users to use the table modification tool of the Odd Editor
This is a first pass on 'important' reports. A second pass will come before v17.
closesodoo/odoo#129492
Forward-port-of: odoo/odoo#129310
Related: odoo/enterprise#44526
Signed-off-by: Bouvy Damien (dbo) <dbo@odoo.com>
A recent trend in report design in Odoo has been to dynamically set the
report template to call using a python method. This was used e.g. to
detect that a document should use an alternative report layout created
by a localization package.
Unfortunately, doing so 'breaks' the new report editor, as it runs
without an underlying record, and therefore cannot call python methods
to determine what the template id to call actually *is*.
This commit removes this mechanism from the Sales app and the Brazilian
localization, relying instead on 'normal' qweb directives and
inheritance to generate the proper layout.
This commit does not introduce any functionnal changes, it simply makes
the templates compatible with the new report editor. No visible change
should occur.
X-original-commit: cd26f77adecc7036c845ed1d7c7094b63987a1a1
Part-of: odoo/odoo#129492
make the qr code section easier to modify in the base report for the
swiss localization
X-original-commit: 105557cc817fc9d21837ee50ba4fbc502926d059
Part-of: odoo/odoo#129492
Includes several modifications to better work with the new editor:
- add placeholders on t-field/t-out nodes
- add several div.oe_structure containers in key places for easier user
edition
- add branching options for several t-if directives without a t-else to
display for users (e.g. displaying the payment QR code if the value is
set vs. when the value is not set). These branching options are set to a
default value (the t-if node) which is what users see by default in the
report editor; the t-else node is a version they can manually toggle if
they wish)
- avoiding 'naked' t nodes as child of table/thead/tbody/tr elements, as
these break the table layout in chomium-based engines (that we know of);
instead, try to have foreach loops on tr or td nodes directly, or hoist
t-set directives above the table node
- replace several div or p (block) nodes by span or other inline nodes
to make it easier for users to insert content in their vicinity
X-original-commit: 744701993ece3099ce4768b35d3c0effff7d46a7
Part-of: odoo/odoo#129492
Includes several modifications to better work with the new editor:
- add placeholders on t-field/t-out nodes
- add several div.oe_structure containers in key places for easier user
edition
- add branching options for several t-if directives without a t-else to
display for users (e.g. displaying the payment QR code if the value is
set vs. when the value is not set). These branching options are set to a
default value (the t-if node) which is what users see by default in the
report editor; the t-else node is a version they can manually toggle if
they wish)
- avoiding 'naked' t nodes as child of table/thead/tbody/tr elements, as
these break the table layout in chomium-based engines (that we know of);
instead, try to have foreach loops on tr or td nodes directly, or hoist
t-set directives above the table node
- replace several div or p (block) nodes by span or other inline nodes
to make it easier for users to insert content in their vicinity
X-original-commit: eabdfe294d38df463828f87970b25d52ceae4a6a
Part-of: odoo/odoo#129492
Includes several modifications to better work with the new editor:
- add placeholders on t-field/t-out nodes
- add several div.oe_structure containers in key places for easier user
edition
- add branching options for several t-if directives without a t-else to
display for users (e.g. displaying the payment QR code if the value is
set vs. when the value is not set). These branching options are set to a
default value (the t-if node) which is what users see by default in the
report editor; the t-else node is a version they can manually toggle if
they wish)
- avoiding 'naked' t nodes as child of table/thead/tbody/tr elements, as
these break the table layout in chomium-based engines (that we know of);
instead, try to have foreach loops on tr or td nodes directly, or hoist
t-set directives above the table node
- replace several div or p (block) nodes by span or other inline nodes
to make it easier for users to insert content in their vicinity
X-original-commit: 567b8d676b3b6dc747df4d9bf10e7a91b4cb61bb
Part-of: odoo/odoo#129492
Includes several modifications to better work with the new editor:
- add placeholders on t-field/t-out nodes
- add several div.oe_structure containers in key places for easier user
edition
- add branching options for several t-if directives without a t-else to
display for users (e.g. displaying the payment QR code if the value is
set vs. when the value is not set). These branching options are set to a
default value (the t-if node) which is what users see by default in the
report editor; the t-else node is a version they can manually toggle if
they wish)
- avoiding 'naked' t nodes as child of table/thead/tbody/tr elements, as
these break the table layout in chomium-based engines (that we know of);
instead, try to have foreach loops on tr or td nodes directly, or hoist
t-set directives above the table node
- replace several div or p (block) nodes by span or other inline nodes
to make it easier for users to insert content in their vicinity
X-original-commit: ddace177b9512657e3dee854309835b4b2f9af28
Part-of: odoo/odoo#129492
Includes several modifications to better work with the new editor:
- add placeholders on t-field/t-out nodes
- add several div.oe_structure containers in key places for easier user
edition
- add branching options for several t-if directives without a t-else to
display for users (e.g. displaying the payment QR code if the value is
set vs. when the value is not set). These branching options are set to a
default value (the t-if node) which is what users see by default in the
report editor; the t-else node is a version they can manually toggle if
they wish)
- avoiding 'naked' t nodes as child of table/thead/tbody/tr elements, as
these break the table layout in chomium-based engines (that we know of);
instead, try to have foreach loops on tr or td nodes directly, or hoist
t-set directives above the table node
X-original-commit: 60465047df56c07e61623c1f7304fede28232581
Part-of: odoo/odoo#129492
The dinosaur regular expressions[^1] used to count SELECT/INSERT queries in SQL
debugging mode were slowing down query execution. They can be replaced by
more efficient ones.
The `re.MULTILINE` flag is not necessary anymore, since there is no more
`$` or `^` in the expressions.
[^1]: f8471796a3closesodoo/odoo#129473
X-original-commit: 0730e432c470635baec962d16ca09e8423c2b3ba
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Olivier Dony (odo) <odo@odoo.com>
Setup:
------
1) Install website_sale module
2) Product:
One product with:
- Sales Price: 100
- Customer Taxes: 10% included
3) Fiscal position
Two fiscal positions:
- Country: France - 10% included --> 20% excluded
- Country: Netherlands - 10% included --> 15% included
Steps to reproduce:
-------------------
- without being logged in, go to ecommerce;
- add the produt to cart;
without information on the tax position, we have:
90.91 + 9.09 = 100 --> this is correct
- process checkout;
- Enter an address with the country France;
France:
90.91 + 18.18 = 109.09 --> this is correct
(100 : (1 + 10%)) * (1 + 20%) = 109.09
- edit the billing address;
- use the country Netherlands;
Netherlands:
104.55 + 20.91 = 125.46 --> this is wrong
instead of:
90.91 + 13.64 = 104.55
(100 : (1 + 10%)) * (1 + 15%) = 104.55
(This is just one example)
Issue:
------
There is inconsistency in the application
of taxes according to tax position.
Cause:
------
To calculate the product's price unit, we apply
tax position mapping via the
`_get_tax_included_unit_price` method.
Modifying the `price_unit` field in the
sale order line will trigger the
compute method `_compute_amount`.
This recalculates the amounts,
but without taking into
account the tax position mapping.
We therefore use a value for the `price_unit`
field which is not in line with the taxes.
Solution:
---------
Recompute sales order line taxes
when a change in fiscal position is detected.
opw-3318971
closesodoo/odoo#129440
X-original-commit: cdb9819b0e199f95d489e8cfe4217cf6de6362b3
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Co-authored-by: Feyensv <vfe@odoo.com>
With an mx company setup
Create Invoice
Validate CFDI
Click "Send & Print"
Issue: xml not in attachments
In e9e9081 FW-port for saas-16.3
`_get_default_email_attachment_data`
method was removed
opw-3419746
closesodoo/odoo#129414
X-original-commit: 1001f6b5c007360ad2ecd5408cad78a744bf3d36
Signed-off-by: Laurent Smet (las) <las@odoo.com>
Signed-off-by: Andrea Grazioso (agr) <agr@odoo.com>
Before this commit, when editing subtype of a follower
(click on pencil icon to edit), the subtype dialog was
displayed while keeping the follower list dropdown open.
This happens because `FollowerList` makes use of
`Dropdown` and `DropdownItem`, and by default they manage
closing of dropdown item when clicking away of when clicking
on the dropdown item. However, when there are specific clickable
elements on the `DropdownItem`, the clicks do not auto-close the
dropdown menu.
This commit fixes the issue by specifically close the dropdown menu
when clicking on edit button of a follower in follower list.
Task-3435443
closesodoo/odoo#129413
X-original-commit: a33f60356ba7c12bd854eb0efe5c653ff1559495
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Before this commit
==================
When creating a BOM through a MO (form view), the WO expected duration is reset
to the default value on the source MO as well as the corresponding Operations in
the BOM.
Steps to Produce
=================
- Create a MO with 1+ WOs and set an expected duration for the WOs.
- Generate a BOM through the MO and observe the changed duration after saving
the BOM
After this commit
=================
After this commit the operation/WO duration doesn't reset to default values.
task - 3414446
closesodoo/odoo#129390
X-original-commit: 05d0dc26e24f24107a5e443dc9ccafd0ff7a1af9
Signed-off-by: Tiffany Chang <tic@odoo.com>
Prior to this commit,
```xml
<t t-elif="days gt 1">In <t t-esc="days" /> days</t>
```
resulted in two separate translations: “In” and “days”.
This commit fixes the problem by explicitly putting the full text in a
gettext.
closesodoo/odoo#129388
X-original-commit: d278fc234540120e86733c2131515a5223d92c87
Signed-off-by: Louis Wicket (wil) <wil@odoo.com>
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
The title of the “Developer Tools” section of the settings is not
translatable. This is because the extractor ignores nodes that are OWL
components. This commit solves the problem by moving the text to be
translated elsewhere.
closesodoo/odoo#129386
X-original-commit: e91370aed41847f9c89bb6ab590f929e6935ac12
Signed-off-by: Géry Debongnie <ged@odoo.com>
Signed-off-by: Louis Wicket (wil) <wil@odoo.com>
Before this commit, when using Odoo with many tabs and when posting
a message in a DM chat, the other tabs had an alert as if we received
a new message from someone else.
This happens because the condition to trigger a new message alert
were not considering the author of message, thus any new message in a
chat where triggering the sound. This only happens when many tabs
were open, because somehow the tab is sometimes not considered in
focus.
There are likely some corner-cases with `isOdooFocused` where it's
not properly syncing among tabs are wrongly considered as
out-of-focus. This bug of out-of-focus, while more delicate to
understand and fix it, is not critical and thankfully is not a
necessity to fix this problem on receiving self-messages in chats.
opw-3425658
closesodoo/odoo#129361
X-original-commit: f59805825c55663f7381204da8f0bdfe63ccd1d8
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Signed-off-by: Matthieu Stockbauer (tsm) <tsm@odoo.com>
This commit revert the changes from this PR https://github.com/odoo/odoo/pull/127377
Before this commit:
Chat window shows all 7 rtc buttons due to this the alignment of the button
is not set because there are way too many buttons.
After this commit:
This commit fixes the issue by showing only 5 buttons Mute,Deafen,Video,More,
Close call and other 3 buttons will moved in expandable More menu.
The testcases were changed accordingly.
Task-3346085
closesodoo/odoo#129360
X-original-commit: 909fb073eada42ff22c4ef4b20b44dc5536b250e
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Before this commit, the message actions "Add to Favorite" and
"Mark as Unread" were shown in the Discuss public page For guests.
These buttons should not be present in public page for guests,
as they both require at least the user being authenticated.
This commit fixes the issue by not showing these 2 actions
"Add to Favorite" and "Mark as Unread" on messages in the Discuss
public page as guests. Internal users can still see both features
in the public page
Task-3430586
closesodoo/odoo#129359
X-original-commit: b551f8799ccee443fc0c6a1e8d4a5e2b8e673c57
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Signed-off-by: Matthieu Stockbauer (tsm) <tsm@odoo.com>
Some groups don't have a total_count, ignore them to avoid NaN result.
This is the case of calendar meeting in particular.
closesodoo/odoo#129358
X-original-commit: f29c4f905a557bef1120ea6ea8af2edf3af93489
Signed-off-by: Olivier Dony (odo) <odo@odoo.com>
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Before this commit:
When format styles were applied to the word table, it would break table.
After this commit:
Now, when format styles are applied to a word table, the style will be applied to it
without breaking the table.
task-3165767
closesodoo/odoo#129356
X-original-commit: 0b06ba23aa111f6a85929abe8018b6b18da79873
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Set Document Layout to "Light" (the default)
Print an Invoice
Open in chrome (tested in Chromium Version 114.0.5735.198)
Issue: border right after table header is still visible
Note: It is reader dependent, as it may not occur with other browser or pdf
reader
opw-3324785
closesodoo/odoo#129275
X-original-commit: 28eedfeec2531c0ebfbdeb4024abad967d450a0d
Signed-off-by: Andrea Grazioso (agr) <agr@odoo.com>
Steps to reproduce:
- Install l10_ch
- create a journal entry with account 9991 or 9992
- go on the general p&l and compare it to the swiss p&l
Issue:
The results won't be the same
Cause:
The accounts 9991 and 9992 are not taken into account into the swiss expenses.
The `CH_4` only takes into account accounts with code `4 <= x < 5`.
https://github.com/odoo/enterprise/blob/bd43cba9e7b5bdbab6319ae1a90e8bf3a8960c15/l10n_ch_reports/data/account_financial_html_report_data.xml#L416
Therefore accounts 9991 and 9992 won't be take into account.
Solution:
When initialising the localisation, we change their code so they fit in the range of `CH_4`
opw-3210100
closesodoo/odoo#129238
X-original-commit: 0896fbb0957060c82bf0f08deef167f866e63cc0
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
before this commit, the window title is
shown as http_error,error_message and
http_error_debug
after this commit, clean window title will
be shown to end user
closesodoo/odoo#129083
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Before this PR, 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 PR 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 PR 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
closesodoo/odoo#114024
Related: odoo/enterprise#43125
Signed-off-by: Géry Debongnie <ged@odoo.com>
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>
_askChanges doesn't apply on a single record, it asks all fields
of all records of the current model to send their changes, so it
makes more sense to have this function on the model instead.
Part of task~3179751
Part-of: odoo/odoo#114024
With this commit, we ensure that the resId of a Record datapoint
never changes. The only exception is for new records: their resId
can go from `false` to their actual id when they are created. When
we want to load another record, we must use the `load` function of
the model, which now accepts `resId` (and `resIds`) as param, when
the root is a "mono record".
As a consequence, the instance of record datapoint now changes when
using the pager. This required some changes in the AceField, to
make it properly react in that case. We took the opportunity to
simplify its implementation (several keys in the state were useless).
Part of task~3179751
Part-of: odoo/odoo#114024
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
Odoo's Mergebot