Wednesday, July 10, 2024
11 changes · 17.0
Resolved issues and error corrections
Fixed an error that occurred when processing vendor bills through the Documents module's automatic digitization feature. The system was incorrectly attempting to create multiple versions of the same attachment, causing errors in the message thread. The fix prevents unnecessary versioning when the attachment being linked is already associated with the document.
Original PR description
Steps to reproduce: ------------------- - Install 'Documents' and 'Accounting' modules - Go to document settings > Activate Accounting + go to "Journal" smart link then create a synchronized with Vendor Bills journal - Go to accounting setting > Activate "Document Digitization" and select "Digitize automatically" for bills - Send a PDF to the Vendor bill mail alias - Open the created bill Issue: ------ Error in the chatter. Cause: ------ We try to set on the document an attachment already linked to it, and because it goes through the versioning code, it will first link the new attachment to the record (who was already the case), and then link the old attachment (who is the same attachment as the new) to the document. Solution: --------- If trying to set the same attachment already linked to the document, we skip the versioning code. opw-4034699 Forward-Port-Of: odoo/enterprise#66361
This fix prevents multiple journal entries from showing the same tax export rejection warning on the accounting dashboard. Previously, when a tax report had negative amounts causing rejection, the error message would appear for every miscellaneous journal instead of just the relevant one. Now the system correctly identifies which journal should display the warning, reducing dashboard clutter and confusion for users managing French tax compliance.
Original PR description
…d warning Steps to reproduce: - Go to Accounting/Reporting/Tax Report; - Make sure there is a negative amount in the tax report; - Click on PDF/EDI VAT/Test Interchange (available in debug) not to send the tax report to the government for real, and "Send VAT Report"; - Go to Reporting/EDI exports > it should have the "Rejected" status because of the negative amount(s); Issue: On the Accounting Dashboard: the error "Export(s) de taxes rejeté(s)" is appearing on several journals Solution: We get the journal defined for the Tax Return Periodicity. If no journal defined; We keep only the first Misc journal that is found This way, we let the user have custom misc journals (fec import or custom coa) opw-4004375
This fix prevents users from accidentally restarting work orders that have already been marked as completed. Previously, finished work orders could be restarted through the dashboard, which could cause confusion and data inconsistencies in manufacturing operations. The system now properly validates the work order status before allowing it to be started again.
Original PR description
**Steps to reproduce the bug:** - Create a storable product P1 with BoM: - Component: Add any component - operation: OP1 - Create a MO with P1: - Confirm it - Start the workorder and mark it as done…
**Steps to reproduce the bug:**
- Create a storable product P1 with BoM:
- Component: Add any component
- operation: OP1
- Create a MO with P1:
- Confirm it
- Start the workorder and mark it as done
- Come back to the dashboard > workorders list
- Select the finished workorder
- Try to start it
**Problem:**
The work order can be started while it is in the 'done' state.
When the function `button_start` is called, we will check if we need to
skip the employee check or not. However, since the current user is also
an employee, we will use them:
https://github.com/odoo/enterprise/blob/c4604d8b398713898b014e6073219d6202c154c3/mrp_workorder/models/mrp_workorder.py#L258-L259
The function start_employee will then be called:
https://github.com/odoo/enterprise/blob/c4604d8b398713898b014e6073219d6202c154c3/mrp_workorder/models/mrp_workorder.py#L284-L286
The state of the work order will then be updated:
https://github.com/odoo/enterprise/blob/c4604d8b398713898b014e6073219d6202c154c3/mrp_workorder/models/mrp_workorder.py#L740"
opw-4024904This update corrects incorrect property settings in the spreadsheet filter side panel that were causing the filter editor to malfunction. The fix ensures that filters are properly configured and work as intended when users edit spreadsheet filters.
Original PR description
Related ticket: 4000939
This update corrects how company identification and discretionary data fields are formatted in US ACH payment files to ensure compatibility with major banks like Chase. The fix changes these fields from right-aligned to left-aligned formatting, which aligns with official specifications and industry standards used by leading payment processors.
Original PR description
The Company Identification field was incorrectly formatted as a numeric field. It is specified as numeric by some banks [^1], but the official specification is alphanumeric [^2]. On top of that the…
The Company Identification field was incorrectly formatted as a numeric field. It is specified as numeric by some banks [^1], but the official specification is alphanumeric [^2].
On top of that the alphanumeric Company Discretionary Data field was right-justified. A minority of banks don't handle this correctly.
There's no official specification on how to align alphanumeric fields [^1]. The decision to left-justify is based on the following:
- Chase specifies to left-justify them [^3]
- The most extensive open-source ACH library left-justifies them [^4]
- Another Python ACH library left-justifies them too [^5]
- Online images of ACH files seem to left-justify them as well
The only two remaining fields that are right-justified with spaces ({:>...}) are Immediate Destination and Immediate Origin. This is on purpose. Although they are numeric fields and thus right aligned, they are specified to start with a blank space, not a leading 0 [^2].
[^1]: https://web.archive.org/web/20230624090124/https://files.nc.gov/ncosc/documents/eCommerce/bank_of_america_nacha_file_specs.pdf
[^2]: https://achdevguide.nacha.org/ach-file-overview
[^3]: https://www.chase.com/content/dam/chaseonline/en/demos/cbo/pdfs/cbo_nacha_filespecs.pdf
[^4]: https://github.com/moov-io/ach/blob/073d011f811605e1b6051792163159a55feca533/converters.go#L81-L94
[^5]: https://github.com/travishathaway/python-ach/blob/cc8b6448d75f3815c91d3b8a5dadd6731aa96e71/ach/data_types.py#L57-L76
opw-4033830Fixed a bug where adding or removing tags from documents would incorrectly show all documents instead of maintaining the current filter view. When users tagged a document within a specific contact's document folder, the system would lose the context and display unrelated documents. This fix ensures that document filters remain active when managing tags.
Original PR description
Tag updates were causing reload of the domain, while updating tag counts, With this commit all contextual values are preserved during tag updates [Reproduce] - Install documents,contacts- Open a contact - Open its documents - Go to "internal" - Upload a document - Add a tag to it (or remove it) - BUG: all documents visible (instead of documents for that particular client) opw-3967799
This fix resolves an issue where images inserted in spreadsheets would not display when the document was shared and accessed via a public link. The problem occurred because image paths were missing the necessary authentication token required to access shared content. Now when spreadsheets are shared, images will display correctly for users accessing them through the share link.
Original PR description
Steps to reproduce: - create a spreadsheet document - insert an image in the spreadsheet - hit the Share button - open the link in an incognito window => the image is not displayed Task: 4037385 opw-4035835
This fix corrects how the Appointment Details page displays in the Calendar module. Previously, the appointment resource section would appear even when no resources were assigned to an appointment. Now, the resource details section only displays when resources are actually configured, providing a cleaner and more accurate user experience.
Original PR description
Steps to reproduce: 1. Create an event with an appointment-type set. 2. In the Calendar module, open the event you created for the appointment. 3. Navigate to the 'Appointment Details' page. Before This Commit: The 'Appointment Details' page is displayed even if no resources have been set. After This Commit: Appointment resource records will only be shown if resources are set. Task:3918574
This fix ensures that insurance amounts are properly included in DHL shipping requests and printed on shipping labels. Previously, insurance amounts were calculated for rating purposes but were not being added to the actual shipping request, resulting in labels that didn't reflect the insurance coverage. Now when insurance is selected, it will correctly appear on the printed label.
Original PR description
before this commit: Insurance amount was sent in rating request but not in shipping request. Resulting in no insurance amount being printed on label. After this commit: If the insurance amount is sent, it is added to the shipping request and gets printed on label. opw-3845693 Forward-Port-Of: odoo/enterprise#66036
This fix resolves a crash that occurred when installing the document management feature for projects in a system that already had demo data. The issue was that document folders weren't being created for all projects that needed them, causing a database constraint violation. The fix ensures all projects with document management enabled get their required document folders set up properly during installation.
Original PR description
To reproduce: - Create a new db with demo data and install `sale_timesheet` module - Then as a second step, install `documents_project` The installation will crash with: ``` psycopg2.errors.NotNullViolation: null value in column "folder_id" of relation "documents_document" violates not-null constraint ``` When using `search` with no corresponding field, `convert_xml()` will only consider the first value, and in our case because of the ordering of project model, we're not going to setup the document folder on project which is not `project.project_project_1`. This commit force creating documents folders for all projects with `use_documents` option set.
This fix addresses an issue where users could drag locked documents to another workspace, but the system would silently fail to move them without any warning. Now, when locked documents are included in a move operation, users will receive a clear notification explaining that those locked files could not be moved, improving transparency and reducing confusion.
Original PR description
Before this commit, when dragging documents including one or more locked documents to another workspace, only the unlocked documents are effectiveley moved and no message were shown to alert the user although the code exists but is never triggered. This commit, fix this by displaying the notification alerting the user that the locked files haven't been moved. Task-3992114 Forward-Port-Of: odoo/enterprise#64670