Issue: create 60 lines in ordered x2many with the same value (0) for the order
field and make a change ; the displayed records will be switched.
The problem appears because the sorting function is not stable and the
records with the same values can change place (hence change page), which is
quite disturbing for the user.
Two attempts of dealing with sorting (and resequencing) in tabbed (multi-pages)
x2many editable lists (see odoo/odoo@c2563db and odoo/odoo@983c7ae) have been
previously done, using a static attribute (`keepChangesUnsorted`) on the
datapoint.
This solution sadly only covers both cases separately, not if they are combined.
Morever, onchanges were not correctly managed in neither of these two cases.
A new approach is used here, by "freezing" and "unfreezing" the datapoint when
needed, which is more flexible.
Some modifications have been introduced:
- when ordering a x2many, all records are now considered (and not only the
records on the current page) ; an additional read is thus done on the sorted
field for all records in the x2many relation
- `setSort` is now asynchronous as a `read` might be needed
This was broken in 11.0 if the media dialog was the first dialog to be
opened when using the editor. This happened for two reasons:
- Never use a widget (dialog)'s `$el` before it is started (opened).
This was the case here. The bug is even worse in saas-11.1 as we do
not allow to do that from there so it results in a JS crash.
- It worked in <= saas-16 because dialogs were started at once as they
did not need to load anything. In >= 11.0, the first dialog which is
opened in the page needs to request the main dialog template and this
takes some time.
So, this fix makes sense in >= 9.0 but I chose to merge it in 11.0 as it
only induces a real bug from there.
Before this commit, the user had the ability to scroll horizontally
on some form views containing chatter.
This horizontal scroll only appeared in mobile (Android and iOS) but
it wasn't useful.
In many cases, we allow class and style attributes in the arch of a
view. However, it did not work in a list view, and there is not really
a good reason for that (only cost is a few runtime checks).
So, with this commit, we allow those attributes in list views (and
x2manys obviously).
However, note that there is a subtle (maybe slightly confusing)
behavior: when a list renderer is in 'readonly' mode, it does not
actually instantiate any field widgets. In that case, it optimizes the
rendering by putting only the formatted value inside a cell:
<td>some value</td>
So, in that case, the only valid target for the attributes is the td:
<td class="hello">some value</td>
But when we are in edit mode, we actually have a field widget inside a
td:
<td><input>some value</input></td>
And in that case, the natural home for the attributes is the field
widget. This is quite important, because this is the way attributes are
done in the form view, and we do not want different behaviour.
<td><input class="hello">some value</input></td>
When creating an SO for a service that create a new Task in a Project, the customer
email field is left empty.
With this commit, the email field is filled with the SO customer's
email.
opw-803566
install delivery
Create a SO with a shipper
Validate it
validate the delivery
Before this commit it was:
- impossible to do the setup for the delivery cost on the SO to get updated with the delivery validation
- the delivery cost on the SO did not update
This was because the stock API changed a bit a some functions were not here anymore
OPW 786500
- Install a new db with demo data and sale_stock module
- Set rounding for product unit of measure from 3 to 5.
- Run sale_stock tests (from command line with --test-enable)
Current behavior:
> FAIL: test_02_sale_stock_return (odoo.addons.sale_stock.tests.test_sale_stock.TestSaleStock)
>
> AssertionError: 3.0000000000000004 != 3.0 : Sale Stock: delivered quantity should be 3.0 instead of "3.0000000000000004" after picking return
>
Fixes#21246
opw-803837
to reproduce:
- have 4 units of product 1 in stock
- create a move for a dozen, reserve it
- try to scrap a single unit
- an exception "cannot reserve more than available" is raised
To reflect the change of reservation after scrapping the quantity, we
have to update the reserved quantity on the move line.
When updating the quantity on the move line, "quantity_split" is in the
quant uom, so it should be converted to the uom of the move line.
- Set a decimal precision for 'Product Price' = 6
- Set a currency precision = 2
- In the product for view, set a 'Sales Price' = 0.123456
The price is rounded to 0.12, while one would expect it to be 0.123456.
We use the decimal precision of the field rather than the default
currency precision.
Fixes#21686
opw-800279
In v10, a `Float` field with `widget="monetary"` option uses the decimal
precision of the field. In v11, however, it uses the decimal precision
of the currency. However, in many cases `widget="monetary"` is used in
the sole purpose of displaying the currency symbol. The precision of the
field sould be kept.
This commit introduces the support of the decimal precision of the field
for this specific use case thanks to the `field_digits` option:
```
<field name="pouet" widget="monetary" options="{'field_digits': True}" />
```
If such an option is used, the field precision will prevail over the
currency precision.
Related to #21686
opw-800279
Previous to this commit, we try to load as many fields as possible
during module installation, however sometimes some fields are not ready
to be loaded, which is the case for custom monetary fields, thus when
trying to find the current model's currency_id field it would not find
it at all, generating an assertion error.
This commit changes this by completely skipping monetary fields if they
are not ready to be loaded.
OPW 787223
In the module website, the relational field website_id is defined twice,
once for ir_ui_view and a second time for res_config_settings, for the
former we perform an ondelete='cascade', which means that when the
website model is unlinked, the field is unlinked as well.
This is not done for the website_id field in res_config_settings, which
instead defaults to setting the field to NULL, which violates a not-null
constraint and therefore causes issues when trying to modify/save
settings.
To solve this, a hard delete of the ir_model_field website_id is
performed during the uninstall process of the website module.
Fixes#21905
OPW 803018
The new settings model loads by default all settings. In the case of
non-admin user having the 'Settings' access rights this can lead to
access errors.
This commit deals with the multi-company issues on a standard
installation. If the admin is in Company A and the other user in Company
B, accessing the settings is pretty much impossible because of records
rules.
This fixes the master or demo data to avoid setting a company by
default. Note that it only fixes a standard installation: if the
settings are later customized, there is no guarantee that it will still
work.
Problematic fields:
`auth_signup_template_user_id`
`crm_default_team_id`
`leave_timesheet_task_id`
opw-801210
Previous to this commit, if a user hadn't properly set up his
Authorize.net credentials, when getting a response from Authorize.net's
servers, we would expect some attributes to be in the response's body,
but this is not the case if the credentials are wrong, thus we would
have an unexpected error like "NoneType object has no attribute text"
which is only a sympton of the real error (bad credentials and no
error-checking).
This is fixed by checking if the response body contains an error
message, if it is the case we raise an UserError with the error code and
the error message (which is only shown if debug mode is activated).
OPW 788261
[FIX] web: Fix column_invisible issue
This commit fixes an issue with the column_invisible attribute.
When we choose product variant for BOM for any particular product,
at that time from the BOM Lines column "Apply on Variants" is hidden,
but when we unset product variant from BOM Form,
at that time the column 'Variants" set to visible. but in this case, it is set to hidden always.
PR 21693, OPW 779555
When
- a user A had set 'notifications handled by Odoo'
- a user B sent a @userA message
Before this commit, the user wasn't notified in the inbox needaction
After this commit, he is
OPW 801315
When confirming a quotation for an MTO product, the state of the
delivery order goes from draft to waiting another operation to waiting
while it should stays in waiting another operation.
If procurement_jit is enabled, confirming a sale order line will
unreserve and rereserve the pickings associated (see
`action_launch_procurement_rule` override). Unreserving a picking will
always set its state to "confirmed", which is wrong if it should be in
"waiting another operation". Not writing on state (which is a computed
field) and let the depends call _compute_state fixes the issue.
The unreserve/rereserve thing is probably useless and is a remain of the
previous stock implementation where it was not possible to complete the
reservation of a move without wiping all its current reservation.
Another commit will improve this part of the code.
opw-801588
- Set the currency rounding to 0.001 (3 digits)
- Create an account move
- Add an account move line, set an account
When switching from edit/read-only mode, the rounding switches from 2 to
3 digits.
This is because, in edit mode, the format method is the method of the
float widget. Therefore, in this case, the formatting doesn't take into
account the currency rounding.
To avoid this, we simply use a `noSymbol` flag to avoid adding the
currency symbol, while keeping the monetary rounding.
opw-800279
When copying a done MO that is unlocked, the new MO is also unlocked and
the buttons to produce/check availability aren't displayed and it is
confusing to the user.
Fixes#20119
Optional bom line havea default `product_qty` of 0. As the "check
availability" button is displayed if the MO is not available and
the `_compute_availability` method considers all move of 0 `product_qty`
as unassiged, the "check availability" button was always displayed and
it was confusing.
Do not consider move with a 0 product_qty in the `_compute_availability`
method to fix the display of the button.
If a row is being edited, this row will be refocused when performing changes
(i.e. resequencing records). It can cause an issue if an onchange modifies the
record being focused.
To avoid this issue, the row is unselected before resequencing records. The row
isn't selected anymore but this behaviour wasn't expected anyway.
Resequencing records with the same sequence wasn't correctly working in the
editable list because we only care about the range between the swapped ids. In
some cases, this isn't good enough.
For example, if we have the records 1,2,3 with sequence field = 10,10,10, then,
swapping records 1 and 2 should lead to resequencing 3 with the sequence values
11,10,12 (to guarantee that the third item is after the previous 2).
Resequence now checks if the list increases or decreases without interruption
to create the subset that must be changed ; otherwise the whole list is changed.
Before this commit, the route to the pager couldn't be resolved
because the <model("xxx.xxx") was having a typo
Now it doesn't, no traceback nor 500 error
OPW 801651
- Create payslip
- Add a contract with any structure
- Add a structure in payslip, different from the one defined in step 2
- Confirm or compute sheet
Payslip is computed using the contract structure, while it should be
computed using the payslip structure.
Closes#21567
opw-787671
Christophe Matthieu