Before this commit, changing the model on an existing xml-id may lead to
strange results.
create any record in xml, ie: id=my_xid, model=new_model
=> Odoo will create a new external_id, pointing to (new_model, id=1)
change only the model in the xml, ie: id=my_xid, model=ir.cron
=> Odoo will use the id of the existing external_id with the new model
and points now to (ir.cron, id=1)
AND REPLACE the ir.cron id=1 (autovacuum_job) with the data of the xml.
This commit simply prevent that by raising when trying to recycle the
same xmlid for another model. An explicit upgrade script to remove the
existing xmlid and corresponding records should be write.
closesodoo/odoo#83422
Signed-off-by: Raphael Collet <rco@odoo.com>
Steps to reproduce the bug:
- Have company A and B
- Create a pricelist A with company A and pricelist B with company B
- Select company A as current company and B as allowed company
- Create contact A without linked company
Problem:
You can select pricelist B while the current company is A, this causes an access error if you save and only select company A in the selector.
It also causes an error when you open a new POS session.
This contact is not linked to a company, so it should be accessible from all companies.
Solution:
Add a domain to allow the user to only select the pricelist linked to the current company or a pricelist that are not linked to a company
opw-2745267
closesodoo/odoo#83537
X-original-commit: 9f79c62fa56a1bb92ea3fc79fd82431bf9041d5c
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
Step to reproduce:
- Go to ‘my profile’
- Action "assigned tasks"
- Create task
Current Behaviour:
- Traceback because default assignee is not correclty set up
Behaviour after PR:
- Correct default assignee
- No traceback
opw-2742199
closesodoo/odoo#83539
X-original-commit: a80bb0c0312e07d233d01f9196ee040e07cffc83
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
This commit accomplishes multiple objectives:
1. Loading of model data for the POS UI is now done in single
request (with some exemptions).
2. Backbone.js is removed and is replaced by reactivity.js
authored by the js framework team.
3. Better organization of assets in the `__manifest__.py`
Data Loading
------------
One request per model -- that's always been how the data is loaded
in POS UI. Now, we move the aggregation of data to the backend which
simplified the data loading. In the frontend, data loading is
initiated in `load_server_data` which makes the single rpc call
to the `load_pos_data` defined in `pos.session` model.
There remains some rpc calls during loading but the number is
greatly reduced.
This change result to faster loading of the POS UI. However,
there is no more progress bar during the loading.
Notable entry points:
- .js: `PosGlobalState.load_server_data`
- .py: `pos.session.load_pos_data`
It is possible to make customizations in the loading, but is done in
several steps:
1. Override `_pos_ui_models_to_load` to include the new model to load.
2. Define `_loader_params_<model_name>` to define the `search_params` and
optional `context`.
3. Define `_get_pos_ui_<model_name>` to return the data that will be
included in the full `loaded_data`. Perform the organization in this method
whenever necessary.
4. Override `_pos_data_process` for further post processing. The final
form of `loaded_data` in this method will be sent to the frontend.
Removal of Backbone.js
----------------------
POS is no longer dependent from `Backbone.js`, but it's replaced by a
new dependency -- `reactivity.js`. It's invented by the js framework
team which will be available in owl v2.
The consequences of this change are the following:
1. The old `PosModel` is renamed to `PosGlobalState`.
2. The name of the other models are kept (except Paymentline which
is renamed to Payment).
3. The name `PosModel` is now used as the base model of the data models.
This is symmetric to our use of `PosComponent`.
4. The instance of `PosGlobalState` is made reactive in `Chrome` (the
root component). As a result, whatever mutation made in that instance,
`Chrome` will rerender. But rendering is batched so multiple mutations
in a single sychronous function call will only result to a single
render call.
5. `PosModel`s can be extended in the `Registries` the same way as we
extend the `PosComponent`s.
```js
// E.g.
Registries.Component.extend(Chrome, PosResChrome);
Registries.Model.extend(Order, PosResOrder);
```
Reorganization of assets declaration
------------------------------------
This is a simple change that replaced the explicit enumeration
of loaded .js and .xml files. Also, we now have regions in the
manifest separating:
1. Augmentations of dependencies
2. Assets for `point_of_sale.index`
3. Assets for the qunit test (soon will be improved)
Other notable changes
---------------------
- Automatic call to `Order.save_to_db` is batched.
- Instances of `devices.DeviceProxy` (`proxy`), `devices.JobQueue`
(`proxy_queue`) and `BarcodeReader` (`barcode_reader`) are moved
to `point_of_sale.env`. Together with `posbus` and `posMutex`
(previously `flush_mutex`).
- `ActivePrograms` is now passed a props.
- `cashier` is no longer saved to `localStorage`.
- `pos_cache` is overhauled.
- `cache` is taken out from `PosDB` to prevent infinite rendering
loop whenever `cache` is mutated. It's now called `CACHE` in
the `db.js` file.
- reactive version of `posmodel` is exposed globally when in debug mode.
This means that calling when calling a mutator, the UI will react.
- Added control buttons in the `ProductScreen` is sorted during `Chrome`
setup. As a result, we don't need to worry on the loading order of the
control buttons components.
- Model can be simply instantiated using `BaseModel.create(obj)`. This
takes into account the extensions.
- `pos_coupon`: rewards are now updated whenever set_order is called.
- Component unit tests were removed. It wasn't useful and it just blocks
the development. We'll be introducing better unit testing later.
closesodoo/odoo#82461
Related: odoo/enterprise#23344
Signed-off-by: Masereel Pierre <pim@odoo.com>
Co-authored-by: Jacky (trj) <trj@odoo.com>
Since [1] when web's owl services were made available to the frontend,
the navigation mixin does conflict with the hotkey service.
E.g.: navigation mixin consumes the 'alt' keyup event, which prevents
the hotkey service from cleaning up the hotkey overlay.
After this commit the old mixin is neutralized and hotkeys in website's
pseudo-backend layer are handled by the general hotkey service.
Also since [2] the menu items are inside `<div>` instead of `<li>`,
adapted the scss to take this into account.
Also added a CSS rule to neutralize the outline on website's menu
dropdowns which are `<a>` instead of the already handled `<button>` in
web.
[1]: https://github.com/odoo/odoo/commit/db7b485d984e50fae5a52308634166460e5fc908
[2]: https://github.com/odoo/odoo/commit/84715436d87bb05b421bc9ccaacda67d07571690
task-2738578
closesodoo/odoo#83529
X-original-commit: 88438fa9b363530aa4e5dec5599c1568fb7ccea0
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Notification handling in some acquirers presents a subset of the
following issues:
1. The signature of synchronous notifications (redirect payloads) is not
checked. (Alipay, Authorize, Buckaroo, Mollie, PayU money, PayULatam)
2. When the signature check fails, we raise a ValidationError which
counts as an HTTP 200 for some providers (it's not the case if they
expect a specific string). (Adyen, Paypal, Sips, Stripe)
3. If a ValidationError is raised when processing the feedback data, it
is allowed to bubble up to the provider. (Alipay, Ogone)
The issues are respectively addressed as follows:
1. If the acquirer implements payments with redirection, make sure that
if either makes a request to the provider to validate the data or
that it verifies the signature. Verifying the origin of the request
is not enough: the payload must be checked too.
2. Instead of raising ValidationError's, raise an HTTP 403 FORBIDDEN
error if the signature check fails.
3. Wrap the call to `_handle_feedback_data` of the webhook method inside
a try/except clause to catch any ValidationError, log a warning, and
acknowledge the notification to avoid having the provider disable the
webhook because of too many failures.
task-2688139
task-2693293
closesodoo/odoo#81607
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Co-authored-by: Lucie Van Nieuwenhuyze <luvn@odoo.com>
Before this commit, after removing a snippet followed by a popup in the
DOM, the popup options were displayed while the popup was closed.
Indeed, selecting the next snippet after one's removal is a feature that
was introduced by [1] but did not consider that the next snippet could
be an invisible one (like a popup).
[1]: https://github.com/odoo/odoo/commit/2cdd95f140b6ec5f3b95ee19bde2f281de21f337
task-2735551
closesodoo/odoo#83512
X-original-commit: cc802d33885700543c753558dc40cc07d971f87f
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Before this commit, when we selected a variant of a product and then
clicked on a share button, the changed variants attributes in the shared
URL were not considered.
This commit also takes the opportunity to convert the whole file to new
Odoo modules and stopped using jQuery. The code actually had to be
refreshed following the merge of [1] so it was a good occasion to do it.
[1]: https://github.com/odoo/odoo/commit/8f7c6997e8ab381563a9fa8d06feef4e89fff4aa
task-2122733
closesodoo/odoo#83503
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Co-authored-by: qsm-odoo <qsm@odoo.com>
In the calendar UI, the avatars ratio has been edited differently with
the original
closesodoo/odoo#83494
X-original-commit: 81875cf0d0b2db5e2b2e0e70178d5ea04bdd509b
Signed-off-by: Michaël Mattiello <mcm@odoo.com>
Purpose
=======
This field is used for several things, like the simple holiday pay recovery.
Normally, we expect the HR officers to create a new employee, instead of
unarchiving the old one, but this could happen.
If someone leaves the company, and come back, take the new entry date as
first contract date instead of the original one.
closesodoo/odoo#83493
Taskid: 2745947
X-original-commit: a17c601fffca149a5c4d7be2924fb581ae408299
Related: odoo/enterprise#23790
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
- Remove "subtotal" amounts from headings.
- Pull GST only and G20 in under purchasing header.
- Remove tag from comparison heading, as it should have no links to audit.
- Add summary section, to make G9 and G20 transfer to 1A / 1B as per ATO
suggested formatting, and to make those figures easier to find on the
report.
closesodoo/odoo#83380
X-original-commit: 1c184391d545298b9b38d4935a6e457ba7674f43
Signed-off-by: William André (wan) <wan@odoo.com>
Before this PR, AttachmentBoxView required a Chatter to have an
AttachmentList. This model is wrong since the attachmentBoxView can direcly own
the AttachmentList.
task-2740183
closesodoo/odoo#83337
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
OWL-2 is in preparation and will be soon merged. One of the changes it
will bring is that it will be no longer possible to use the directive
t-ref on a tag component. Here we refactor the code in order to remove
two uses of such t-refs.
closesodoo/odoo#81984
Related: odoo/enterprise#23464
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
OWL-2 is in preparation and will be soon merged. One of the changes it
will bring is that it will be no longer possible to use the directive
t-on on a tag component. Here we refactor the code in order to remove
one use of it in the action service.
Part-of: odoo/odoo#81984
[1] has changed the summary structure of an order. To avoid any issues
during the deployment, we added some instructions to remove the old
summaries. Now, these instructions can be removed.
[1] 911a178c99fe56c5f644083a0bb5e992a11f34ed
closesodoo/odoo#83481
X-original-commit: 1638b3490d8fb44a6b57d6168e5e74e567f0fd50
Signed-off-by: Masereel Pierre <pim@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
When creating a new working calendar, its timezone is set to the one of the user creating the record.
However, when first installing the resource app, the timezone of the default working calendar is always UTC regardless of the timezone of the users.
To fix this, this commit sets the timezone of the default working calendar to the timezone of the admin instead.
Task 2744201
closesodoo/odoo#83480
X-original-commit: 2ddddd0253db402542ab6359026888acd61c2464
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Simplify SCSS and use direction-relative margins to handle RTL layouts.
Part of the overall v16 SCSS optimization/restyle (task-2704984).
task-2731819
closesodoo/odoo#83036
Related: odoo/enterprise#23605
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
This commit defines an arbitrary `min-width` aiming to achieve a
perfect(ish) circle when a badge contains only one character.
The badge extends as usual when more characters are rendered.
This commit addresses also an issue caused by margins defined globally,
while necessary to handle m2m field only.
Part of the overall v16 SCSS optimization/restyle (task-2704984).
task-2731819
Part-of: odoo/odoo#83036
This prevents memory issues on creating massive amount of records.
For example, on populating `account.move` table,
the process takes 10 time less memory, while execution time per batch is almost the same: ~1 minute.
closesodoo/odoo#82875
Signed-off-by: Raphael Collet <rco@odoo.com>
To apply shapes on images, we need to store them (in base64) inside the
shape SVG, but before that, we need to use 'applyModifications()' to get
the dataURL that contains the image with applied filters and size
options...(see ImageOptimize > _writeShape). But since we can't handle
GIFs on applyModifications(), we get a single frame of the animation as
a result...
The goal of this commit is to skip the updates from 'applyModification()'
(when the target is a .GIF) and only apply the shape.
This way, other "data-attributes" options should be disabled for GIFs
and only shapes option is allowed.
task-2679905
closesodoo/odoo#79330
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Like in debug mode on optional field on tree view, show technical name on export view.
closesodoo/odoo#73898
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Users with Swiss localization have a possibility to create QR_Bills from their invoices, however, PoS currently does not send information about partner_bank_id to the generated invoice, so users can not create
QR_Bill from the invoice that was created by PoS. After this commit, function _get_partner_bank_id will get partner_bank_id in case customer didn't pay for the order fully, and this information will be added to
the invoice, thus, giving user an ability to create a QR-Bill from said invoice.
In case user will try to create a QR-Bill from the invoice that has been fully paid, they will get an error saying that QR-Bill can not be generated on paid invoices. If the user tries to generate QR-Bill from
the invoice that has empty partner_bank_id, they will also get an error notifying them that they should check Recipient Bank field on the invoice.
OPW-2695969
closesodoo/odoo#83456
X-original-commit: 634f90a728cba9ff45c17e471f2b160e939bbd3d
Signed-off-by: Masereel Pierre <pim@odoo.com>
Current behavior:
When creating a gift card in a PoS the price was reset to 0 when modifying the customer
Steps to reproduce:
- Set PoS gift card mode in Generate a new barcode and set a price
- Modify the current customer
- The price of the gift card is reset to 0
opw-2666917
closesodoo/odoo#83452
X-original-commit: ffc2e11e92a5b528fa2cda855ecdf1d83a54f4bb
Signed-off-by: Masereel Pierre <pim@odoo.com>
Purpose
=======
Less secured apps are no longer supported by google, therefore, we need
to transition to the OAuth2 authentication system.
Specifications
==============
1. User will need to fill their Gmail API credentials in the main
settings page
2. Then, in the incoming / outgoing mail server form view, they will
need to tick the Gmail support checkbox
3. A link will be available to be redirected to Gmail and accept the
permission
4. The user can now copy / paste the authorization code in Odoo, set
his email as "login" and then send / receive emails with Gmail
Task-2170676
closesodoo/odoo#83424
X-original-commit: ff223afc5300b2421b8ce935bb468f503c938c5d
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
The action server is only available on view list. It is hard to find this.
closesodoo/odoo#83455
X-original-commit: 2fa29557d048e43bc9ed0a9fc9047de203b0c4f0
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Before this commit: static XML templates could only be defined on the
file system, and called by manifest assets or ir.asset records.
Attachments were not taken into account when evaluating static
templates.
Now, if a given path does not match a file on the system, an
additional check is run on ir.attachment records instead of failing
directly.
Task 2715333
closesodoo/odoo#83438
X-original-commit: e022c4bfafa77f1a3433c3b980631510af696ade
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Signed-off-by: Julien Mougenot (jum) <jum@odoo.com>
Whenever we clicked on a link that contained another element
(eg. span, bold, ...), the LinkTool did not open.
Task-2667989
closesodoo/odoo#83437
X-original-commit: d69d26a2dd8830aca8c5922d3548e5ff59c688fc
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Those steps were removed with [1] to avoid a indeterminist timeout, but by
doing so that part of the feature was not tested anymore.
Sadly, it was broken by [2] without being noticed for a long period of time.
The error was discovered by fixing multiple lang issues in the website
configurator in master.
Note that by creating a new lang instead of using an existing one will avoid
the timout error that lead to the removal of those steps with [1]. Indeed, as
no .po files will be found for that lang, it won't spend time on processing
those files.
[1]: https://github.com/odoo/odoo/commit/a15c7099a36a3a5b4dca9375b233cbe3fe2a280f
[2]: https://github.com/odoo/odoo/commit/745ef9de97544d5c1a97e03be67e903feca40c2aclosesodoo/odoo#83420
X-original-commit: 0b43f52116fd9a58fb0a123db576d822fd541043
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Since [1] the redirection supposed to happen after a lang install from the
frontend was broken.
Indeed, the 'url_return' was moved and used before it is actually set.
[1]: https://github.com/odoo/odoo/commit/745ef9de97544d5c1a97e03be67e903feca40c2a
Cheers to @jke-be which did the same fix in another branch in parallel.
X-original-commit: 74a594bb2e68662b22477fcce24d9620b2dd0b2a
Part-of: odoo/odoo#83420
On runbot database can be create concurently by other builds, meaning
that the teardown may fail randomly if a database is create between
setup and teardown. Filtering on the dbfilter in all case may miss some
errors but will be enough in this case.
closesodoo/odoo#83414
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
Steps to reproduce the bug:
- Activate packaging in inventory configurations
- set the product UOM digits to more than 2 decimals
- Create a storable product:
- Go to inventory tab > Packaging > Add a line
- Change the contained quantity to a value with more than 2 decimal places
Problem:
It will round it to 2 decimal places regardless of the set digits.
Because the formatFloat function does not receive the digits in parameter, so it uses 2 as default value
Problem:
opw-2723068
closesodoo/odoo#83411
X-original-commit: 144761f07c9de53aaeb7e1468e017eee17cbacd2
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
Current behavior:
When creating a gift card in PoS you are not able to use it in the eCommerce website
Steps to reproduce:
- Activate gift card in PoS, in Generate barcode mode
- Create a gift card in the PoS
- Try to use this gift card in the eCommerce website
- You get an error "expired or not valid"
opw-2727404
closesodoo/odoo#83354
X-original-commit: 26112a57cd2ce1726af1b10f24305595d3f4d0be
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Engels Robin (roen) <roen@odoo.com>
Current behavior:
When changing the type of a payment journal used in a cash payment method you couldn't close a PoS that used this payment method
Steps to reproduce:
- Point of Sale > Configuration > Payment Methods
- Select 'Cash' payment method, go to journal 'Cash', edit the type to 'Bank'
- Go to a Pos session, then try to close it.
opw-2732933
closesodoo/odoo#83343
X-original-commit: 43b64a78888d5b79d87491caf1401964228809fc
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Engels Robin (roen) <roen@odoo.com>
In order to anticipate an anomaly in the network to prevent
a save, wait for an rpc to finish.
task-2742008
closesodoo/odoo#83103
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Upon save in website or in mass_mailing, if a `cleanForSave` of a
`SnippetEditor` or a `SnippetOption` wait for the end of an
`this._rpc()` request AND the `SnippetEditor` or the `SnippetEditor`
of the `SnippetOption` has a `SnippetEditor` ancestor, the
`cleanForSave` will never resolve.
Here is the scenario:
- **SnippetEditor B** has **SnippetEditor A** as its odoo widget parent
In `SnippetMenu` `_destroyEditors`:
- **SnippetEditor A** and **all its SnippetOption** call `cleanForSave`.
- **SnippetEditor B** and **all its SnippetOption** call `cleanForSave`.
One of the promise of **SnippetEditor B** includes the result of
`rpc()` in `ajax_service.js`.
- **SnippetEditor A** and **all its SnippetOption**
`cleanForSave promises` resolve (but not **SnippetEditor B**).
- **SnippetEditor A** get's destroyed (`snippetEditor.destroy()`). As
**SnippetEditor B** is a `Widget` child of **SnippetEditor A**:
- **SnippetEditor B** get's destroyed (here is where the problem start).
... in the mean time ...
The ajax request of a promise of **SnippetEditor B** ends. The promise
of the `rpc()` will never finish because **SnippetEditor B** is
destroyed and the condition in `rpc()` is:
```js
if (!target.isDestroyed()) {
resolve(result);
}
```
Because the promise will never finish for `_destroyEditors`, the save
action will never fully complete.
Task-2742008
Part-of: odoo/odoo#83103
Before this commit, to aaccess some values of the DeliveryPackage
objects, we needed to take the value from the related picking. for
example, for the `payment country code` linked to the package, we need
to retrieve the value from the related picking or order.
To avoid passing too much data to the request objects, it is convenient
to be able to access to the order/picking related to the package
directly from the package.
Because these objects are not children of odoo.models.Model, I do not
need to follow the convention for the names, however, calling the
picking > picking_id in the DeliveryPackage suggests that the picking is
actually a odoo.models.Model child, which should be the case if it
exists.
reference-branch= https://github.com/odoo-dev/enterprise/tree/master-dhl_add_commercial_invoice-goaclosesodoo/odoo#83404
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Whenever the layout of the shop when editing the /shop page,
all the elements mutated from _onApplyShopLayoutChange
became dirty but shouldn't have as there is no intention to
save those mutations.
Task-2676809
closesodoo/odoo#83398
X-original-commit: aca32bc0ab670221ea885cf8c17e7449255f1458
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Before this commit, when trying to paste an url, the editor was
properly creating a link but did not create a step in the history.
So when the user hit enter just after the paste, the last link
insertion was reverted.
Task-2720366
closesodoo/odoo#83396
X-original-commit: 0e37742d3caba1c6544e5b466503f155626375eb
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Before this commit, a traceback occured when trying to remove a popup
snippet, only if content inside was clicked on before (base case but
that last part was not covered by our main test which drags and drops +
removes all snippets).
The problem is complex and annoying to solve in stable. The cause is the
combination of [1] and [2]. Indeed, with [2] we solved the snippet
activation flow to ensure the onFocus and onBlur methods are called when
needed... but that new correct implementation relies on the fact that
the number of snippet editor instances does not change for the whole
async operation of activating a snippet. That should naturally be the
case but is not because of [1]: when we remove a snippet we first
trigger a snippet activation then destroy the snippet (and its editor
instance)... but the snippet activation is not awaited at the moment.
Thus making the snippet editor instance be destroyed *during* the
snippet activation flow. Of course a better solution than this commit
must be found but this fixes the traceback with a very minimal change
for the 15.0 stable version while waiting for that miraculous solution.
[1]: https://github.com/odoo/odoo/commit/ae219ec06baf0280c76ae09b1453cc1481eece30
[2]: https://github.com/odoo/odoo/commit/0acc5e784b15d9c963660da3781763448503f33e
task-2735663
closesodoo/odoo#83378
X-original-commit: da7c1b5757a7780897c5736ddecc014a7fb50bdb
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Steps to follow
- Use an odoo instance without the planning app
- Go to the survey app > feedback form
- Click on "See results"
- Print the document with your browser
-> The output only contains the first page
Cause of the issue
A height of 100% is set to the html element
It works with the planning module because this css is present
https://github.com/odoo/enterprise/blob/ead53fcca721aaa06619b4113707cae3fe086731/planning/static/src/scss/planning_calendar_report.scss#L57-L60
Solution
Unset the html height property in the survey layout
opw-2724319
closesodoo/odoo#83370
X-original-commit: 2c2f9a13a8251791ea24e93927f9a45e8dda2c14
Signed-off-by: Hubert Van De Walle <huvw@odoo.com>
It is sometimes impossible to unbuild a product because of decimal
values.
To reproduce the issue:
(Enable debug mode)
1. In Settings, enable "Units of Measure"
2. Set the decimal accuracy of "Product Unit of Measure" to 4
3. Set the rounding precision of "Units" to 0.001
4. Create two products P1, P2
5. Create a BoM:
- Product: P1
- Quantity: 3
- Type: Manufacture
- Components: 5 x P2
6. Process a MO with 3 x P1
7. Create an unbuild order UO:
- Manufacturing Order: MO
- Quantity: 1
8. Unbuild
Error: An error message is displayed "The quantity done for the product
"P2" doesn't respect the rounding precision[...]"
At some point, for each SM associated to the UO, the modules uses the
value of `product_uom_qty` to write the done quantity of the SM. The
rounding of `product_uom_qty` is based on "Product Unit of Measure" so
the component's SM has its quantity equal to `1.6667`. Moreover, writing
the done quantity trigger the creation of the associated SML. As a
result, the SML has its done quantity equal to `1.6667` while the
rounding of the associated UoM is `0.001`. When calling `_action_done`
on such a SML, it will raise an error because the value doesn't respect
the rounding.
Side note: the error message is incorrectly written, the indents in the
file are displayed on the front-end.
OPW-2710038
closesodoo/odoo#83369
X-original-commit: c11d772f39179c5dec5eb431b6f4bc02c680643a
Signed-off-by: Adrien Widart <awt@odoo.com>
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Part of the overall v16 SCSS optimization/restyle, task-2704984.
task-2731819
closesodoo/odoo#83092
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Benjamin Vray