Monday, June 17, 2024
24 changes · master
Enhancements to existing features
Customers can no longer restart closed subscriptions from the portal when the related subscription plan or product has been archived. This prevents payments from reactivating offerings that the business has intentionally discontinued or removed from sale.
Original PR description
Before this commit: Previously, customers had the ability to reopen any closed subscription via payment from the portal, irrespective of whether the associated plan or product was archived. After this commit: Following this update, customers will no longer be able to reopen closed subscriptions from the portal if they are linked to archived plans or products. Task-3756259
The HR referral recruitment dashboard has been updated with improved data so teams can get clearer insights from the spreadsheet dashboard. This helps business users review referral recruitment information more accurately and make better-informed staffing decisions.
Original PR description
task-3964448
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
Odoo Studio’s view editors are being prepared for upcoming kanban editor improvements, with cleaner sidebar components and better field filtering. Users gain more flexibility by being able to edit CSS class values from the editor, while test updates improve reliability for future development.
Original PR description
This PR contains multiple improvements and changes in the web_studio module. This is done in preparation of task-3650117, which will improve the kanban editor UX. This will come in another PR later, with a minimal diff containing only the newest editor and its related changes. The code has been simplified in some commits, and there is a small set of tests converted to the HOOT framework. Those are the basis for future conversions and the tests of the newest editor.
Brazilian tax and electronic invoicing integrations now use expanded address fields when sending customer or company address details. This helps improve address accuracy for tax calculation and electronic document processing, reducing the chance of mismatches or incomplete information.
Original PR description
Now that we depend on base_address_extended in l10n_br we can send more accurate addresses. task-3958544
Kanban cards are now clickable by default across Odoo, while specific business views that should not open records directly opt out of that behavior. This keeps day-to-day navigation more consistent while preserving specialized workflows in areas like accounting, documents, HR, manufacturing, stock, social, and timesheets.
Billing targets are now set as percentages on each employee record instead of using one company-wide setting. Timesheet leaderboard calculations now account for each employee's working calendar, making billable rate tracking more accurate across months with different schedules.
Original PR description
This commit introduces the following changes: - Remove the billing rate target from the company settings. - Instead, replace the billing time target on the employee form by a billing rate target. - Change the computation of the billable rate in the leaderboard by using the employee working calendar (and not the billing time target anymore). - Change the comparison made to know if an employee has reached its target by using the billing rate target set for the employee (and not the target rate defined in the company settings anymore). The rationale is that as each month is different, so is the working calendar of employees. To take the variations between months into account, we now compute the billable rate of employees as such: Current number of billable hours of the employee / Number of hours currently worked by the employee according to his working calendar task-3609085
The document sharing process now avoids creating temporary share records before they are actually needed, reducing unnecessary background calls when users open or cancel the share popup. Spreadsheet sharing keeps the same performance by handling snapshots through the share data flow without extra user-facing steps.
Original PR description
Purpose ======= There are many things that can be improved in the current sharing flow Share popup ----------- We always create a `document.share`, and if we don't use it, we manually make an unlink…
Purpose ======= There are many things that can be improved in the current sharing flow Share popup ----------- We always create a `document.share`, and if we don't use it, we manually make an unlink RPC call to remove the temporary record... This is very inefficient because we make an RPC call to create the record, one to get the action, one to remove the record if we cancel the modal, etc. Instead, we can just not create the record at all, and refactor the code in that direction (so the share URL needs to be just based on the token, not on the ID, since we need to copy the URL before the record is created). Spreadsheet ----------- When we share a spreadsheet, we make a snapshot of it. This snapshot is saved in the model `documents.shared.spreadsheet`, and it can not be done in python. Before it used the fact that the share was created to not make an RPC call, but it can not be used anymore. We can still avoid making an RPC call by creating a new non-stored field, with an inverse, that way the performance remain the same. So, we have a lot of code with RPC call to create those snapshot records, Task-3924439
Resolved issues and error corrections
Appointment booking pages now avoid browser cache errors when users move back and forward after choosing an appointment. The change improves booking reliability and keeps the selected timezone consistent by prioritizing the session timezone.
Original PR description
Steps to reproduce: - Install Appointments - Login as admin (or user with appointment manager rights) - Go to URL "/appointment" - Select an appointment and clicks Continue - Click on previous button and next button => ERR_CACHE_MISS (in Chrome) or Document Expired (in Firefox) The use of "Cache-Control: no-store" leads to an issue when navigating the browser history through the previous/next buttons. When posting data from a form, this leads to a security error of the browser as it prevents the form to be resend automatically. Instead of submitting the form, we redirect manually when clicking on the continue button. Also, to avoid any issue with a previous timezone selected we reused the timezone from the session before any other if it was set. task-3945356
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 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
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