Wednesday, May 29, 2024
12 changes · master
Enhancements to existing features
The Inventory app menu has been simplified by removing a duplicate action. This reduces confusion for users and makes it easier to find the right inventory reporting option.
Original PR description
In this commit: ==================== - Remove duplicate action from Inventory menus to streamline user experience and improve functionality. task-3837207
Restaurant appointment flows in Point of Sale now ignore hidden “shadow tables” used for unassigned restaurant orders. This keeps appointments focused on real dining tables and avoids confusing or incorrect table links for staff.
Original PR description
In the corresponding community commit we introduce the concept of "shadow tables", which allows us to place orders in pos restaurant that appear to not be linked to any table. In this commit we have to adapt `pos_restaurant_appointment` to ignore these "shadow tables" Task: 3908568 https://github.com/odoo/odoo/pull/164918
Resolved issues and error corrections
A Colombian localization field is no longer mandatory when it is not relevant. This prevents companies outside Colombia from being blocked by a country-specific requirement that should not apply to them.
Original PR description
This change should have been done in commit 3f798c74d7a05114f2d8390742c51bf2ac5aede6 . It was forgotten during forward porting. The field should not be required since it does not matter for non-CO companies. see https://github.com/odoo/enterprise/pull/54086#discussion_r1464762388
Code cleanup and technical improvements
This update removes unused code across several Point of Sale-related modules. It should make the codebase easier to maintain without changing day-to-day business workflows or adding new features.
Original PR description
*: l10n_cl_edi_pos, l10n_de_pos_cert, l10n_de_pos_res_cert, pos_blackbox_be, pos_iot, pos_l10n_se, pos_preparation_display, pos_settle_due, whatsapp_pos Remove dead code
Miscellaneous changes
Steps to reproduce: - go to planning app - choose a month for a user without any planned or open shifts - publish - go to frontend via the email link - error raised Source: - many attributes like default_start are not present in planning_get reponse, trying to accessing default_start = undefined and converting it to a valid date that can be used to display the calendar raises an error. Solution: - when no_data = True, start function in fullcalendar should not compute anything as the
Original PR description
Steps to reproduce: - go to planning app - choose a month for a user without any planned or open shifts - publish - go to frontend via the email link - error raised Source: - many attributes like default_start are not present in planning_get reponse, trying to accessing default_start = undefined and converting it to a valid date that can be used to display the calendar raises an error. Solution: - when no_data = True, start function in fullcalendar should not compute anything as there are no data to display. task-3906551 task-3186609 Forward-Port-Of: odoo/enterprise#63158 Forward-Port-Of: odoo/enterprise#61866
**Steps to reproduce:** - Install `documents_project` module (for test purposes) - Create a new activity type with: - `action`: `Upload Document` - `folder_id`: `Internal` - `model_id`: `Task` - Go to settings and enable `Centralize files attached to projects and tasks` (from 16.0, set a default folder on the project) - Go to any task and add a new activity with the new activity type - Click on `Upload Document` and select a file **Issue:** Access right error message.
Original PR description
**Steps to reproduce:** - Install `documents_project` module (for test purposes) - Create a new activity type with: - `action`: `Upload Document` - `folder_id`: `Internal` - `model_id`: `Task` - Go…
**Steps to reproduce:** - Install `documents_project` module (for test purposes) - Create a new activity type with: - `action`: `Upload Document` - `folder_id`: `Internal` - `model_id`: `Task` - Go to settings and enable `Centralize files attached to projects and tasks` (from 16.0, set a default folder on the project) - Go to any task and add a new activity with the new activity type - Click on `Upload Document` and select a file **Issue:** Access right error message. **Cause:** Simple explanation: 2 documents are created (one on the activity creation and one on the attachment upload) and the attachment is linked to the second document. When trying to fisrt unlink the second document and then link the attachment to the first document, the attachment is already unlinked. Detailed explanation: When creating the activity, if a folder_id is set on the activity, an empty document is first created with the request_activity_id. https://github.com/odoo/enterprise/blob/a23a18681bddc5995c5dac8cacfb074c06fc5ea8/documents/models/mail_activity.py#L46 When uploading the file, if the related record model is an inherit of `documents.mixin` model and the documents settings (in this case `Document Project Settings`) are activated, it will create the document with the attachment. https://github.com/odoo/enterprise/blob/2df654e8cb08d528976d5f1d24397574798a5cad/documents/models/ir_attachment.py#L63 Then, in the action done, we will unlink the last document record created and try to link it's attachment (already unlinked) to the first document record (with the `request_activity_id`). https://github.com/odoo/enterprise/blob/2df654e8cb08d528976d5f1d24397574798a5cad/documents/models/mail_activity.py#L33 Since the following commit, when unlinking a document, it unlink also it's attachment: https://github.com/odoo/enterprise/commit/a999f2c32ab542ca7aa44cf34970dc7cca4fdaf8 **Solution:** Override the upload route (`/mail/attachment/upload`) so that it skip the creation of the second document (by adding `no_document` to the context) if an activity ID is available and that a document with a `request_activity_id` with the same activity ID already exists. COM PR: https://github.com/odoo/odoo/pull/159943 opw-3458850 Forward-Port-Of: odoo/enterprise#63220 Forward-Port-Of: odoo/enterprise#59796
Currently, several l10n_pe_edi tests are failing every night. This is due to: - Error 98 meaning that not enough time is given to the remote sever to process cancellation requests -> wait and check several times before asserting - Duplicated name: Sometimes, some invoices have duplicated names. We make sure it is not possible by 'incrementing' the name for each invoice we create. ----- 1. `test_send_delivery_guide` was failing because the picking vehicule was not set up properly in
Original PR description
Currently, several l10n_pe_edi tests are failing every night. This is due to: - Error 98 meaning that not enough time is given to the remote sever to process cancellation requests -> wait and check…
Currently, several l10n_pe_edi tests are failing every night. This is due to: - Error 98 meaning that not enough time is given to the remote sever to process cancellation requests -> wait and check several times before asserting - Duplicated name: Sometimes, some invoices have duplicated names. We make sure it is not possible by 'incrementing' the name for each invoice we create. ----- 1. `test_send_delivery_guide` was failing because the picking vehicule was not set up properly in the test. After this was fix, another issue appeared: the company needed proper credential to connect to the SUNAT. Since those were not available, the function connecting to SUNAT has been patched to simulate a basic answer from SUNAT. 2. `test_generate_delivery_guide`'s expected document has been updated to include the vehicule set up in the previous step. 3. Since there is no more call to an external API. The `external` and `l10n_external` tags are not necessary anymore. This allows to group both tests under the same class. task-3718645 Forward-Port-Of: odoo/enterprise#63291 Forward-Port-Of: odoo/enterprise#62452
When user clicks on contracts smart button in application and if application has two contracts (one archived and one active), a traceback will appear. Steps to reproduce the error: - Install "hr_contract_salary" module - Go to Recruitment > Applications > All Applications > Create new application > Generate Offer > Select Contract Template > Send By Email > Send - Click on Offers > Salary Configurator > Fill all required fields > Review Contract & Sign > Validate & Send Completed Do
Original PR description
When user clicks on contracts smart button in application and if application has two contracts (one archived and one active), a traceback will appear. Steps to reproduce the error: - Install…
When user clicks on contracts smart button in application and if application has
two contracts (one archived and one active), a traceback will appear.
Steps to reproduce the error:
- Install "hr_contract_salary" module
- Go to Recruitment > Applications > All Applications > Create new application >
Generate Offer > Select Contract Template > Send By Email > Send
- Click on Offers > Salary Configurator > Fill all required fields >
Review Contract & Sign > Validate & Send Completed Document
- Open that application > Contracts > Create new contract > Save
- Archived one contract > Click on Contract smart button
Traceback:
```
ValueError: Expected singleton: hr.contract(27, 29)
File "odoo/http.py", line 2253, in __call__
response = request._serve_db()
File "odoo/http.py", line 1829, in _serve_db
return self._transactioning(_serve_ir_http, readonly=ro)
File "odoo/http.py", line 1849, 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 1827, in _serve_ir_http
return self._serve_ir_http(rule, args)
File "odoo/http.py", line 1834, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
File "odoo/http.py", line 2059, 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 740, 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/hr_contract_salary/models/hr_applicant.py", line 59, in action_show_proposed_contracts
"res_id": self.env['hr.contract'].search([["applicant_id", "=", self.id], '|', ["active", "=", False], ["active", "=", True]]).id,
File "odoo/fields.py", line 5182, in __get__
raise ValueError("Expected singleton: %s" % record)
```
https://github.com/odoo/enterprise/blob/504b3c66a9a8d142b89f9c873675ec65fdb43dd0/hr_contract_salary/models/hr_applicant.py#L59
Here when application has two contracts (one is archived and one is active),
So when it tries to access the id of 2 records.
It will lead to the above traceback.
sentry-5350130147
Forward-Port-Of: odoo/enterprise#62627Steps to reproduce ================== - Open a product form - Open Studio - Remove the "Internal Notes" block from "General Information" - Add a new field => The normalized view contains many operations, it should only contain one move and one insertion Cause of the issue ================== The normalization compares the original view with the view with all operations applied. To do this, it stringifies every node and then does a textual diff between the original and modified ve
Original PR description
Steps to reproduce ================== - Open a product form - Open Studio - Remove the "Internal Notes" block from "General Information" - Add a new field => The normalized view contains many…
Steps to reproduce
==================
- Open a product form
- Open Studio
- Remove the "Internal Notes" block from "General Information"
- Add a new field
=> The normalized view contains many operations, it should only contain one move and one insertion
Cause of the issue
==================
The normalization compares the original view with the view with all operations applied. To do this, it stringifies every node and then does a textual diff between the original and modified versions.
The issue in this case is that there are multiple ways to represent a diff.
In this example, we remove the first group
```xml
<form>
<group/>
<group/>
</form>
```
```xml
<xpath expr="/form/group" position="replace"/>
```
The before stringified view is represented as
```
/form/group
/form/group[@closed]
/form/group
/form/group[@closed]
```
The after stringified view is represented as
```
/form/group
/form/group[@closed]
```
There are two ways to represent this diff
```diff
- /form/group
- /form/group[@closed]
/form/group
/form/group[@closed]
```
```diff
/form/group
- /form/group[@closed]
- /form/group
/form/group[@closed]
```
In this case, we only want the first one, but the second one is generated.
Solution
========
We can assign an id to every node before performing the diff, this way, the nodes are uniquely represented.
The before stringified view will be represented as
```
/form#1/group#2
/form#1/group#2[@closed]
/form#1/group#3
/form#1/group#3[@closed]
```
The after stringified view is represented as
```
/form#1/group#3
/form#1/group#3[@closed]
```
The diff can now only be represented in one way
```diff
- /form#1/group#2
- /form#1/group#2[@closed]
/form#1/group#3
/form#1/group#3[@closed]
```
opw-3888345
opw-3924997
Forward-Port-Of: odoo/enterprise#63047**Current behavior:** If you create a SEPA report for an employee that has address information in their `hr.employee` record but not their `res.partner` record, the creditor address will not use the `hr.employee` information- the corresponding XML node will not be included. **Expected behavior:** The employee address should be in the report if they have one listed in their HR information. **Steps to reproduce:** 1. Install the `test_l10n_be_hr_payroll` module, switch to 'My B
Original PR description
**Current behavior:** If you create a SEPA report for an employee that has address information in their `hr.employee` record but not their `res.partner` record, the creditor address will not use the…
**Current behavior:**
If you create a SEPA report for an employee that has address
information in their `hr.employee` record but not their
`res.partner` record, the creditor address will not use the
`hr.employee` information- the corresponding XML node will not
be included.
**Expected behavior:**
The employee address should be in the report if they have one
listed in their HR information.
**Steps to reproduce:**
1. Install the `test_l10n_be_hr_payroll` module, switch to
'My Belgian Company'
2. In the Employee application, go to an employee (e.g., Bernice
Jensen) and make sure their listed bank account is verified
to be able to receive payments
3. In the Payroll application, create a new `To Pay` record for
the employee from step 2, register it, then create the
payment report
4. In the Exported File notebook tab, you can see that there is
no Creditor Address listed in the XML Sepa Report
**Cause of the issue:**
The report builder constructs the creditor address only from
the `res.partner` record.
**Fix:**
Extend the postal address construction such that we get an
address from a partner's employee record (when applicable). The
information should not be mix-and-matched; we will use whichever
address has the most complete information.
opw-3716705
Forward-Port-Of: odoo/enterprise#62934
Forward-Port-Of: odoo/enterprise#58743Before this commit, the journal report did not show the date for credit notes. opw-3939676 Forward-Port-Of: odoo/enterprise#63187
Original PR description
Before this commit, the journal report did not show the date for credit notes. opw-3939676 Forward-Port-Of: odoo/enterprise#63187
[REF] l10n_mx_edi: change fecha date to sent date Issue: Sometimes payments are created in Odoo prior to sending the CFDI, by law payments don't have to be necessarily sent to the government on the same month and can sometimes be sent up to the first 10 days of the next month. Solution: fill the 'fecha' field with the current datetime for the cfdi of the payments, Then send it. Task-3885769 Forward-Port-Of: odoo/enterprise#63293 Forward-Port-Of: odoo/enterprise#62108
Original PR description
[REF] l10n_mx_edi: change fecha date to sent date Issue: Sometimes payments are created in Odoo prior to sending the CFDI, by law payments don't have to be necessarily sent to the government on the same month and can sometimes be sent up to the first 10 days of the next month. Solution: fill the 'fecha' field with the current datetime for the cfdi of the payments, Then send it. Task-3885769 Forward-Port-Of: odoo/enterprise#63293 Forward-Port-Of: odoo/enterprise#62108