Friday, March 3, 2023
15 changes · master
New functionality added to Odoo
Manufacturing teams can now log in as employees directly from work order list and kanban views, assign workers to jobs, and complete multiple work orders at once. Time tracking is more reliable and easier to manage, including better tablet behavior and automated updates in the tracking wizard.
Original PR description
This main feature of this pr is adding the possibility to login with multiple employees on the list view and kanban view of workorders. There is now a button in the header that will allow to log in…
This main feature of this pr is adding the possibility to login with multiple employees on the list view and kanban view of workorders. There is now a button in the header that will allow to log in as an employee in the list view. The flow is the following : - The employee logs in - He becomes the "admin" of the session and his name appears next to the log out button. - If another employee logs in, he will become admin and the first one will no longer be visible in the header. - The employee will start timesheeting on the workorder if he press the start button. Notice that the employees working on the workorder will appear in the last column of every work_order record. - If this second employee logs out, the first one will not become admin automatically. He will first need to click on his name/avatar in the popup and will be asked his pin code (if needed) to log in again. There is also a way to assign employees to a workorder. A filter will help retreive the workorder on wich the admin of the session has been assigned. In addition, a new button in the header allows to mark as done multiple workorders at once. The timer component has been updated to avoid wrong values if the computer goes to sleep mode. The wizard of the workorders allowing to see the time traking has also be modified (switching tabs) and automated (changing duration will update end date e.g.) From a more technical point of vue, the employees and admin will be saved in the session. The employees working on a workorder will be saved on the record. Task : 3063632 I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Enhancements to existing features
The Argentine electronic invoicing module now recognizes the new AFIP point-of-sale setting across both sales and purchase journals. This helps ensure Liquido Producto processing remains compatible with updated journal configuration rules and reduces compliance-related setup issues.
Original PR description
Update logic to make it compatible with new field Is AFIP POS (l10n_ar_is_pos) taking into account both sale and purchase journals This PR depends on https://github.com/odoo/odoo/pull/111076
Resolved issues and error corrections
Point of Sale shops can now open normally when Worldline is enabled and a Worldline terminal is linked to a payment method. This prevents an unnecessary startup blockage, even when that payment method is not used in the shop.
Original PR description
Currenlty, PoS shop cannot be opened if we activate Worldline and create a pos payment method with an associated Worldline terminal (even without adding it to the shop) This PR solves this issue
Miscellaneous changes
Steps to reproduce ================== - Install CRM, Studio - Go to CRM - Open studio - Click on New Model - Complete the wizard -> Nothing happens visually Cause of the issue ================== The old controller state is kept when creating a new model opw-3058363 Forward-Port-Of: odoo/enterprise#37341
Original PR description
Steps to reproduce ================== - Install CRM, Studio - Go to CRM - Open studio - Click on New Model - Complete the wizard -> Nothing happens visually Cause of the issue ================== The old controller state is kept when creating a new model opw-3058363 Forward-Port-Of: odoo/enterprise#37341
The invoice extraction module now works with the newer invoice sending process in Odoo. This keeps electronic document handling aligned with how invoices are actually sent, improving reliability when information leaves Odoo.
Original PR description
The account.invoice.send wizard has been replaced by account.move.send. Main reason: EDI synchronization happens when info get out of Odoo and not on _post(). task-id: 3117238 [enterprise](https://github.com/odoo/enterprise/pull/36757) [community](https://github.com/odoo/odoo/pull/111857)
When an address is validated with Avalara, Odoo now also uses the latitude and longitude returned by Avalara to update the partner's geolocation fields. This reduces manual work and keeps address and map location data aligned for businesses using Avalara and geolocation features.
Original PR description
Before this PR when validating an address with Avalara the latitude and longitude of the response given by their API wasn't used. Since we also have a module named "Geo localization" that provide a way to get the geo localization of a user, we decided that it would be nice that when validating the address the geo localization field would change at the same time. Task-id: 3186071
Point of Sale now supports working across orders in the Belgian blackbox and settle-due flows. This improves cashier workflows and keeps related payment/order actions compatible with recent Point of Sale processing changes.
Original PR description
Related to odoo/odoo#109216 This commit aims at adding the feature "cross-orders" of the PoS. This commit is related to a change made in community where add_new_order now make calls to the server and became asynchronous. The calls to add_new_order must thus be preceded by "await" if necessary.
Users can now choose to display record properties as optional columns in list views, making custom information easier to compare without opening each record. This improves visibility in areas such as Helpdesk and Knowledge while keeping property columns optional and avoiding unsupported bulk editing.
Original PR description
[IMP] *: display properties in list view This commit adds the possibility to display a properties field in a list view. How it works: When a properties field is present in the arch of a list view, it will not be displayed directly. It will display its properties as an optional column. Now, we will find at the end of the dropdown of the optional columns a section by record parent of the properties field. The proposed sections will be the properties linked to the parent record of which at least one record referring to it has been encountered during the navigation in this list view. (A parent record is the record storing the properties definition). Limitation: Multi-editing is not applicable on properties fields as you cannot edit one property without modifying all the others. TaskID: 3105039 Co-authored-by: mcm-odoo <mcm@odoo.com> Co-authored-by: FrancoisGe <fge@odoo.com>
The Knowledge app now correctly keeps the Add Cover button responsive after interface updates. This prevents intermittent failures when users try to add a cover image, improving reliability without changing the feature itself.
Original PR description
Before this commit, and with the last version of owl [1], the knowledge_cover_selector_tour tour failed almost all the time, because at some point, the "Add cover" button had no mousedown event on it. This is because the useEffect used to add the event handler didn't correctly defined its dependencies: when the button changes, the handler must be re-added. It has been highlighted by the update of owl because it slightly changes the way refs are handled, and something that was luckily working before (whereas it shouldn't have) wasn't anymore. [1] odoo/odoo@abaf9d0e70a480252afcf0e08f2a3c68fbbafa00
Fixes an issue where changing a recurring planning shift to a single occurrence could delete the current shift and leave users stuck on an error screen. The form now returns to the previous view instead, keeping scheduling workflows smooth.
Original PR description
Steps: - Create a planning shift, set a recurrence for ever. - Go few occurences later (form via kanban) and set... ...recurrence type to "Number of Occurences", ...recurrence nmber to 1. - Save. Issue: "This record doesn't exist". Cause: The write method will update the recurrence so that it only contains only one occurrence. Consequently, the record you just updated is deleted. Then we try to fetch the record to display its form again. Because de read returns [], _fetchRecord rejects the promise, and we're stuck. Fix: In community commit, we make `FormController.saveButtonClicked` call `Record.save` with its params. In this commit, we override `FormController.saveButtonClicked` to call super with the arg `throwOnError` so that, if the shift is deleted when updating its recurrence, we will catch it and, rather than staying on its form, go back to the previous view. Related: https://github.com/odoo/odoo/pull/112335
Impacted versions: - 16.0+ ## Instanciate Behavior components after a collaborative step How to reproduce: - Edit a collaborative html_field in a form view with 2 users (in 2 distinct windows simultaneously) (i.e. a task in Project, there should be at least 2 tasks) - Be sure to click on the field with both user_1 and user_2 so the collaboration starts - Add one /article command block with user_1 - Click right of the received /article command block with user_2 Current beha
Original PR description
Impacted versions: - 16.0+ ## Instanciate Behavior components after a collaborative step How to reproduce: - Edit a collaborative html_field in a form view with 2 users (in 2 distinct windows…
Impacted versions: - 16.0+ ## Instanciate Behavior components after a collaborative step How to reproduce: - Edit a collaborative html_field in a form view with 2 users (in 2 distinct windows simultaneously) (i.e. a task in Project, there should be at least 2 tasks) - Be sure to click on the field with both user_1 and user_2 so the collaboration starts - Add one /article command block with user_1 - Click right of the received /article command block with user_2 Current behavior: - Sometimes, the cursor appears inside the /article command block, while it should be contenteditable=false (like a button) Issue: - The issue is that the Article Behavior was not properly instanciated, thus the contentEditable=false attribute could not be set. Fix: - trigger a `refresh_behaviors` event when the editor is reset (`resetEditor`) ## Ignore locks from Behavior components rendering in wysiwyg `setValue` How to reproduce: - Edit an html_field in a form view (on a model with at least 2 accessible records). i.e. in Project with at least 2 tasks and edit a task. - Add a lot of /article command blocks (i.e. 10) - Switch back and forth to and from the next record in the form view (button "next") Current behavior: - Traceback (may or may not happen, asynchronous "randomness") Issue: - Knowledge Behavior have asynchronous rendering which happens with the mutationObserver of the editor disconnected (because mutations should not be registered). If the resetContent happens before the lock is lifted, then the mutations for the content reset would not be registered Fix: - allow the `setValue` method to remove locks coming from Behavior components, and restart the observer if there is no lock left. Note: - When the "oe-protected" feature is fully implemented, Knowledge behaviors won't have to disconnect the mutationObserver of the editor, and this fix will be reverted. see odoo/odoo#113813 Task-3208896 Forward-Port-Of: odoo/enterprise#37589
From BS4 to BS5, the `form-control-file` class has disappeared and became `form-control`. This commit replaces the occurrences of the old class by the new one. It is necessary because by letting the old class, it is impossible to place a form label above a `File Upload` field. Indeed, since the `.form-control-file` CSS rule setting the `display` property to `block` has been removed, the file input now has `display: inline-block` by default, which is why the label would end up on the sam
Original PR description
From BS4 to BS5, the `form-control-file` class has disappeared and became `form-control`. This commit replaces the occurrences of the old class by the new one. It is necessary because by letting the…
From BS4 to BS5, the `form-control-file` class has disappeared and became `form-control`. This commit replaces the occurrences of the old class by the new one. It is necessary because by letting the old class, it is impossible to place a form label above a `File Upload` field. Indeed, since the `.form-control-file` CSS rule setting the `display` property to `block` has been removed, the file input now has `display: inline-block` by default, which is why the label would end up on the same line as the input, instead of on top. With `.from-control`, this rule is back, allowing to place the label on top again. After this commit, the look of the file input will change. This is because in BS4, with the `form-control-file` class, the input was the browser native one. It could be customized using `.custom-file` (and the associated `custom-file-*` classes). But in BS5, the file input is directly a custom one, thanks to custom styles added on top of `.form- control`. task-3071151 See [1] for the associated PR. [1]: https://github.com/odoo/odoo/pull/105872 Forward-Port-Of: odoo/enterprise#34495
Steps to reproduce the bug: - Go to any storable product - Click on ECO widget: - Type: New product introduction - Apply on: Product only - start revision and validate the changes - The version of the product becomes “2” - duplicate the product Problem: The new product keeps version “2” instead of starting from 1 opw-3179587 Forward-Port-Of: odoo/enterprise#37367 Forward-Port-Of: odoo/enterprise#37333
Original PR description
Steps to reproduce the bug:
- Go to any storable product
- Click on ECO widget:
- Type: New product introduction
- Apply on: Product only
- start revision and validate the changes
- The version of the product becomes “2”
- duplicate the product
Problem:
The new product keeps version “2” instead of starting from 1
opw-3179587
Forward-Port-Of: odoo/enterprise#37367
Forward-Port-Of: odoo/enterprise#37333Use case to reproduce: - Create a BoM with a step to fill a worksheet - Fill the worksheet and save Traceback. It uses `call` on `this.model.ormService`. However in web, only `this.model.orm` is define. With the fix, the call to server is correctly made but `self.super` is present and trigger another traceback. opw-3056872 Forward-Port-Of: odoo/enterprise#34033
Original PR description
Use case to reproduce: - Create a BoM with a step to fill a worksheet - Fill the worksheet and save Traceback. It uses `call` on `this.model.ormService`. However in web, only `this.model.orm` is define. With the fix, the call to server is correctly made but `self.super` is present and trigger another traceback. opw-3056872 Forward-Port-Of: odoo/enterprise#34033
The SEPA field was squeezed on the same line as the dates, which made it difficult to use. task-3169032 Forward-Port-Of: odoo/enterprise#37677
Original PR description
The SEPA field was squeezed on the same line as the dates, which made it difficult to use. task-3169032 Forward-Port-Of: odoo/enterprise#37677