Monday, June 17, 2024
16 changes · master
Enhancements to existing features
The subscription dashboard data has been refreshed to improve the information shown to sales teams. This helps users rely on more current and relevant dashboard views when tracking subscription sales performance.
The WhatsApp event integration is simplified so it no longer installs or depends on website event features. Event date information is handled directly by the event module, reducing unnecessary dependencies and cleanup while keeping messaging templates working.
Original PR description
RATIONALE Whatapp_event depends on website_event, which makes no sense. The only usage seems to be "whatsapp portal url" which is either * the portal url on some hardcoded models, if available; * the event website url (fuck it if not published by the way); * or contactus page because yolo All this could be moved into a website_whatsapp module or something like that anyway, to have a real whatsapp_event bridge module with only event. PURPOSE Remove dependency to website_event, to be event only. 'website_url' field existence can be checked with an "in", no need of a module just for that. Move "date_range" field from whatsapp to event, as anyway it calls a method already used in various templates. Move method itself on event model as it depends only on model. Rename field to "event_date_range" to match event dates fields naming. Remove dead code. Task-3768779
Resolved issues and error corrections
This fix prevents spreadsheet pivot insertions from creating an extra table unless the pivot is added directly from the pivot view. It avoids unintended table creation and keeps spreadsheet behavior consistent for users.
Original PR description
Creating a table should be done only when the pivot is inserted from the pivot view, not when it is inserted with the command "INSERT_PIVOT". Task: 3987435
Code cleanup and technical improvements
This update streamlines how chat, WhatsApp, VoIP, documents, and helpdesk live chat data is prepared before being sent to the browser. It reduces repeated information, which can improve responsiveness and make future performance improvements easier.
Original PR description
This will reduce data transferred to the client and processed in JS when the same member was appearing multiple times. This also makes more clear what is transferred by avoiding nested values. Note: this is a first step, many format methods still have to be converted, in particular the one from member, which will then allow converting the one from partner, which will significantly reduce duplicate data send for the current partner (one duplicate per open channel). Formatting code eventually becomes simpler too, by always adding data to the store rather than updating pre-existing dict manually. Part of task-3605717 https://github.com/odoo/odoo/pull/169484
Miscellaneous changes
When using the new sparse gantt mode [1] users would get a crash if an appointment was visible. This is because there was an assumption the rows would always represent records of the model of the last grouping. In the sparse mode the rows represent the pill records, in this case events. So we find the parent group instead to find the relevant attendee, in that mode. `partner_id` on `calendar.event` in test models is also updated to use `.id` as `related` doesn't work well with relationa
Original PR description
When using the new sparse gantt mode [1] users would get a crash if an appointment was visible. This is because there was an assumption the rows would always represent records of the model of the last grouping. In the sparse mode the rows represent the pill records, in this case events. So we find the parent group instead to find the relevant attendee, in that mode. `partner_id` on `calendar.event` in test models is also updated to use `.id` as `related` doesn't work well with relational fields. task-3950682 [1] e5f9c54415d3ca10378fc5729b242508396b2316 Forward-Port-Of: odoo/enterprise#63417
This update reorganizes how Odoo marks records' main attachments, moving model-specific logic to the relevant business records instead of the attachment layer. It improves code separation and batch processing, helping modules like invoice extraction, expenses, recruitment, documents, and localization behave more consistently.
Original PR description
Currently updating main attachment is done a bit through two methods * one model-based "_message_set_main_attachment_id"; * one attachment-based "register_as_main_attachment"; Attachment-based method is overridden in various addons to implement model specific behavior. This makes no sense: model-specific behaviors should be implemented on the right model. With this commit, "register_as_main_attachment" now correctly calls "_message_set_main_attachment_id", which is the method to override when adding model-specific behaviors. "register_as_main_attachment" still exists notably due to attachment viewer that takes an attachment as main record. It now delegates the model update to the model itself, leading to clearer code separation. Various calls and main attachment update are updated accordingly. Finally we also make 'register_at_main_attachment' batch-enabled. It groups attachments per model, allowing to benefit from cache. Task-3599245
When triggering the onchange method of the reconciliation widget, the `_get_invoice_matching_amls_candidates` method is executed. If there are both numerical and exact tokens, it produces a query with 6 subqueries (a general query with 6 UNION ALL). This can become quite slow on database with lots of amls. Because for each of these 6 "subqueries" the FROM, JOIN and WHERE clauses are the same, we can extract all of them in a single CTE. Thanks to that the CTE is executed only once and each UNI
Original PR description
When triggering the onchange method of the reconciliation widget, the `_get_invoice_matching_amls_candidates` method is executed. If there are both numerical and exact tokens, it produces a query…
When triggering the onchange method of the reconciliation widget, the `_get_invoice_matching_amls_candidates` method is executed. If there are both numerical and exact tokens, it produces a query with 6 subqueries (a general query with 6 UNION ALL). This can become quite slow on database with lots of amls. Because for each of these 6 "subqueries" the FROM, JOIN and WHERE clauses are the same, we can extract all of them in a single CTE. Thanks to that the CTE is executed only once and each UNION ALL simply scans the CTE to get the correct columns + performs an additional filtering. This reduces the average execution of the query by a factor of 3-4 on hot-cache. Since the onchange is triggered each time we do something in the reconciliation widget, on average the cache is expected to be hot so the average speedup boils down to the hot-cache scenario. #### speedup Customer 17.0 database with 7M account_move_lines and 8000 accounts, the query execution, given a st_line and with both numerical and exact tokens: 7.5s -> 2.3s ##### dalibo [Standard](https://explain.dalibo.com/plan/0a6fe16h503614e0) vs [CTE](https://explain.dalibo.com/plan/495a777ef95d2980) There is also a speedup achievable with a partial multicolumn index but that's more of a case by case index. opw-3938995 Forward-Port-Of: odoo/enterprise#64433
Revisions are technical records that are never supposed to be changed (except the `active` field). If any of `res_model`, `res_id`, `revision_uuid` is changed, the spreadsheet history will be broken. Changing field `commands` could also break the spreadsheet if the json is malformed or the command is made invalid. In this commit, we prevent the admin to make any changes. Forward-Port-Of: odoo/enterprise#64401 Forward-Port-Of: odoo/enterprise#64328
Original PR description
Revisions are technical records that are never supposed to be changed (except the `active` field). If any of `res_model`, `res_id`, `revision_uuid` is changed, the spreadsheet history will be broken. Changing field `commands` could also break the spreadsheet if the json is malformed or the command is made invalid. In this commit, we prevent the admin to make any changes. Forward-Port-Of: odoo/enterprise#64401 Forward-Port-Of: odoo/enterprise#64328
Create an asset Reverse an entry in the past => In depreciation schedule, if we take the current period, initial amount in Depreciation does not correspond to the cumulative depreciation in the Depreciation Board of the asset. The reversed entry are not taken into account, which was normal before, but now we take reversal entry into account so these should be too. opw-3890144 Forward-Port-Of: odoo/enterprise#64564 Forward-Port-Of: odoo/enterprise#63821
Original PR description
Create an asset Reverse an entry in the past => In depreciation schedule, if we take the current period, initial amount in Depreciation does not correspond to the cumulative depreciation in the Depreciation Board of the asset. The reversed entry are not taken into account, which was normal before, but now we take reversal entry into account so these should be too. opw-3890144 Forward-Port-Of: odoo/enterprise#64564 Forward-Port-Of: odoo/enterprise#63821
Steps to reproduce: - Install `documents_project` - Go to one of the task and add a document - Close it Issues: In the project update the number of documents is shown however it is wrong, as it compute it by retrieving all the tasks without taking into account the state of the tasks. When clicking on the documents button you don't see documents linked to task that are closed, the desired behaviour is to see all of them and not take into account the state of the tasks. The behaviour
Original PR description
Steps to reproduce: - Install `documents_project` - Go to one of the task and add a document - Close it Issues: In the project update the number of documents is shown however it is wrong, as it compute it by retrieving all the tasks without taking into account the state of the tasks. When clicking on the documents button you don't see documents linked to task that are closed, the desired behaviour is to see all of them and not take into account the state of the tasks. The behaviour was due to the way the domain is set on the `task_ids` in the project model. https://github.com/odoo/odoo/blob/174cb193592f12c7f4167eb34642665778deb208/addons/project/models/project.py#L332-L333 Because of this when we retrieved the documents we didn't have all the tasks. https://github.com/odoo/enterprise/blob/0e98a5fdf5e4f32eeae769552284297b9233088c/documents_project/models/project_project.py#L204 opw-3921156 Forward-Port-Of: odoo/enterprise#64603
Steps to reproduce : --------------------------- - Install pos and product barcodelookup - Go to settings disable variants - Try to scan a product having variants - Click on save button Issue : -------- Can't save and traceback comes. Cause : ---------- It was trying to set the variants but the variant field was not in the form as it's disabled from settings. Fix : ----- Create and set the attributes only if the variant is enabled. Forward-Port-Of: odoo/enterprise#64678 Forw
Original PR description
Steps to reproduce : --------------------------- - Install pos and product barcodelookup - Go to settings disable variants - Try to scan a product having variants - Click on save button Issue : -------- Can't save and traceback comes. Cause : ---------- It was trying to set the variants but the variant field was not in the form as it's disabled from settings. Fix : ----- Create and set the attributes only if the variant is enabled. Forward-Port-Of: odoo/enterprise#64678 Forward-Port-Of: odoo/enterprise#62991
A bad fw-port caused the xml to be changed wrongly. The test class was deactivated, so it got merged without being seen. runbot-68044 Forward-Port-Of: odoo/enterprise#64660
Original PR description
A bad fw-port caused the xml to be changed wrongly. The test class was deactivated, so it got merged without being seen. runbot-68044 Forward-Port-Of: odoo/enterprise#64660
Currently importing a DIAN document produces a blank invoice, because `_get_ubl_cii_builder_from_xml_tree` does not return anything, since the node `UBLVersionID` contains "UBL 2.1" rather than just "2.1" as in the other usual formats. Use the node `ProfileID` to treat the DIAN xml documents (using the `UBLVersionID` might have side effects if other specific formats also fill it with "UBL 2.1"). Forward-Port-Of: odoo/enterprise#64426
Original PR description
Currently importing a DIAN document produces a blank invoice, because `_get_ubl_cii_builder_from_xml_tree` does not return anything, since the node `UBLVersionID` contains "UBL 2.1" rather than just "2.1" as in the other usual formats. Use the node `ProfileID` to treat the DIAN xml documents (using the `UBLVersionID` might have side effects if other specific formats also fill it with "UBL 2.1"). Forward-Port-Of: odoo/enterprise#64426
A string domain is being used without being evaluated, leading to a traceback ### Steps to reproduce * Turn on debug mode * Go to the “Journal Entries” window action via Settings > Technical > Actions > Window Actions * Give any domain to the “Domain Value” field of the window action * Go to Tax Report via Accounting > Reporting > Statement Reports > Tax Report * Click the “Closing Entry” button * Click the “Post” button to post the closing entry you will run into the following tr
Original PR description
A string domain is being used without being evaluated, leading to a traceback ### Steps to reproduce * Turn on debug mode * Go to the “Journal Entries” window action via Settings > Technical > Actions > Window Actions * Give any domain to the “Domain Value” field of the window action * Go to Tax Report via Accounting > Reporting > Statement Reports > Tax Report * Click the “Closing Entry” button * Click the “Post” button to post the closing entry you will run into the following traceback: `IndexError: string index out of range` ### Fix The `account.action_move_journal_line` (Journal Entries window action) record was being reused for consistency. However, domains added to that record should not be propagated in this context. So in this case, the solution is to remove the domain from the returned action. opw-3903500 Forward-Port-Of: odoo/enterprise#64597
When deleting a line from an order, the preparation display wasn't updated. This commit fixes this issue. TaskId: 3976728 Community PR: https://github.com/odoo/odoo/pull/168694 Forward-Port-Of: odoo/enterprise#64241
Original PR description
When deleting a line from an order, the preparation display wasn't updated. This commit fixes this issue. TaskId: 3976728 Community PR: https://github.com/odoo/odoo/pull/168694 Forward-Port-Of: odoo/enterprise#64241
If the network is really slow, when you order a drink at the frontdesk. The visitor_id will not be set correctly, and you will have a traceback. Steps to reproduce: ------------------- * Install frontdesk * Enable "host selection" on the frontdesk station * Choose open kiosk * With the developper tool make the network slow, and use a mobile view * Click on check in, then try to order a drink > Observation: You get a traceback Why the fix: ------------ The `createVisitor` functi
Original PR description
If the network is really slow, when you order a drink at the frontdesk. The visitor_id will not be set correctly, and you will have a traceback. Steps to reproduce: ------------------- * Install frontdesk * Enable "host selection" on the frontdesk station * Choose open kiosk * With the developper tool make the network slow, and use a mobile view * Click on check in, then try to order a drink > Observation: You get a traceback Why the fix: ------------ The `createVisitor` function was not awaited during the setup of the page. But it is required to order the drink. opw-3889245 Forward-Port-Of: odoo/enterprise#62899