Daily updates from Odoo
Monday, July 29, 2024
26 changes · master
Enhancements to existing features
Restaurant table references now use a numeric table number instead of a free-text name across appointment, preparation display, and self-order preparation flows. This makes table identification more consistent for staff and customer-facing order preparation screens.
Original PR description
pos*: pos_restaurant_appointment, pos_restaurant_preparation_display, pos_self_order_preparation_display In this commit, we adapt the data model of the restaurant table. Its name becomes a table number: the field is changed from 'name::string' to 'table_number::integer'. Community PR: odoo/odoo#173108
Gantt views now handle end dates more consistently by avoiding rounding to the last second of the day. This improves scheduling accuracy in planning, field service, projects, and other Gantt-based workflows.
Original PR description
*web_gantt, planning, industry_fsm
Before this commit:
- The default value of the end time in Gantt view was 23:59:59.
After this commit:
- The end time in the Gantt view will now default to 00:00:00 with one day/hr
ahead.
- Introduced a new parameter `roundUpStop` in the `getColumnStartStop` function.
- When this parameter is set to true, the default time for the end date
will increment by 1ms.
- When set to false, the end time remain as it is.
Task-3871980The expense onboarding flow now lets users either try a sample receipt or upload their own receipt. This makes the setup experience more realistic, while ensuring uploads are only available when the customer has data extraction credits.
Original PR description
Before this commit, the expense onboarding wizard offered the user 4 sample receipts to choose from. Now, the user can choose either a sample receipt, or to upload their own receipt. However, in order to upload their own receipt, they need to have credit for data extraction. A depiction of the updated user journey could be found here: https://link.excalidraw.com/l/65VNwvy7c4X/3RaHoyA4PFQ task-3901510
Users can now open the full project or task form from Gantt and Calendar views using the expand button. This makes collaboration details such as the chatter accessible without leaving the planning workflow.
Original PR description
Currently, when user open a task or project in the calendar or Gantt view, they cannot access the chatter. With this commit, they can now access the form view through the expanded button. Task: 3837229
Indian payroll now supports sandwich leave calculations, where intervening weekends or public holidays can be counted when leave is taken on both sides. This helps businesses apply local leave policies more consistently and deduct the correct number of leave days from employee balances.
Original PR description
This commit, adds the Sandwich Leave Rule in Indian Localization. The sandwich leave rule will be applied if an Employee takes leave like in the scenario below. Scene 1: Friday (leave) -> Saturday -> Sunday -> Monday(Leave) 4 Leaves will be deducted from the Employee's leave balance. Scene 2: Tuesday(Leave) -> Wednesday(Public Holiday) -> Thursday (Leave) 3 Leaves will be deducted from the Employee's leave balance. task-3950973
The event form now places the social menu setting in a dedicated Sub-menu tab. This makes the event setup screen easier to navigate and helps users find related website menu options more quickly.
Original PR description
**Specifications:** Modify event form and move 'social_menu' field to 'Sub-menu' tab. **After this commit:** 'social_menu' field will be moved in the newly created 'Sub-menu' tab. Please refer the related community PR for better understanding. Task-4010675
Event website sub-pages can now keep their own SEO titles and descriptions instead of unintentionally sharing the same values. This helps event organizers tailor search visibility and social previews for pages like talks and exhibitors independently.
Original PR description
**How to reproduce:** - Create an event and activate the submenu - Open Talk Proposal page and set specific SEO discription and title - Open Exhibitors page and set another one **Specifications:** - They are currently synced. - All the sub-pages except 'Introduction' and 'Location' page are synced. - SEO data of all the pages should be different from one another. **After this PR:** SEO data for all sub-pages will be different. Task-3874050
Global invoices for Mexican POS sales now use the POS reference, making the related ticket numbers visible on the invoice. This helps businesses provide clearer records during government tax audits and makes it easier to match invoices with sold tickets.
Original PR description
When there is a tax audit from the government, its common to check global invoices as they declare which tickets were sold during a certain period. This is not possible because the global invoice does not contain ticket numbers, it contains references which are only visible from Odoo and can be an issue for checking. [Ticket](https://www.odoo.com/odoo/project/4216/tasks/4061845?cids=17)
Resolved issues and error corrections
Removing HMRC authentication credentials now affects the user selected by the administrator, not the currently logged-in user. This prevents accidental removal of another user's UK tax reporting credentials and makes multi-user credential management more reliable.
Original PR description
This commit fixes the following issue and also improves the way the code is handling write/clean hrmc tokens on user. In the write/clear functions, `user` argument is now mandatory so that we can do…
This commit fixes the following issue and also improves the way the code is handling write/clean hrmc tokens on user. In the write/clear functions, `user` argument is now mandatory so that we can do the operation on the selected user rather than the environment user. Issue: Step to reproduce: - install`l10n_uk_reports` - create 2 user or more - for each user, fill their hmrc token values - select a user different from the current environment user - remove their credential with the button "Remove Authentication Credentials" Current behavior: - The selected user's credential is not removed, but the environment user one got removed Expected behavior: - the selected user's credential should be the one that is removed, and the environment user should not be removed. Why it happens: - In `_clean_tokens` function, it clears the credential of the environment user by default. Solution: - change the signature of _clean_tokens function to have `user` required argument and clean that user's token instead of `env.user` opw-4041604
Australian payroll users now have a dedicated menu item to access termination payments. This restores easier access after a previous workflow change and keeps payroll forms less cluttered.
Original PR description
Termination flow was removed in a previous commit. https://github.com/odoo/enterprise/commit/9d21446069dfc794fcf7b0f7bb4ced90202cbd05 This commit adds a menu item for the Termination Payments to avoid too many actions on the form view.
Code cleanup and technical improvements
This change reorganizes how extra record details are prepared for Approvals, VoIP, and WhatsApp features. It reduces repeated technical handling behind the scenes, making future maintenance easier without changing the user experience.
Original PR description
\* = approvals, voip, whatsapp This allows to easily set extra values on records without having to repeat the model name or the id in many different places. Part of task-3605717 https://github.com/odoo/odoo/pull/174507
Miscellaneous changes
It turns out we've been sending the wrong value in the state field [1]. This hasn't caused issues for the majority of states, but some states reject invoices if they don't have the right code (e.g. Minas Gerais). opw-4076445 [1] The specification mentions state *code*: https://avataxbr-docs.avalarabrasil.com.br/#/Invoice%20Goods/sendInvoiceGoods Forward-Port-Of: odoo/enterprise#67476
Original PR description
It turns out we've been sending the wrong value in the state field [1]. This hasn't caused issues for the majority of states, but some states reject invoices if they don't have the right code (e.g. Minas Gerais). opw-4076445 [1] The specification mentions state *code*: https://avataxbr-docs.avalarabrasil.com.br/#/Invoice%20Goods/sendInvoiceGoods Forward-Port-Of: odoo/enterprise#67476
Steps to Reproduce: ----------- - Install sale planning. - Create a sale order with a plan product. - Navigate to the Planning app > Schedule > By Resource. - Click on a cell in the "Open Shifts" line. - Select a resource. - Save and close. - Check the shift resource. Issue: ---------- The shift is not being created in the open shift section based on the parameters selected by the user. Fix: ---------- When creating a shift from the open shift section, it
Original PR description
Steps to Reproduce: ----------- - Install sale planning. - Create a sale order with a plan product. - Navigate to the Planning app > Schedule > By Resource. - Click on a cell in the "Open Shifts" line. - Select a resource. - Save and close. - Check the shift resource. Issue: ---------- The shift is not being created in the open shift section based on the parameters selected by the user. Fix: ---------- When creating a shift from the open shift section, it should generate shifts according to the parameters selected by the user, such as resource, date, etc. task-3919549 Forward-Port-Of: odoo/enterprise#67248 Forward-Port-Of: odoo/enterprise#64203
Currently, if a user uses a sale order sequence that contains special characters like `/` (e.g. SO/2024/12/31/01), they do not see such a sale order in suggestions in bank reconciliation if the label doesn't match the name of the sale order exactly. That is, a label `SO/2024/12/31/01 test` would not much this sale order, but a label `SO2024123101 test` would much a sale order with a name `SO2024123101`. This is because we format tokens and filter out special characters and then compare them t
Original PR description
Currently, if a user uses a sale order sequence that contains special characters like `/` (e.g. SO/2024/12/31/01), they do not see such a sale order in suggestions in bank reconciliation if the label doesn't match the name of the sale order exactly. That is, a label `SO/2024/12/31/01 test` would not much this sale order, but a label `SO2024123101 test` would much a sale order with a name `SO2024123101`. This is because we format tokens and filter out special characters and then compare them to names. With this commit, we'll compare names and tokens that are formatted the same way. opw-3964898 Forward-Port-Of: odoo/enterprise#67471 Forward-Port-Of: odoo/enterprise#67176
We should not raise during the Send & Print. Otherwise, when sending a batch of invoices and one of them is raising errors, none will be sent. no task Forward-Port-Of: odoo/enterprise#66326
Original PR description
We should not raise during the Send & Print. Otherwise, when sending a batch of invoices and one of them is raising errors, none will be sent. no task Forward-Port-Of: odoo/enterprise#66326
Speed up the shop floor by drastically reducing the number of refresh calls. We try to avoid a refresh of data from the server as much as possible. If an update is still unavoidable, we try to only refresh the relevant MO. task-4048415 Forward-Port-Of: odoo/enterprise#66898
Original PR description
Speed up the shop floor by drastically reducing the number of refresh calls. We try to avoid a refresh of data from the server as much as possible. If an update is still unavoidable, we try to only refresh the relevant MO. task-4048415 Forward-Port-Of: odoo/enterprise#66898
In Peru, we don't prevent invoices with the same name from being created. Invoices with the same name, same document type and same company RUC will be reported to SUNAT with the same `edi_filename`. SUNAT rejects those invoices as duplicates, which is good. However, our fallback mechanism of retrieving the existing CDR for those invoices and marking the invoice as sent is not good in this situation. Indeed, the user should be notified that the invoice was rejected, prompting them to resequenc
Original PR description
In Peru, we don't prevent invoices with the same name from being created. Invoices with the same name, same document type and same company RUC will be reported to SUNAT with the same `edi_filename`. SUNAT rejects those invoices as duplicates, which is good. However, our fallback mechanism of retrieving the existing CDR for those invoices and marking the invoice as sent is not good in this situation. Indeed, the user should be notified that the invoice was rejected, prompting them to resequence their invoice. Instead, they get the impression that their invoice was correctly sent to SUNAT. To fix this, we don't try to retrieve an existing CDR if an invoice was rejected as duplicate, but there already exists an invoice with the same edi_filename that was sent to SUNAT. opw-3900393 Forward-Port-Of: odoo/enterprise#67161 Forward-Port-Of: odoo/enterprise#65520
Steps to reproduce: - Open the Profit & Loss report - Create a budget using the budget filter - Audit a cell of the report Issue: A traceback occurs, indicating a string or bytes-like object error. Cause: In the previous commit https://github.com/odoo/enterprise/commit/8f19af2335d4199a306d9db489cbac1db656a0cb, the markup of line IDs was modified to include dictionaries for groupby information. However, one 'groupby' was overlooked, causing a traceback due to the system expecting a
Original PR description
Steps to reproduce: - Open the Profit & Loss report - Create a budget using the budget filter - Audit a cell of the report Issue: A traceback occurs, indicating a string or bytes-like object error. Cause: In the previous commit https://github.com/odoo/enterprise/commit/8f19af2335d4199a306d9db489cbac1db656a0cb, the markup of line IDs was modified to include dictionaries for groupby information. However, one 'groupby' was overlooked, causing a traceback due to the system expecting a string instead of a dictionary. Fix: This commit corrects the missing 'groupby' case to handle dictionaries properly,preventing the traceback. Additional Changes: Updated a related comment to reflect the new markup handling for consistency. task-3791247 Forward-Port-Of: odoo/enterprise#67337
With this PR : ========================== - Previously, when producing the entire quantity of a product, new component lines were created, ignoring reserved components. - This change uses the reserved components instead of creating new ones. Task-id : 4012314 Forward-Port-Of: odoo/enterprise#65559
Original PR description
With this PR : ========================== - Previously, when producing the entire quantity of a product, new component lines were created, ignoring reserved components. - This change uses the reserved components instead of creating new ones. Task-id : 4012314 Forward-Port-Of: odoo/enterprise#65559
Before this fix, one couldn't move documents to the parents workspaces. This was due to a check on the 'active' class of the target's child elements and not only on his direct descendant. This commit fix this by adding ':scope > ' to the selector. Task-3999790 Forward-Port-Of: odoo/enterprise#65000
Original PR description
Before this fix, one couldn't move documents to the parents workspaces. This was due to a check on the 'active' class of the target's child elements and not only on his direct descendant. This commit fix this by adding ':scope > ' to the selector. Task-3999790 Forward-Port-Of: odoo/enterprise#65000
- Added missing pot/po files/translations for l10_cl_edi_pos - Converted website_sale file from es_CL => es_419 so the translations will show for other LATAM countries/langs - Added missing pot file + added missing terms/translations to website_sale module opw-4044338 Forward-Port-Of: odoo/enterprise#67429
Original PR description
- Added missing pot/po files/translations for l10_cl_edi_pos - Converted website_sale file from es_CL => es_419 so the translations will show for other LATAM countries/langs - Added missing pot file + added missing terms/translations to website_sale module opw-4044338 Forward-Port-Of: odoo/enterprise#67429
### Steps to reproduce: - Install hr_holidays_contract_gantt module - Create two employees one with a contract and another without - Create a time off for each employee - Check Time Off -> Overview ### Current behavior before PR: The employee who has a contract will have grey cells on weekend days that are coming after his contract start date but the ones before will be white. The employee who has no contract won't have any grey cells neither for his off days nor the weekend days.
Original PR description
### Steps to reproduce: - Install hr_holidays_contract_gantt module - Create two employees one with a contract and another without - Create a time off for each employee - Check Time Off -> Overview ### Current behavior before PR: The employee who has a contract will have grey cells on weekend days that are coming after his contract start date but the ones before will be white. The employee who has no contract won't have any grey cells neither for his off days nor the weekend days. ### Desired behavior after PR is merged: Both employees should show the grey cells in the gantt view whether they have contract or not because if so we fallback on the employee working hours and then company's working hours 'According to the PO' opw-3961873 Forward-Port-Of: odoo/enterprise#67432 Forward-Port-Of: odoo/enterprise#65470
When the customer tries to create an asset for multiple journal items from different companies, a traceback will appear. Steps to reproduce the error: - Create an invoice with Company A - Create an invoice with Company B - Go to Accounting > Journal Items > select both invoice > Create Asset Traceback: ``` ValueError: Expected singleton: res.company(1, 5) File "odoo/http.py", line 2248, in __call__ response = request._serve_db() File "odoo/http.py", line 1823, in _serve_db
Original PR description
When the customer tries to create an asset for multiple journal items from different companies, a traceback will appear. Steps to reproduce the error: - Create an invoice with Company A - Create an…
When the customer tries to create an asset for multiple journal items from
different companies, a traceback will appear.
Steps to reproduce the error:
- Create an invoice with Company A
- Create an invoice with Company B
- Go to Accounting > Journal Items > select both invoice > Create Asset
Traceback:
```
ValueError: Expected singleton: res.company(1, 5)
File "odoo/http.py", line 2248, in __call__
response = request._serve_db()
File "odoo/http.py", line 1823, in _serve_db
return self._transactioning(_serve_ir_http, readonly=ro)
File "odoo/http.py", line 1843, in _transactioning
return service_model.retrying(func, env=self.env)
File "odoo/service/model.py", line 134, in retrying
result = func()
File "odoo/http.py", line 1821, in _serve_ir_http
return self._serve_ir_http(rule, args)
File "odoo/http.py", line 1828, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
File "odoo/http.py", line 2053, in dispatch
result = self.request.registry['ir.http']._dispatch(endpoint)
File "odoo/addons/base/models/ir_http.py", line 220, in _dispatch
result = endpoint(**request.params)
File "odoo/http.py", line 756, in route_wrapper
result = endpoint(self, *args, **params_ok)
File "addons/web/controllers/dataset.py", line 42, in call_button
action = self._call_kw(model, method, args, kwargs)
File "addons/web/controllers/dataset.py", line 34, in _call_kw
return call_kw(request.env[model], method, args, kwargs)
File "odoo/api.py", line 458, in call_kw
result = getattr(recs, name)(*args, **kwargs)
File "home/odoo/src/enterprise/saas-17.2/account_asset/models/account_move.py", line 315, in turn_as_asset
'default_company_id': self.company_id.id,
File "odoo/fields.py", line 5183, in __get__
raise ValueError("Expected singleton: %s" % record)
```
https://github.com/odoo/enterprise/blob/9373f9bac47839e3314a7823e05d4ef61af0b3e3/account_asset/models/account_move.py#L345 Here, When the user creates an asset for multiple journal items from
different companies, Self has multiple 'company_id'.
So it will lead to the above traceback.
sentry-5613448397
Forward-Port-Of: odoo/enterprise#67417
Forward-Port-Of: odoo/enterprise#66806Problem --------- Currently, if you install l10n_xx and update some specific account codes (depending on the localization) and then try to install the corresponding l10n_xx_hr_payroll_account hr module, you are struck with an error that cancels the installation as some accounts are missing. 1. Install l10n_ae for example 2. Switch to AE company 3. Update the account with code 201002 to 701002 4. Install l10n_ae_hr_payroll_account -> Error occurs during the installation Objective ----
Original PR description
Problem --------- Currently, if you install l10n_xx and update some specific account codes (depending on the localization) and then try to install the corresponding l10n_xx_hr_payroll_account hr module, you are struck with an error that cancels the installation as some accounts are missing. 1. Install l10n_ae for example 2. Switch to AE company 3. Update the account with code 201002 to 701002 4. Install l10n_ae_hr_payroll_account -> Error occurs during the installation Objective --------- Be able to install the module even when the account is missing. Solution --------- Log a warning instead of raising an error. opw-3961798 Forward-Port-Of: odoo/enterprise#67345 Forward-Port-Of: odoo/enterprise#67241
Issue: =============== When a manufacturing order (MO) is created, the default components are automatically reserved and are made visible in the barcode module. However, even if these components are later unreserved, they will continue to be displayed in the barcode module. Resolution: ================ To address this issue, we've taken the step to avoid forcefully re-reserving the components when a component is unreserved. This resolves the persistent display of components in t
Original PR description
Issue: =============== When a manufacturing order (MO) is created, the default components are automatically reserved and are made visible in the barcode module. However, even if these components are…
Issue: =============== When a manufacturing order (MO) is created, the default components are automatically reserved and are made visible in the barcode module. However, even if these components are later unreserved, they will continue to be displayed in the barcode module. Resolution: ================ To address this issue, we've taken the step to avoid forcefully re-reserving the components when a component is unreserved. This resolves the persistent display of components in the barcode. Steps to Reproduce: ====================== 1. Create a manufacturing order (MO) and confirm it. 2. Navigate to the barcode module within the manufacturing order. 3. By default, the components are reserved, so they are visible in the barcode module. 4. Go to the form view of the MO in MRP and unreserve the components. 5. Check the barcode module again, and notice that the unreserved components are still visible. Expected Result: ================== After implementing the solution, When we opens the MO in the barcode module only reserved components should be visible. When a component is unreserved, it should no longer be visible in the barcode module for manufacturing order. task-3869731 Forward-Port-Of: odoo/enterprise#66679 Forward-Port-Of: odoo/enterprise#61827
Refs. commits message for steps to reproduce COMMIT 1: ---------------- Issue: ------ One attachment has been removed (not linked anymore to the move). Cause: ------ When switching the main attachment, the versioning is triggered; the new main attachment is set on the document and the previous is added to the history for versioning (and therefore also change the res fields to be linked to the document instead of the move). Solution: --------- When updating the attachm
Original PR description
Refs. commits message for steps to reproduce COMMIT 1: ---------------- Issue: ------ One attachment has been removed (not linked anymore to the move). Cause: ------ When switching the main…
Refs. commits message for steps to reproduce COMMIT 1: ---------------- Issue: ------ One attachment has been removed (not linked anymore to the move). Cause: ------ When switching the main attachment, the versioning is triggered; the new main attachment is set on the document and the previous is added to the history for versioning (and therefore also change the res fields to be linked to the document instead of the move). Solution: --------- When updating the attachment of a document that already have an attachment (normal versioning), we should remove the link between the current document attachment (not the new one) and the related model only if the related model has not a `message_main_attachment_id` field or if the current document attachment is different of the main attachment set on the related model. COMMIT 2: ---------------- Issue: ------ A second document is created. Cause: ------ The issue is when switching the second time the invoice main attachment, the current main attachment is in fact in the versioned attachments (`document.preview_attachment_ids`), and since we search only for document that have as attachment (`document.attachment_id`) the current invoice main attachment, we don't find it and create a new document. Solution: --------- Look also in the versioned attachments when searching for the invoice main attachment in case it has been versioned. opw-4028789 Forward-Port-Of: odoo/enterprise#67464 Forward-Port-Of: odoo/enterprise#66501