Thursday, August 31, 2023
22 changes · master
Enhancements to existing features
The public Knowledge sidebar and related page layout have been moved into the Website Knowledge app, where they are actually used. This simplifies maintenance, removes unused favorite/sidebar pieces for public visitors, and restores automated coverage for the public “load more” behavior.
Original PR description
Purpose: - Since the [refactoring of knowledge for portal users](https://github.com/odoo/enterprise/commit/d66829ca7fcbf25bd4683963908d0973734abf96) and the [sidebar](https://github.com/odoo/enterprise/commit/b55ee8f06d7990fc71ee2430029775d5e8277020), some code in knowledge was not used anymore, or only relevant when website was installed. For example, the "frontend" layout that was previously used by portal and public users is now only used by public users, and should thus be in website_knowledge rather than in knowledge. The favorite section of this "frontend" layout is also not relevant anymore since public users cannot add articles to their favorites. This commit moves some code (cleared from dead parts) from knowledge to website_knowledge, and renames some parts to ease the distinction between what's used for portal users and what's used for public users. Task-3346593
Website helpdesk forms now automatically add a default description when tickets are submitted. This helps support teams receive clearer ticket information, including the relevant email field details, without extra manual input.
Original PR description
In this commit, a function has been introduced to facilitate the inclusion of the email field name when a website form is submitted. This addition ensures that a default description is automatically appended to tickets. task-3419255
This update removes obsolete styling code and aligns visual behavior between Odoo Community and Enterprise. Users should see more consistent screens, dialogs, and mobile layouts across apps, with no intended functional change.
Original PR description
task-3439226
The Australian ABA payment feature now installs automatically with the main Australian accounting setup. This helps ensure required bank details, such as BSB information, are available for Australian accounting users without extra manual setup.
Original PR description
Impacted Version: - 16.5 and above This commit improve below features: - Update auto_install requirement for l10n_au_aba - The field aba_bsb is essential in AU accounting task-3419980
Resolved issues and error corrections
Spreadsheet users now see a proper confirmation dialog when merging cells that may affect existing content. This lets them either proceed or cancel, preventing accidental changes from a single OK-only prompt.
Original PR description
Steps to reproduce: - open a spreadsheet - set some content in A2 - select A1:A2 - hit the "Merge cells" icon button => a confirmation dialog opens but the only button is "OK". You should be able to cancel (or confirm) With this commit, the confirmation dialog is used.
Code cleanup and technical improvements
The update replaces an older date-handling component with a newer shared one across several Odoo apps. This helps reduce page assets and supports easier maintenance without changing the intended user experience.
Original PR description
luxon and moment are both used in the solution, but these two libraries facilitate the manipulation of dates. It was decided to replace all uses of moment with luxon so we can then remove moment.js from the code and lighten the assets. task-3391739 PR Community : https://github.com/odoo/odoo/pull/133144
Miscellaneous changes
## Issue When we have an SLA policy with a duration shorter than the average working hours for the calendar's team, and a ticket is created after working hours, said SLA policy is viewed as failed upon ticket creation ## Steps to reproduce - Install Helpdesk - Create a Team > Activate SLA policies - Create a Working Calendar whos working time is before 'now' (for ex: working hours in the morning, but ticket creation is in the afternoon) - Set the calendar to the team - Create an SLA pol
Original PR description
## Issue When we have an SLA policy with a duration shorter than the average working hours for the calendar's team, and a ticket is created after working hours, said SLA policy is viewed as failed…
## Issue When we have an SLA policy with a duration shorter than the average working hours for the calendar's team, and a ticket is created after working hours, said SLA policy is viewed as failed upon ticket creation ## Steps to reproduce - Install Helpdesk - Create a Team > Activate SLA policies - Create a Working Calendar whos working time is before 'now' (for ex: working hours in the morning, but ticket creation is in the afternoon) - Set the calendar to the team - Create an SLA policy of 2 hours for this team - Create a new Ticket for said team, upon saving, it's SLA is already failed. ## Cause In f2cb1712869a0c5cc0e8a0f5eac9814099cf9be5, we prevented overshooting of the SLA deadline for days, but this shouldn't be done when `status.sla_id.time < working_calendar.hours_per_day`, because then we don't fall into `if time_days > 0:` which pushes the deadline by 1 day in the future for that case. This means in our use-case, the deadline is actually 'start of working day' + `status. sla_id.time` of the same day, meaning that if the ticket was created after the working day, it already exceeded the deadline. ## Fix Add the condition to make sure the use-case referenced in the above mentioned commit is used only in case of sla_times larger than a day. ## Affected versions 15.0 up to master --- opw-3425366 Forward-Port-Of: odoo/enterprise#46619 Forward-Port-Of: odoo/enterprise#44649
The Planning app calendar view has been corrected so users can switch to it without encountering an error. This keeps schedule viewing available and avoids disruption when managers review plans in calendar format.
Original PR description
This commit's purpose is to fix a traceback that appears when we switch to the calendar view in planning app. step to reproduce : - open planning app - click on 'calendar' to switch view details of the implementation : Switched the this.env._t to the new standard use introduced by the refactor of the translations. task - 3485773
This fix ensures spreadsheet chart extensions are loaded in the right order before the spreadsheet library starts. It helps prevent chart-related issues and keeps spreadsheet reports working reliably for users.
Original PR description
We now load the o-spreadsheet dependencies before the library itself to make sure we can insert our chart.js plugin extensions. Task: 3482480
Several Odoo Enterprise apps were updated to use the newer shared data search mechanism after the older endpoint was removed. This keeps accounting, documents, payroll, knowledge, timesheets, planning views, maps, and Studio aligned with the core platform change and helps avoid disruption as the old method is phased out.
Original PR description
This PR is the counterpart of odoo/odoo#133617 It adapts the calls to /web/dataset/search_read (which has been removed) and web_search_read (which has been replaced by the unity version). Part of task~3179751
The older way of handling automatic form updates has been removed and replaced by the newer approach across several Odoo Enterprise apps. This keeps the platform more consistent and easier to maintain, with limited direct impact for everyday users.
Original PR description
This replaces the old implementation of `onchange()` by its new implementation `onchange2()`.
This change reorganizes how discussion-related records are added behind the scenes, moving the logic into the data models themselves. It prepares the messaging code for easier maintenance and fewer unexpected side effects, with no intended change for end users.
Original PR description
https://github.com/odoo/odoo/pull/133509 In preparation to clean code of models, e.g. by simplifying model insertion and reducing side-effects in record insertion. This commit moves the implementation of the `insert()` in discuss services to the models, and drop support of the service methods `insert()`. The only way to insert a model is through the store entry, e.g. `store.Thread.insert()`.
Since odoo/odoo#115390, the Note app was replaced by ToDo. This commit, changes the the shortcut `note` in the `WebManifest` by the new ToDo app (`project_todo`). Forward-Port-Of: odoo/enterprise#46600
Original PR description
Since odoo/odoo#115390, the Note app was replaced by ToDo. This commit, changes the the shortcut `note` in the `WebManifest` by the new ToDo app (`project_todo`). Forward-Port-Of: odoo/enterprise#46600
* : documents_spreadsheet, spreadsheet_edition Issue: ===== When you select groupby date month in rows and groupby date year in cols in pivot view it still shows the button insert in spreadsheet. Steps to reproduce the error: ============================= - Go to sales/reporting -> pivot view - Groupby rows by month - Groupby cols by year - insert in spreadsheet is enabled Origin of the issue: ==================== When we check on duplicates we don't consider the the fact that
Original PR description
* : documents_spreadsheet, spreadsheet_edition Issue: ===== When you select groupby date month in rows and groupby date year in cols in pivot view it still shows the button insert in spreadsheet.…
* : documents_spreadsheet, spreadsheet_edition Issue: ===== When you select groupby date month in rows and groupby date year in cols in pivot view it still shows the button insert in spreadsheet. Steps to reproduce the error: ============================= - Go to sales/reporting -> pivot view - Groupby rows by month - Groupby cols by year - insert in spreadsheet is enabled Origin of the issue: ==================== When we check on duplicates we don't consider the the fact that date:month and date:year are the same if applied in rows and cols at the same time. it's okay to have them both on only rows or cols. Having this behavior will result in error when displaying the spreadsheet because in `pivot_model.js` we check only on the name of the groupby which is date to classify a groupby is a col or a row . (https://github.com/odoo/odoo/blob/cc3e899be84f44a8d6b1161ef9ae278e8f75c1c3/addons/spreadsheet/static/src/pivot/pivot_model.js#L561) Solution: ========= As dicussed with LUL, I added a check on the date to make sure it exist in only rows or cols but not both. opw-3390240 Forward-Port-Of: odoo/enterprise#46587 Forward-Port-Of: odoo/enterprise#46242
Before, when the cashier would rapidly press on "Send" followed by "Cancel" in a loop it was possible to get stuck with a payment line which would be impossible to delete or have no payment line but with Worldline terminal asking for a payment which would never get saved in Odoo. This PR fixes both issues and applies the fix both for Raspberry Pi and Virtual Windows IoT [task 3390547](https://www.odoo.com/web#id=3390547&cids=1&menu_id=4720&action=333&active_id=1428&model=project.task&view
Original PR description
Before, when the cashier would rapidly press on "Send" followed by "Cancel" in a loop it was possible to get stuck with a payment line which would be impossible to delete or have no payment line but with Worldline terminal asking for a payment which would never get saved in Odoo. This PR fixes both issues and applies the fix both for Raspberry Pi and Virtual Windows IoT [task 3390547](https://www.odoo.com/web#id=3390547&cids=1&menu_id=4720&action=333&active_id=1428&model=project.task&view_type=form) Forward-Port-Of: odoo/enterprise#44557
## Issue By default, when a website has one published helpdesk team, the label of the helpdesk menu is "Help". When we add a second team on the website, each team gets it's own menu, and the label should reflect the name of the team. Currently the first team, which had the label "Help" is not renamed to the team name when we publish another team on the website. The inverse process should also be true: if we have multiple teams, and we remove all of them but one, said team menu label should be r
Original PR description
## Issue By default, when a website has one published helpdesk team, the label of the helpdesk menu is "Help". When we add a second team on the website, each team gets it's own menu, and the label…
## Issue By default, when a website has one published helpdesk team, the label of the helpdesk menu is "Help". When we add a second team on the website, each team gets it's own menu, and the label should reflect the name of the team. Currently the first team, which had the label "Help" is not renamed to the team name when we publish another team on the website. The inverse process should also be true: if we have multiple teams, and we remove all of them but one, said team menu label should be renamed to Help, which is currently not the case. ## Steps to reproduce - Install Helpdesk and Website - Publish one of the helpdesk team to the website with "Website Form". - Notice it has the has the label "Help" on the website menu. - Publish another team, refresh the website - Notice the first label is still "Help", while the second is the name of the newly published helpdesk team. ## Cause In `_ensure_website_menu(self)`, we set the name of the of the newly written to team, creating the correct label for the new menu that we are adding, but there is no routine to update the names of the other team's menu linked to the website we are modifying. ## Fix With the teams provided from the read_group, we scan for those that whose menu may need a label update based on the count of teams we have on the website. ## Affected versions saas-15.2 up to master ## Reference opw-3453794 Forward-Port-Of: odoo/enterprise#46557 Forward-Port-Of: odoo/enterprise#46197
Before this commit, the read_group done in grid view of timesheets to find additional data with planning.slot could fail because we use the whole domain used in the search view. That domain has to be filtered to just have the field available inside of planning.slot since the domain in the search is exclusively used for `account.analytic.line` model. This commit uses `removeDomainLeaves` to remove all tuples in that domain containing another fields than `project_id`, `employee_id`, and `user_i
Original PR description
Before this commit, the read_group done in grid view of timesheets to find additional data with planning.slot could fail because we use the whole domain used in the search view. That domain has to be filtered to just have the field available inside of planning.slot since the domain in the search is exclusively used for `account.analytic.line` model. This commit uses `removeDomainLeaves` to remove all tuples in that domain containing another fields than `project_id`, `employee_id`, and `user_id` to be sure the domain used for the read_group done for `planning.slot` model only used fields defined inside `planning.slot`. Forward-Port-Of: odoo/enterprise#46535
Since https://github.com/odoo/odoo/pull/122663, calls to IAP services are prevented by default in tests, and raise an AccessError. As such, the IAP l10n_pe_edi tests were failing in the external_l10n nightly build - see for example https://runbot.odoo.com/runbot/build/49918376 The solution is to remove the testing flag on the current thread when calling iap_jsonrpc(). (See the solution implemented in the website module in the above PR.) Forward-Port-Of: odoo/enterprise#46432
Original PR description
Since https://github.com/odoo/odoo/pull/122663, calls to IAP services are prevented by default in tests, and raise an AccessError. As such, the IAP l10n_pe_edi tests were failing in the external_l10n nightly build - see for example https://runbot.odoo.com/runbot/build/49918376 The solution is to remove the testing flag on the current thread when calling iap_jsonrpc(). (See the solution implemented in the website module in the above PR.) Forward-Port-Of: odoo/enterprise#46432
task-id: 3452269 Forward-Port-Of: odoo/enterprise#46511 Forward-Port-Of: odoo/enterprise#45910
Original PR description
task-id: 3452269 Forward-Port-Of: odoo/enterprise#46511 Forward-Port-Of: odoo/enterprise#45910
To reproduce: - Create an asset - Dispose the asset - Don't post the disposal move yet - Check the depreciation schedule at this month => Book value of the asset is 0 while the move is not posted Solution: only consider disposal if the remaining value of posted entries is 0 Forward-Port-Of: odoo/enterprise#46520 Forward-Port-Of: odoo/enterprise#44215
Original PR description
To reproduce: - Create an asset - Dispose the asset - Don't post the disposal move yet - Check the depreciation schedule at this month => Book value of the asset is 0 while the move is not posted Solution: only consider disposal if the remaining value of posted entries is 0 Forward-Port-Of: odoo/enterprise#46520 Forward-Port-Of: odoo/enterprise#44215
Description of the issue/feature this PR addresses: In the website when any task is open, sign button is visible all the the time. Sign button should only visible when field service option is enable from the particular project form view, worksheet template is not empty, task is in sign state and worksheet field in project setting is enabled. Current behavior before PR: Sign button is visible in all task in website. Desired behavior after PR is merged: Sign button is only visible when
Original PR description
Description of the issue/feature this PR addresses: In the website when any task is open, sign button is visible all the the time. Sign button should only visible when field service option is enable…
Description of the issue/feature this PR addresses: In the website when any task is open, sign button is visible all the the time. Sign button should only visible when field service option is enable from the particular project form view, worksheet template is not empty, task is in sign state and worksheet field in project setting is enabled. Current behavior before PR: Sign button is visible in all task in website. Desired behavior after PR is merged: Sign button is only visible when field service option is enable from the project form view, worksheet template is not empty, task is in sign state and worksheet field in project setting is enabled. Fix: Add t-if condition in sign button template to check whether field service is selected and sign report button is visible or not in task form view. Sign button is only visible when any worksheet template is selected and worksheet field in project setting is enabled. task-3217427 Forward-Port-Of: odoo/enterprise#46408 Forward-Port-Of: odoo/enterprise#38875
…ing subviews Have a form view with the widget many2many_checkboxes (or any other that doesn't need subviews) (i.e. the field widget must have useSubView set to a falsy value) In studio, click on that field. Before this commit, the buttons to navigate to the X2many views where visible, which made no sense, and could cause crashes. After this commit, x2many fields not using subviews don't show those buttons hen clicked on. Forward-Port-Of: odoo/enterprise#46536 Forward-Port-Of: odoo/
Original PR description
…ing subviews Have a form view with the widget many2many_checkboxes (or any other that doesn't need subviews) (i.e. the field widget must have useSubView set to a falsy value) In studio, click on that field. Before this commit, the buttons to navigate to the X2many views where visible, which made no sense, and could cause crashes. After this commit, x2many fields not using subviews don't show those buttons hen clicked on. Forward-Port-Of: odoo/enterprise#46536 Forward-Port-Of: odoo/enterprise#46276