Wednesday, September 11, 2024
4 changes
2 changes
New functionality added to Odoo
Adds a Wages Protection System report for UAE payroll so companies can prepare required salary payment files more easily. The update supports local compliance needs and includes related payroll, bank, and configuration changes.
Original PR description
… to UAE payroll task-3326388 Continuation of this [PR](https://github.com/odoo/enterprise/pull/61289) as it was closed due to the branch renaming. Comments from there have been addressed Adding UAE WPS Report [Ticket ID: 3326388](https://www.odoo.com/web#id=3326388&cids=14&menu_id=4722&action=333&active_id=4996&model=project.task&view_type=form)
Enhancements to existing features
Document sharing now supports recipient-only links, invitation emails, and a portal area where users can find files shared with them. This makes document access easier for intended recipients while reducing accidental exposure through open links.
Original PR description
### **<<<<< SHARE LINK CHANGES >>>>>** **---- changes in `documents_share.py` ----** 1. There will now be 2 types of share link. 2. For which a new `Selection` field `share_type` has been added to…
2 changes
Resolved issues and error corrections
This fix corrects an issue where Mexican tax documents (CFDI) generated from point-of-sale invoices were incorrectly using the customer's individual name instead of the company name. This ensures that tax filings with Mexican authorities contain the correct buyer information as provided by the business.
Original PR description
Currently, when a user requests an invoice from a POS ticket under a Mexican company, the CFDI document attached to the invoice incorrectly uses the buyer's name instead of using the provided company name. ### Steps to reproduce * install `l10n_mx_edi_pos` * Switch to a Mexican company * the settings enable "Generate a code on ticket" * validate a POS order * follow the instructions on the ticket to generate an invoice. Make sure to provide a company name on the customer form. When checking the XML file that is forwarded to the Mexican tax authorities, you see that only the "individual name" is registered there as the buyer, when it should be the company name. opw-4103543 opw-4071503
### **<<<<< SHARE LINK CHANGES >>>>>**
**---- changes in `documents_share.py` ----**
1. There will now be 2 types of share link.
2. For which a new `Selection` field `share_type` has been added to the `documents_share` model. The values of which are as follows:
- `share_global` --> Allows anyone with the link to access shared documents.
- `share_restricted` --> Only selected records (from the `res.partner` model)
will have access.
3. Added a `Many2many` field member_ids to specify `res.partner` records allowed
to access the share link.
4. The field `member_ids` will only display those records which are not archived
and have a related `res.users` record. (refer the `_get_member_domain` function).
5. Added a method `_check_share_access_rights` to check if the user is authorized
to access the documents from the share link.
6. Added action_send_invitation method to send email invitations to partners in
the field `member_ids`.
**---- changes in `documents_share_views.xml` ----**
1. Users must select `share_type` inside the `documents_share` dialog box.
2. On selecting the "Only Recipients" option, the user will be prompted to enter the recipients with whom they wish to share the link.
3. The [COPY LINK & CLOSE] button changes to [SEND INVITATION] upon recipient selection.
4. The [SEND INVITATION] button triggers an email to the recipients.
**---- changes in `mail_template_data.xml` ----**
1. The template `mail_template_document_share` receives the data from the `action_send_invitation` method.
2. This is the template used to email the share link to all the recipients.
**---- changes in `documents_kanban_view.scss` ----**
1. Rectified the selector to match the correct class of the `CopyClipboardChar` widget.
### **<<<<< PORTAL INTEGRATION >>>>>**
- Shared documents are now visible to recipients under the `Files Shared` label in their portal.
**---- changes in `documents.py` ----**
1. Added a new route to access the `download_one` function from the portal as well.
2. Added a check (inside the `_get_file_response`) to verify the access token when the user tries to preview/download the document from the portal.
3. Also added a check for authorization of the users trying to access the shared documents directly from the share link.
**---- added `documents_share_demo.xml` ----**
1. Added a demo record to facilitate testing of portal flows.
**---- changes in `documents.document.py` ----**
1. Added a new `access_token` field for security reasons while accessing the documents' records from the portal.
2. Added a SQL CONSTRAINT to ensure `access_token` uniqueness.
**---- changes in `test_documents_document.py` ----**
1. Directly copying the spreadsheet without specifying a new access token results in the violation of the SQL CONSTRAINT.
2. Hence, manual assignment of a new `access_token` is required.
**---- changes in `documents_templates_share.xml` ----**
1. Added an access denied template for unauthorized access attempts.
**---- changes in `sign_portal_templates.xml` ----**
1. Updated the icon of the `sign` portal card so we can use that icon as the icon for the `documents` portal card.
2. Renamed the `sign` module portal card for clarity between `sign` and `documents` portal cards.
**---- changes in `spreadsheet_mixin.py` ----**
1. Each invocation of the `copy` method requires a unique `access_token`. (If we do not do this, we will violate the unique SQL CONSTRAINT applied on the `access_token` field)
2. Since there are many different models invoking the method, we need to explicitly check if the `self` is an instance of the `documents_document` model. And only in that case we pass the access_token.
Task-3889932This fix resolves two critical issues in the Mexican electronic shipping document (Cartaporte) generation that were introduced during a version upgrade. The system was incorrectly calculating customs regime data, causing PDF generation to fail, and was missing country names in tax residency information. These fixes ensure shipping documents are generated correctly for Mexican operations.
Original PR description
[This commit] is a fw-port from 15.0. However, during the adaptation between the versions, we had two issues: - the `regimenes_aduanero` for the PDF was incorrectly computed, causing a crash on generation - the country names for the Residencia Fiscal were not added anymore This commit fixes these issues. task-3990042 [This commit]: https://github.com/odoo/enterprise/commit/e76859d90cfca3a144f10860e8e4e6845850e4f8