Tuesday, November 22, 2022
39 changes · master
Enhancements to existing features
The documentation now includes guidance for enabling autocomplete when using the Odoo command line. This helps developers and administrators work faster and reduce typing mistakes, with no direct impact on business workflows.
Original PR description
Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Saved payment methods created while a payment provider is in test mode now show a “test token” badge, regardless of which provider created them. This reduces confusion for users by clearly marking test payment details and avoiding reliance on the Demo provider name.
Original PR description
"Demo token" badge is only displayed for tokens created under Demo provider. This is misleadind and should be connected with provider state not it's name. It should be shown on every token created under "test mode". task-2908903 Upgrade PR: https://github.com/odoo/upgrade/pull/4023
This change removes an unused database index on attachment checksums. For large databases, this can reduce storage usage and maintenance overhead without affecting normal search behavior.
Original PR description
Description of the issue/feature this PR addresses: On database with 5 million attachaments, the index of checksum is 250 Mo, but this field is never used to search. @rco-odoo --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The contract history view has been simplified by removing code that supported creating employees from a screen where that option no longer exists. This reduces unnecessary maintenance work without changing the experience for users.
Original PR description
In the hr_contract_history list view, some owl code was set to allow employee creation from that view. Since the create button has been removed, that code was unused.
Resolved issues and error corrections
Bills that create both an asset and deferred revenue now show separate, correctly named smart buttons for each item type. This helps users quickly access the right related records without confusion from a single misleading button.
Original PR description
- Create a bill that creates a deferred revenue and an asset - There is only one smart button with, as name, the first of the deferred revenue or asset. The problem is that the view takes the type of the first asset/deferred revenue/deferred expenses in the move. We have to create a button for each type. We can remove the field asset_ids_display_name as it is now useless. task-2894690
Miscellaneous changes
The `comment` field was not properly displayed since the move to grid display. Forward-Port-Of: odoo/odoo#106175
Original PR description
The `comment` field was not properly displayed since the move to grid display. Forward-Port-Of: odoo/odoo#106175
This update adjusts an internal Discuss performance test so it remains compatible with recent changes in the community edition. It helps keep automated quality checks reliable without changing end-user functionality.
Original PR description
COM PR: https://github.com/odoo/odoo/pull/106188 Fw-port of: https://github.com/odoo/enterprise/pull/34233
This update adjusts an enterprise discussion performance test so it stays compatible with recent community edition changes. It helps keep automated checks reliable, reducing the chance of false test failures during development.
Previously, we had an option on char/text fields called "onchange_on_keydown", which allowed to trigger the onchange while the user was typing (instead of when the field is blurred). It was notably used when typing a phone number in the sms composer, to warn the user that the phone number is invalid. This feature was lost during the port to OWL, this commit restores it. Task-3033107 Forward-Port-Of: odoo/odoo#103552
Original PR description
Previously, we had an option on char/text fields called "onchange_on_keydown", which allowed to trigger the onchange while the user was typing (instead of when the field is blurred). It was notably used when typing a phone number in the sms composer, to warn the user that the phone number is invalid. This feature was lost during the port to OWL, this commit restores it. Task-3033107 Forward-Port-Of: odoo/odoo#103552
This PR - Reverts the change in [#105425](https://github.com/odoo/odoo/pull/105425) as the code is redundant see [Discussion](https://github.com/odoo/odoo/pull/105656#discussion_r1022837632) - Fixes the issue and explain the details as it doesn't get triggered from `inventory adjustment` view but from` current stock `view in location X. Steps to reproduce: - Install inventory - Activate storage locations - Allow import in Locations/WH/Stock/Current Stock - Export the current stock of W
Original PR description
This PR - Reverts the change in [#105425](https://github.com/odoo/odoo/pull/105425) as the code is redundant see [Discussion](https://github.com/odoo/odoo/pull/105656#discussion_r1022837632) - Fixes…
This PR - Reverts the change in [#105425](https://github.com/odoo/odoo/pull/105425) as the code is redundant see [Discussion](https://github.com/odoo/odoo/pull/105656#discussion_r1022837632) - Fixes the issue and explain the details as it doesn't get triggered from `inventory adjustment` view but from` current stock `view in location X. Steps to reproduce: - Install inventory - Activate storage locations - Allow import in Locations/WH/Stock/Current Stock - Export the current stock of WH/Stock - Change the Location in the file to WH/Output - Import the modified file In the `Location/Current stock` view, the _load_records_write/create methods are bypassing the `allowed_fields` checks in the def create/write since this check only occurs when `_is_inventory_mode() = True`. This can cause inconsistencies if there are quants reserved. To solve the problem we set `inventory_mode` to `True` so that the method returns True and the checks are triggered (and prevent these inconsistencies). Task id: 3007499 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#105930 Forward-Port-Of: odoo/odoo#105898
This commit aims to solve the reported issue where printers are switching states from "connected" to "disconnected" and stay unreachable for 2 minutes. Now the available printers will be searched for multiple times before disconnecting them [task 2891909](https://www.odoo.com/web#id=2891909&cids=1&menu_id=4720&action=333&active_id=1428&model=project.task&view_type=form) [Fixes 2687380](https://www.odoo.com/web#id=2687380&menu_id=4720&cids=1&action=3531&model=project.task&view_type=form) [
Original PR description
This commit aims to solve the reported issue where printers are switching states from "connected" to "disconnected" and stay unreachable for 2 minutes. Now the available printers will be searched for multiple times before disconnecting them [task 2891909](https://www.odoo.com/web#id=2891909&cids=1&menu_id=4720&action=333&active_id=1428&model=project.task&view_type=form) [Fixes 2687380](https://www.odoo.com/web#id=2687380&menu_id=4720&cids=1&action=3531&model=project.task&view_type=form) [Fixes 2856101](https://www.odoo.com/web#id=2856101&cids=1&model=project.task&view_type=form) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#103292
When we have too many products from orderpoints we cannot compute the forecasts for all at once. Otherwise we may get a MemoryError. Here we iterate by chunks. This error was observed on upg-417045, where there were 381927 products. Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#106105
Original PR description
When we have too many products from orderpoints we cannot compute the forecasts for all at once. Otherwise we may get a MemoryError. Here we iterate by chunks. This error was observed on upg-417045, where there were 381927 products. Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#106105
Not the main purpose of this PR, but for the related visual improvements: <details> <summary>Before this PR</summary>  </details> <details> <summary>After this PR</summary>  </details> [FIX] website: prevent validation of conditionally hidden fields
Original PR description
Not the main purpose of this PR, but for the related visual improvements: <details> <summary>Before this PR</summary>…
Not the main purpose of this PR, but for the related visual improvements:
<details>
<summary>Before this PR</summary>
</details>
<details>
<summary>After this PR</summary>
</details>
[FIX] website: prevent validation of conditionally hidden fields
Steps to reproduce the issue (see opw):
- Add a form to a page
- Add a checkbox
- Add a second checkbox that is required and visible only if the first
checkbox is not checked
- Save
- Do not check anything and try to send => Good, you can't, the required
checkbox is not set
- Check the second checkbox and try to send => Good, you can, the
required checkbox is set
- Go back to the empty form, check the first checkbox and try to send
=> Bad, you can't but you should: the required checkbox is hidden, it
is not supposed to be required anymore.
(Not that arguably, that two checkboxes setup should be replaced by a
required selection field but the issue of the OPW would remain as there
is another required conditionally-hidden field (a file upload) when the
second checkbox is checked.)
Conditionally-hidden fields should not require validation while they are
hidden. Indeed, their purpose is to be able to enter additional data
when some condition is fulfilled. If such a field is required, it is
only required when visible. The problem only occurred with checkboxes,
the other fields were already working in that case. Although there could
be issues with dates too, this commit added a series of FIXME and TODO
comments as well as some things need to be investigated.
[FIX] website: show invalid checkboxes, radio buttons and file upload
Before this commit, when submitting a website form which has invalid
radio buttons, checkboxes or file upload elements, they had no visual
difference. Now they will have red labels as intended with bootstrap.
For alone checkboxes, a warning label will appear after the checkboxes.
This will only take effects for newly added checkboxes.
[FIX] website: properly align checkboxes in website forms
With [1], checkboxes in website forms were wrapped in a <div/> with the
"form-check" bootstrap class (as they should). That forgot to mark the
checkboxes themselves with the class "form-check-input". Without it they
are misaligned.
This fixes the error for newly added checkboxes in forms. Old ones will
stay "broken".
[1]: https://github.com/odoo/odoo/commit/9ea276ae2f00c3a5ba4e10af313085947e70e265
[FIX] website: show a label for empty selection values
Before this commit, if the user tried to setup a required selection
field whose first value is empty, it was possible but the empty value
appeared as a 0px-height div in the DOM preview. That empty value also
shows up when trying to use the conditionally-hidden fields feature: if
another field's visibility depends on such selection field, the editor
UI was visually broken as the first choice was an empty option element.
Now, we show "<no value>" in both cases.
Note: this is not done in earlier versions than 15.0 although the
problem exists, but it was decided that the real problem was about the
visibility select being visually broken and that feature only appeared
in 15.0.
opw-3003952
Forward-Port-Of: odoo/odoo#106102
Forward-Port-Of: odoo/odoo#105870**Steps to reproduce:** - go to a product page - replace image (=> image is shown) - click on "Save manually" (the cloud upload icon) - BUG: previous image is displayed. But it was saved: if you move to another record and return then it shows the correct one. **Solution:** Basically, in an image_field: If its props.value is a "binary size", then the image source is a url pointing to a server endpoint and this url is based on the rawCacheKey, otherwise, we use the "base64" of t
Original PR description
**Steps to reproduce:** - go to a product page - replace image (=> image is shown) - click on "Save manually" (the cloud upload icon) - BUG: previous image is displayed. But it was saved: if you move to another record and return then it shows the correct one. **Solution:** Basically, in an image_field: If its props.value is a "binary size", then the image source is a url pointing to a server endpoint and this url is based on the rawCacheKey, otherwise, we use the "base64" of the uploaded image. The proposed solution for the said issue is to invalidate the rawCacheKey during upload. Then, during the calculation of image url (at `getUrl`), we reassign the rawCacheKey with the newest "__last_update" value of the record when needed (if the props.value is a "binary size"). --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#105672
Currently, in mass mailing, the user cannot be redirected to the next page after clicking "upload a file" in the import mailing list. This is because the contact list field is mandatory, so when the user clicks "upload a file" with an empty contact list, it is unable to redirect to the next page. This commit fixes the above issue by making the contact list field not mandatory. taks-3070829 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/sub
Original PR description
Currently, in mass mailing, the user cannot be redirected to the next page after clicking "upload a file" in the import mailing list. This is because the contact list field is mandatory, so when the user clicks "upload a file" with an empty contact list, it is unable to redirect to the next page. This commit fixes the above issue by making the contact list field not mandatory. taks-3070829 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#106119
**Issue:** - Open a list view with `expand="1"` and `limit=<arbitrary small number, say 5>`. - BUG: The pager shows that it's displaying the limited records, but in reality, it's displaying all records under each group. **Solution:** This is because we are *not* limiting the number of records being fetch in the first read_group rpc. We are now specifying the expand_limit in this commit. **Illustrations:** Before fix: ![Screenshot 2022-11-21 at 09 26 15](https://user-images
Original PR description
**Issue:** - Open a list view with `expand="1"` and `limit=<arbitrary small number, say 5>`. - BUG: The pager shows that it's displaying the limited records, but in reality, it's displaying all records under each group. **Solution:** This is because we are *not* limiting the number of records being fetch in the first read_group rpc. We are now specifying the expand_limit in this commit. **Illustrations:** Before fix:  After fix:  --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#106126
The job_title field was too narrow and misaligned on mobile. Removed the help text for the Contacts smartbutton. task-3070980 Forward-Port-Of: odoo/odoo#106223
Original PR description
The job_title field was too narrow and misaligned on mobile. Removed the help text for the Contacts smartbutton. task-3070980 Forward-Port-Of: odoo/odoo#106223
Before this commit, going to Apps and then clicking on App Store in debug mode causes a crash. Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#106224
Original PR description
Before this commit, going to Apps and then clicking on App Store in debug mode causes a crash. Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#106224
The wsgi application entrypoint moved during the httpocalypse. Some clients don't use the odoo builtin wsgi server and have troubles upgrading from 15.0 to 16.0 because the `odoo.service.wsgi_server` module doesn't exist anymore. Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#105715 Forward-Po
Original PR description
The wsgi application entrypoint moved during the httpocalypse. Some clients don't use the odoo builtin wsgi server and have troubles upgrading from 15.0 to 16.0 because the `odoo.service.wsgi_server` module doesn't exist anymore. Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#105715 Forward-Port-Of: odoo/odoo#105434
Forward-Port-Of: odoo/odoo#104355
Original PR description
Forward-Port-Of: odoo/odoo#104355
Co-authored-by: Xavier BOL (xbo) <xbo@odoo.com> Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#106051
Original PR description
Co-authored-by: Xavier BOL (xbo) <xbo@odoo.com> Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#106051
Before this commit, new model term translations cannot be saved if it has been translated before. The reason is while translating fr_FR the backend needs the mapping {old_term_fr: new_term_fr} to update old_value_fr However the UI sent {old_term_en: new_term_fr} which was wrong This commit fixes the bug by changing the key of the mapping from the old_term_en to the old_term_fr opw-3074712 Description of the issue/feature this PR addresses: Current behavior before PR: Desired beh
Original PR description
Before this commit, new model term translations cannot be saved if it has been translated before.
The reason is while translating fr_FR
the backend needs the mapping {old_term_fr: new_term_fr} to update old_value_fr However the UI sent {old_term_en: new_term_fr} which was wrong
This commit fixes the bug by changing the key of the mapping from the old_term_en to the old_term_fr
opw-3074712
Description of the issue/feature this PR addresses:
Current behavior before PR:
Desired behavior after PR is merged:
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#106174It is not possible to post the journal entries related to an expense paid by the company Steps to reproduce: 1. Install Expense 2. Create an expense payable to company 3. Set an amount 4. Create report 5. Submit report 6. Approve report 7. Attempt to post 8. An error is thrown Solution: Relax the constraint on account.move.line linked to an expense paid by the company Problem: The constraint `_check_payable_receivable` in the account module forbids to post the journal entries
Original PR description
It is not possible to post the journal entries related to an expense paid by the company Steps to reproduce: 1. Install Expense 2. Create an expense payable to company 3. Set an amount 4. Create report 5. Submit report 6. Approve report 7. Attempt to post 8. An error is thrown Solution: Relax the constraint on account.move.line linked to an expense paid by the company Problem: The constraint `_check_payable_receivable` in the account module forbids to post the journal entries even though they are correct opw-3038648 Forward-Port-Of: odoo/odoo#105850
Since the conversion in OWL of the `many2one_barcode` widget, on Mobile when we open the search more a filter value is added automatically in the filter and so when we want to change the value we need an additional step to remove the filter to see all records. This commit, use a 'custom event' to open the barcode search and restore the normal behaviour on the `click` event. Steps to reproduce: * Go to Timesheet * Add a new line * Select a project * Try to change the project => BUG show
Original PR description
Since the conversion in OWL of the `many2one_barcode` widget, on Mobile when we open the search more a filter value is added automatically in the filter and so when we want to change the value we need an additional step to remove the filter to see all records. This commit, use a 'custom event' to open the barcode search and restore the normal behaviour on the `click` event. Steps to reproduce: * Go to Timesheet * Add a new line * Select a project * Try to change the project => BUG show only the selected project Co-authored-by: Romain Estievenart <res@odoo.com> --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#106158
Commit [1] actually "repair" the test theme installation that was actually not calling `_post_copy()` for the website/themes created through the `_post_init` hook of the `test_themes` module. By doing so, the Nano theme now correctly activated the `footer_language_selector` view, meaning that the tour would fail as this Nano view would mess up with the tour (that Nano view was returned on top of the Theme custo view). Those website standalone tests should really be part of the regular testing
Original PR description
Commit [1] actually "repair" the test theme installation that was actually not calling `_post_copy()` for the website/themes created through the `_post_init` hook of the `test_themes` module. By…
Commit [1] actually "repair" the test theme installation that was actually not calling `_post_copy()` for the website/themes created through the `_post_init` hook of the `test_themes` module. By doing so, the Nano theme now correctly activated the `footer_language_selector` view, meaning that the tour would fail as this Nano view would mess up with the tour (that Nano view was returned on top of the Theme custo view). Those website standalone tests should really be part of the regular testing suite and not in the nightly build only: 1. This is getting really annoying to fix it again and again, we wouldn't have to do that if it was in the regular testing base as it could not be broken. This is a waste of time for no reason, as we need to investigate, understand and find a fix. 2. For now it only broke due to no real bug, most of the time it is because the test need to be adapted to a theme change or something, but one day someone will be able to break the website core mechanisms (COW, theme install etc) and this will be problematic. Note that if this was to happen, the runbot team will be handling the issue and the fix with the people that broke it, as it was promised when we discussed about moving those tests in the regular testing suite. It was the conscensus for us to accept to leave those tests in the nightly only (we didn't really had a choice tho). [1]: https://github.com/odoo/design-themes/commit/fea847977d8bd4b0c0ddfc7685e3d3dc0933759c Forward-Port-Of: odoo/odoo#106026
Steps to reproduce: - install sale_management module; - go to settings of sale_management and check "Automatic invoice" parameter; - in debug mode, we can see the template selected (do not change it); - save the settings; (This is just one example) Issue: The parameter is not added to the "ir_config_parameter" table. Cause: The improvement which consists in comparing the settings which one wishes to record with those which already exist in order to set th
Original PR description
Steps to reproduce: - install sale_management module; - go to settings of sale_management and check "Automatic invoice" parameter; - in debug mode, we can see the template selected (do not change…
Steps to reproduce:
- install sale_management module;
- go to settings of sale_management and check "Automatic invoice" parameter;
- in debug mode, we can see the template selected (do not change it);
- save the settings;
(This is just one example)
Issue:
The parameter is not added to the "ir_config_parameter" table.
Cause:
The improvement which consists in comparing the settings which one wishes to record with those which already exist in order to set the parameters which are different creates a problem.
Indeed, the current settings are retrieved directly from the model with their default value if there is one.
These are the values that will be used for the comparison.
Because of this, when we want to save a parameter which is set to its default value (on first save), the logic will not notice a difference.
Therefore, the parameter will not be saved in the "ir_config_parameter" table.
Consequence:
In the code, when we wanted to look up the value of a parameter, if it is not saved, we use its default value instead of saving it with its default value.
Example:
```
field_example = fields.Integer(string='Example', default=1000, config_parameter='model.field_example')
value_field_example = params.get_param('model.field_example', default=1000)
```
The default value is repeated.
Solution:
To know whether or not we add a new parameter in the "ir_config_parameter" table, we must look at what already exists in the table and not in the settings defined in the model.
opw-3057306
Forward-Port-Of: odoo/odoo#105991Issue : - Liechtenstein adapted the same QR-Invoice as Switzerland. However, Odoo only allows the issuance of QR-Invoices to swiss customers https://www.llb.li/en/private/paying-and-saving/payment-services/qr-bill#:~:text=Standing%20orders%20based%20on%20orange%20payment%20slips%20can%20no%20longer%20be%20processed%20after%2030%20September%202022.%20Therefore%2C%20these%20standing%20orders%20need%20to%20be%20newly%20set%20up%20on%20the%20basis%20of%20QR%20bills. Fix: - Allow LI users to
Original PR description
Issue : - Liechtenstein adapted the same QR-Invoice as Switzerland. However, Odoo only allows the issuance of QR-Invoices to swiss customers https://www.llb.li/en/private/paying-and-saving/payment-services/qr-bill#:~:text=Standing%20orders%20based%20on%20orange%20payment%20slips%20can%20no%20longer%20be%20processed%20after%2030%20September%202022.%20Therefore%2C%20these%20standing%20orders%20need%20to%20be%20newly%20set%20up%20on%20the%20basis%20of%20QR%20bills. Fix: - Allow LI users to be issued QR-Invoices OPW-2977644 Forward-Port-Of: odoo/odoo#106207 Forward-Port-Of: odoo/odoo#100470
Updating the CLA to allow core contributions (e.g. bug fixing) by further developer --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#106246
Original PR description
Updating the CLA to allow core contributions (e.g. bug fixing) by further developer --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#106246
Steps to reproduce: 1-set timezone to Africa/Algiers (or any timezone different from UTC) 2-navigate to field service map view 3-open task the planned date is different Bug: the planned date is displayed in UTC on the map view in V15 and prior date is converted from UTC when openning a marker [1] Fix: convert date feilds to local timezone in map view when loading records opw-2978034 [1]:https://github.com/odoo/enterprise/blob/ca0e30556af35356350d37d389c39f076743d645/web_map/sta
Original PR description
Steps to reproduce: 1-set timezone to Africa/Algiers (or any timezone different from UTC) 2-navigate to field service map view 3-open task the planned date is different Bug: the planned date is displayed in UTC on the map view in V15 and prior date is converted from UTC when openning a marker [1] Fix: convert date feilds to local timezone in map view when loading records opw-2978034 [1]:https://github.com/odoo/enterprise/blob/ca0e30556af35356350d37d389c39f076743d645/web_map/static/src/js/map_renderer.js#L336 Forward-Port-Of: odoo/enterprise#34190 Forward-Port-Of: odoo/enterprise#31539
Issue : - Liechtenstein adapted the same QR-Invoice as Switzerland. However, Odoo only allows the issuance of QR-Invoices to swiss customers https://www.llb.li/en/private/paying-and-saving/payment-services/qr-bill#:~:text=Standing%20orders%20based%20on%20orange%20payment%20slips%20can%20no%20longer%20be%20processed%20after%2030%20September%202022.%20Therefore%2C%20these%20standing%20orders%20need%20to%20be%20newly%20set%20up%20on%20the%20basis%20of%20QR%20bills. Fix: - Allow LI users to
Original PR description
Issue : - Liechtenstein adapted the same QR-Invoice as Switzerland. However, Odoo only allows the issuance of QR-Invoices to swiss customers https://www.llb.li/en/private/paying-and-saving/payment-services/qr-bill#:~:text=Standing%20orders%20based%20on%20orange%20payment%20slips%20can%20no%20longer%20be%20processed%20after%2030%20September%202022.%20Therefore%2C%20these%20standing%20orders%20need%20to%20be%20newly%20set%20up%20on%20the%20basis%20of%20QR%20bills. Fix: - Allow LI users to be issued QR-Invoices linked to: https://github.com/odoo/odoo/pull/100470 OPW-2977644 Forward-Port-Of: odoo/enterprise#34219 Forward-Port-Of: odoo/enterprise#34168
Forward-Port-Of: odoo/enterprise#34149 Forward-Port-Of: odoo/enterprise#34128
Original PR description
Forward-Port-Of: odoo/enterprise#34149 Forward-Port-Of: odoo/enterprise#34128
Forward-Port-Of: odoo/enterprise#33328
Original PR description
Forward-Port-Of: odoo/enterprise#33328
Issue: Recurrence name isn't translated. Since this name is used in several views, including the eCommerce sale renting pages to display pricings, the name should be lang context dependant. This commit handles language to compute recurrence name, using the translated recurrence unit description. Forward-Port-Of: odoo/enterprise#33931
Original PR description
Issue: Recurrence name isn't translated. Since this name is used in several views, including the eCommerce sale renting pages to display pricings, the name should be lang context dependant. This commit handles language to compute recurrence name, using the translated recurrence unit description. Forward-Port-Of: odoo/enterprise#33931
Reproduction: 1. Install Manufacturing, create two storable products test_MTO and test_component, update test_component quantity in stock as 10 2. Go to Manufacturing -> Manufacturing Orders, create a new MO for test_MTO, and use one test_component 3. Mark the MO as done, then click Scrap, fill in the product name and click done 4. Go to Reporting -> Production Analysis, Quantity produced is 2 instead of 1 Reason: the move_id from the scrapped stock moves should be filtered out otherwise,
Original PR description
Reproduction: 1. Install Manufacturing, create two storable products test_MTO and test_component, update test_component quantity in stock as 10 2. Go to Manufacturing -> Manufacturing Orders, create a new MO for test_MTO, and use one test_component 3. Mark the MO as done, then click Scrap, fill in the product name and click done 4. Go to Reporting -> Production Analysis, Quantity produced is 2 instead of 1 Reason: the move_id from the scrapped stock moves should be filtered out otherwise, they are counted again Fix: add a condition to make sure the stock move of the MO is not scrapped opw-3049301 Forward-Port-Of: odoo/enterprise#34182
Allows a MRP "user" to be able to make a new step suggestion in the tablet view of a workorder. This requires a few `sudo()` to be added. The details are in the commit messages, but TL;DR : - A PLM "user" shouldn't be required to be a MRP "administrator" just for the sake of being able to create an ECO and start a revision, as its own ACL allows him to create them. - A MRP "user" shouldn't need PLM "user" permissions nor Quality "administrator" permissions just to be able to add the new step
Original PR description
Allows a MRP "user" to be able to make a new step suggestion in the tablet view of a workorder. This requires a few `sudo()` to be added. The details are in the commit messages, but TL;DR : - A PLM "user" shouldn't be required to be a MRP "administrator" just for the sake of being able to create an ECO and start a revision, as its own ACL allows him to create them. - A MRP "user" shouldn't need PLM "user" permissions nor Quality "administrator" permissions just to be able to add the new step in the revision BOM. - Also adds back the suggested title in the generated ECO, instead of just notify that the suggestion was done in the workorder. Forward-Port-Of: odoo/enterprise#33880
for some reason, this demo data is duplicating quants and causing issues so we wipe the pre-existing ones to ensure correct data in the end Forward-Port-Of: odoo/enterprise#34127
Original PR description
for some reason, this demo data is duplicating quants and causing issues so we wipe the pre-existing ones to ensure correct data in the end Forward-Port-Of: odoo/enterprise#34127
Previously, we had an option on char/text fields called "onchange_on_keydown", which allowed to trigger the onchange while the user was typing (instead of when the field is blurred). It was notably used in the following contexts: - When typing a message in the social app, to get the previews - When typing a Youtube title/description in the social app, to update the Youtube preview - When modifying the appointment share link "short code", to warn the user that he cannot enter special char
Original PR description
Previously, we had an option on char/text fields called "onchange_on_keydown", which allowed to trigger the onchange while the user was typing (instead of when the field is blurred). It was notably used in the following contexts: - When typing a message in the social app, to get the previews - When typing a Youtube title/description in the social app, to update the Youtube preview - When modifying the appointment share link "short code", to warn the user that he cannot enter special characters (such as a space) This feature was lost during the port to OWL, this commit restores it. Task-3033107 Forward-Port-Of: odoo/enterprise#32966
…n edition feature In studio in general, we don't want clicks to honor their default behavior (open records etc...) Instead, clicks are usually a ways to access either a node's properties or an edition feature (add field, structures etc...). Before this commit, in kanban, when the arch contained `t-on-click` (which it should absolutely not btw), and that one clicked on such a node in the DOM, a crash occured. After this commit, every click is captured and cancelled if it doesn't concern
Original PR description
…n edition feature In studio in general, we don't want clicks to honor their default behavior (open records etc...) Instead, clicks are usually a ways to access either a node's properties or an edition feature (add field, structures etc...). Before this commit, in kanban, when the arch contained `t-on-click` (which it should absolutely not btw), and that one clicked on such a node in the DOM, a crash occured. After this commit, every click is captured and cancelled if it doesn't concern an edition feature. Forward-Port-Of: odoo/enterprise#34198
This commit takes care of barcodes being small and out of place in full page ticket and foldable badge reports. By creating barcodes with dummy data instead of an image of empty barcode, example tickets look more like the actual ones. Task-2980708 Forward-Port-Of: odoo/enterprise#31362
Original PR description
This commit takes care of barcodes being small and out of place in full page ticket and foldable badge reports. By creating barcodes with dummy data instead of an image of empty barcode, example tickets look more like the actual ones. Task-2980708 Forward-Port-Of: odoo/enterprise#31362