Search
Navigate
Branch
Monday, May 10, 2021
13 changes
New functionality added to Odoo
Adds a new Planning Portal module that lets companies publish planning slots on the Odoo website so external users can view schedules through the portal. This improves transparency for customers and partners, though the proposal notes further configuration work may be needed before final rollout.
Original PR description
This introduces a new module `planning_portal` which allows to publish & see planning slots on the Odoo website. Since planning is becoming a more and more important feature in companies and since customers want more transparancy all the time this moves Odoo a step forward. Note: This PR is not completely finished. If we'd add this in I'd propose to add a configuration option in the settings of the `planning` app which then auto-installs this module. We will continue our efforts if this new app can get approval. CC @wardm95
Enhancements to existing features
The Planning app onboarding tour has been updated with added and revised steps to better guide users through key workflows. Related planning views in project forecasting and helpdesk timesheets were also adjusted, making the experience clearer and easier to follow.
Original PR description
Generic UX improvement. More details TBD. task-2508723
Resolved issues and error corrections
Removed obsolete signing code that was no longer used and cleaned up a warning caused by an undeclared variable. This reduces background noise for maintainers and helps keep the signing feature more reliable without changing the user experience.
Original PR description
Before this commit, some dead code remained from older versions and an undeclared variable 'success' triggered some warning in https://github.com/odoo/enterprise/pull/17991 taskid: 2523517
Miscellaneous changes
The amount already depreciated (from another software/another version) was not taken into account when selling an asset. opw-[2518970](https://www.odoo.com/web#id=2518970&model=project.task&view_type=form&cids=1&menu_id=) Forward-Port-Of: odoo/enterprise#18229
Original PR description
The amount already depreciated (from another software/another version) was not taken into account when selling an asset. opw-[2518970](https://www.odoo.com/web#id=2518970&model=project.task&view_type=form&cids=1&menu_id=) Forward-Port-Of: odoo/enterprise#18229
Employee profiles now make it easier to find and manage the license plate for a private vehicle. When private car use is enabled on a contract, the license plate can be edited on the employee or user profile; otherwise it comes from the company car assigned to the employee.
Original PR description
Pad:https://pad.odoo.com/p/r.d74ee89df60138e4cc2a572a0f063ad4 Task:https://www.odoo.com/web#id=2158962&action=327&model=project.task&view_type=form&menu_id=4720
The app switcher menu order has been reorganized so related applications appear closer together and commonly used apps are easier to find. This should reduce navigation time for users working across connected areas such as Sales, Accounting, Marketing, Inventory, HR, and Services.
Original PR description
PURPOSE Reorder the menus of the app switcher in order to reduce the distance between correlated applications, and bring the most common apps upward. SPECIFICATIONS Current Currently, in master with all apps installed: https://www.awesomescreenshot.com/image/7489455?key=80bac6cba18b7984fd0b40c11eff6c4e 1) the 'Sales' app is 18 menus away from 'Accounting' 2) 'Social Marketing' is 25 menus away from 'Email Marketing' 3) 'IoT' is on the second line of menus, nowhere close to the inventory apps 4) etc. To be Reorder the menus of the app switcher. PR: #17989 Task Id: 2513082 I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Currently, when we delete the 'customer care' team generated by default and create a new team then it generates an error. In this commit, we fix this issue by creating a new stage_id if the team doesn't get a default stage_id. After this, the team is successfully created. Task-id: 2507832 Forward-Port-Of: odoo/enterprise#17878
Original PR description
Currently, when we delete the 'customer care' team generated by default and create a new team then it generates an error. In this commit, we fix this issue by creating a new stage_id if the team doesn't get a default stage_id. After this, the team is successfully created. Task-id: 2507832 Forward-Port-Of: odoo/enterprise#17878
[FIX] account_reports: display the fiscal position filter properly in all cases Before, when there was only one foreign vat fiscal position in the same country as the domestic country, but on a distinct state, the options were computed properly, but the filter did not show up in the report, while it should (because we want to be able switching between 'domestic' and that fiscal position). [IMP] account_reports: tax closing with foreign vat: improve labelling We now only display the cou
Original PR description
[FIX] account_reports: display the fiscal position filter properly in all cases Before, when there was only one foreign vat fiscal position in the same country as the domestic country, but on a…
[FIX] account_reports: display the fiscal position filter properly in all cases Before, when there was only one foreign vat fiscal position in the same country as the domestic country, but on a distinct state, the options were computed properly, but the filter did not show up in the report, while it should (because we want to be able switching between 'domestic' and that fiscal position). [IMP] account_reports: tax closing with foreign vat: improve labelling We now only display the country on the closing entry when it's useful, that is, when there are foreign VAT fiscal positions defined. Same goes for the states: we show them only when it adds information. Also, we don't call the domestic closing entry 'Domestic' anymore. Instead, we label it with its country and country states when needed, just like any other closing move. [FIX] account_reports: tax closing: allow switching from 'annually' to 'monthly' without duplicating closing moves Before, when switching from 'annually' to 'monthly' tax return periodicity with a draft closing move in the current period, a new move was created for the current month instead of overwriting the dates and labels of the existing one. This resulted in multiple closing next activities showing up on the dashboard. Now, we overwrite the existing move properly. Forward-Port-Of: odoo/enterprise#18204
To reproduce the issue: 1) install a CoA without any default tax receivable of payable account, and no value set for these fields on any tax group (for example l10n_nl) 2) Post an invoice in a previous period 3) open the tax report for this previous period and click on "closing journal entry" ===> No error is raised, the entry is created with 2 lines at 0. Now, try to click on the refresh buttonof the closing entry ===> A RedirectWarning is raised, as your tax groups aren't configured.
Original PR description
To reproduce the issue: 1) install a CoA without any default tax receivable of payable account, and no value set for these fields on any tax group (for example l10n_nl) 2) Post an invoice in a…
To reproduce the issue: 1) install a CoA without any default tax receivable of payable account, and no value set for these fields on any tax group (for example l10n_nl) 2) Post an invoice in a previous period 3) open the tax report for this previous period and click on "closing journal entry" ===> No error is raised, the entry is created with 2 lines at 0. Now, try to click on the refresh buttonof the closing entry ===> A RedirectWarning is raised, as your tax groups aren't configured. This is because of the way raise_on_empty is used since https://github.com/odoo/enterprise/commit/d4036da02b997b24115e0211d8709d565b1f2904 . When called from the report, it's False ; when called from the button, it's True. We don't want this behavior. The check is now always performed: if the tax groups are not correctly configured, we raise. We also remove the second RedirectWarning, as it does not make sense anymore to raise in case of an empty closing move under any circumstances. Forward-Port-Of: odoo/enterprise#18216 Forward-Port-Of: odoo/enterprise#18206
Instead of matching only the transfer account set on the company, be less restrictive and match them using the transfer account prefix instead. issue: 2486669 Forward-Port-Of: odoo/enterprise#17940
Original PR description
Instead of matching only the transfer account set on the company, be less restrictive and match them using the transfer account prefix instead. issue: 2486669 Forward-Port-Of: odoo/enterprise#17940
Forward-Port-Of: odoo/enterprise#18202
Original PR description
Forward-Port-Of: odoo/enterprise#18202
[FIX] l10n_de_reports: avoid shadowing XML export of the tax report for other countries when installed When l10n_de_reports was installed together with other l10n modules defining an xml export for their tax report, the German XML could shadow the others because of a missing country check at the beginning of the function. [FIX] l10n_be_reports, l10n_se_reports, l10n_sg_reports, l10n_uk_reports: correct country check in tax report-related functions saas-14.3 introduced foreign VAT fisc
Original PR description
[FIX] l10n_de_reports: avoid shadowing XML export of the tax report for other countries when installed When l10n_de_reports was installed together with other l10n modules defining an xml export for their tax report, the German XML could shadow the others because of a missing country check at the beginning of the function. [FIX] l10n_be_reports, l10n_se_reports, l10n_sg_reports, l10n_uk_reports: correct country check in tax report-related functions saas-14.3 introduced foreign VAT fiscal positions: it is now possible for a single company to use the tax reports from multiple countries. When overriding a tax report function, the country should hence be checked using the dedicated helper and the options, not with the fiscal country of the company. Forward-Port-Of: odoo/enterprise#18196
Before this commit the subqueries did select any move line linked to the partner to set the 'with_overdue_invoices' followup status. Therefore, lines related to payment were selected since there was no where clause on account type, and it did also select already reconciled lines. With this commit, we make sure that only unreconciled lines on receivable accounts are selected and that the followup status is correct. It actually restores all the condition that were defined in the WHERE cl
Original PR description
Before this commit the subqueries did select any move line linked to the partner to set the 'with_overdue_invoices' followup status. Therefore, lines related to payment were selected since there was no where clause on account type, and it did also select already reconciled lines. With this commit, we make sure that only unreconciled lines on receivable accounts are selected and that the followup status is correct. It actually restores all the condition that were defined in the WHERE clause of the CTE that has been removed for performance reasons. OPW-2522263 Forward-Port-Of: odoo/enterprise#18140 Forward-Port-Of: odoo/enterprise#18129