Daily updates from Odoo
Navigate
Branch
Tuesday, July 23, 2019
17 changes
Enhancements to existing features
Portal users who access a shared document through a token can now download the attachments that are visible in the document chatter. Each visible attachment gets its own access token, helping users access the files they should see without exposing private or internal attachments.
Original PR description
Before this commit if a user has access to a document thanks to an access_token, he would already be able to see the chatter for the document, but he would not be able to download the attachments…
Before this commit if a user has access to a document thanks to an access_token, he would already be able to see the chatter for the document, but he would not be able to download the attachments that are shown to him on that same chatter. The goal of this commit it to let the user download those attachments. To solve this issue we could have used the access_token of the main document, but this would allow any user with the token to access all attachments of the document, including those he should potentially not be able to see such as those from internal notes. Instead we ensure a different access_token is properly set on each of the attachments that are going to be shown and we update their links accordingly. This allows for a more granular access control, and it also takes advantage of the existing /web/content route without having to adapt it. Part of task-37264 Co-authored-by: Pratima Gupta <pgu@odoo.com> Co-authored-by: Sébastien Theys <seb@odoo.com> Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The gamification app no longer keeps a separate stored field for a user's karma ranking. This simplifies the system because the ranking is now calculated directly where it is displayed, reducing unnecessary data maintenance without changing the user experience.
Original PR description
Since task Id 2000687 and PR #33475, karma position field is not necessary anymore as the karma position is computed directly in the website_profile controller. Task ID:2001367
Cash handling in Point of Sale is now easier to manage with guided cashbox counting, clearer session closing screens, and reusable cashbox templates. Businesses can set cash difference limits per POS configuration and managers receive a warning before approving sessions with larger-than-allowed cash discrepancies.
Original PR description
Current behavior before PR: We have a non intuitive way to manage the cash control. Desired behavior after PR is merged: We have a model to manage our cash control that will open a pop up to register the amount of coins/bills. We also change some error message and moved the amount of authorized difference to the pos config. Also added warning if manager wants to close a session with higher difference than it should be allowed. Task id: 1934784 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Uploading vendor bills and customer invoices now opens the file selection window directly, removing an unnecessary intermediate step. This streamlines invoice entry from dashboards and list views, and related electronic invoicing flows were adjusted to support the simpler process.
Original PR description
Task 2007561 We want to avoid this intermediate screen; Instead, directly open the selection files window... Done from dashboard button + vendor bill list view & customer invoice list view. Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update simplifies and clarifies how employee time off is requested, viewed, and approved. It streamlines manager and administrator responsibilities, improves dashboard usability, and adds clearer employee notifications when leave is approved or refused.
Original PR description
Purpose ======= Having a clean policy in leave access right. If there are some internal need or bugs, read this before decided if it is an expected brhavior or not. It is what we want in a standrard…
Purpose
=======
Having a clean policy in leave access right. If there
are some internal need or bugs, read this before decided
if it is an expected brhavior or not. It is what we want
in a standrard point of vew.
Specification
=============
Access rights Policy
--------------------
Remove Time Off - Team Leader access right
Leave_manager_id is now requried, by default it
is = parent_id for admin it is admin by default (data
employee_admin)
3 access rights:
- Internal User
- Time Off - All Approver
- Time Off - Administrator
3 fields for "manager"
- parent_id
- leave_manager_id
- manager_id on department
Department
Is just there for information. So never use it in
default filters
Rules Policy
------------
Don't forget to take the leave type configuration into
account
* no validation means automatic
* officer validation means you need to be at least
holidays_user to approve
* manager validation means anyone who is at least
leave_manager_id can approve
Internal User
-------------
In double validation mode he:
- can only do the first approval
- can see the everyone's leaves with a anonymisation of
the leave description
- can create a leave (even if leave type is directly approved)
- can refuse its own leaves (till not reported in payslip)
- can reset to draft his own leaves and reconfirm them
- can delete a leave in draft state
- can cancel a leave if the date_start is in the future
- cannot validate its own leaves
If leave type is configured in manager mode, he:
- can approve or refuse the leaves if he is leave_manager_id
If leave type is configured in both mode, he:
- can only do the first approval or refuse for the leave
if he is leave_manager_id
Time Off - All Approver
-----------------------
In double validation mode he:
- can only do the second approval
- can see, write, read all leaves and perform the second
approval.
- Can set a leaves as reported in payslip.
- Cannot validate its own leaves
- cannot configure leave type
- cannot create leaves in batch
Time Off - Administrator
------------------------
In double validation mode he:
- can do all the approvals
- can bypass all leaves (approve or refuse).
- can configure Time Off Types
- can create batch leaves
- can validate its own leaves
Menu
----
- My Time Off (access rights: internal user)
- Dashboard
- Time Off Requests
- Allocation Requests
- My Team (rename into "Everyone", access rights: internal
user. default filters on current year and group by
employee; default view: gantt can switch to list and form)
- Managers
- To Approve (internal user who are leave_manager_id
see and can approve. See only leave he has to approve
(domain))
- Time Off
- Allocation
- All
- Time Off
- Allocation
- Payroll
- Time Off to report.
- Reporting (access right: time off administrator)
- Time Off Analysis
- Report by Department
- Configuration (access right: time off administrator)
Usability
---------
- In all list of "manager menus", add actions to change
status in mass
- In leave type data:
- move Home Working from data to demo data
- There are 2 Paid time off, get rid of the company on
it and share it on all companies (keep only the one
in data)
- Leave type like this:
- Overtime Compensation/compensatory days (keep only
one of both, to avoid having 2 same leaves in
demo data). Validation by: team leader and hr
officer, no validity date
- Paid Time Off 2019. Validation by Team Leader
and Payroll Officer. Remove validity, remove 2019.
- Unpaid. Can be taken in hours. Approved by Payroll
officer and team leader. No allocation needed.
- New leave request: order of leave type in the m2o:
1. leaves where allocation are fixed by rh and remaining
> 0 and allocated > 0
2. leaves where free allocation. Where reaming is > 0
and allocated >0
3. One already taken
4. All other leaves.
- Remove the sequence widget in leave type
- The employee should get a notification when his leave is
refused "Your "leave_type_name_" planned on "start_date"
has been refused"
- from the dashboard calendar, the reset to draft should lead
to edit (avoid user has to click on edit)
- An employee should be notified when a leave is approved
"Your [leave_type_name] on [start date] has been approved"
Leave Dashboard V2
------------------
https://drive.google.com/file/d/1pMCqDlecqM7ngvmhJJdWtkG2_GiXHyIX/view?usp=sharing
Testing
-------
Everything concerning the leave requests has to be tested.
All the access rights have been reviewed and need testing.
Migration
---------
Don't forget to keep the filters in the calendar view (otherwise RIP perfomances and usability)
TaskID: 1950998Accounting settings no longer show options to manually install asset and deferred revenue features. These features are now installed automatically when needed, reducing setup steps and simplifying configuration for users.
Original PR description
Remove the settings that would previously install the account_asset and account_deferred_revenue as they become auto_install. opw-2006605 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
When the POS IoT module is installed, the relevant point-of-sale journal settings are now shown again so users can configure terminal usage. This helps businesses manage cash control and payment terminal setup without hidden configuration options.
This update simplifies Time Off permissions and approval responsibilities so employees, approvers, and administrators have clearer roles. It also improves leave request handling, menu organization, notifications, and payroll reporting flows, making time off management easier and more consistent across the company.
Original PR description
Purpose ======= Having a clean policy in leave access right. If there are some internal need or bugs, read this before decided if it is an expected brhavior or not. It is what we want in a standrard…
Purpose
=======
Having a clean policy in leave access right. If there
are some internal need or bugs, read this before decided
if it is an expected brhavior or not. It is what we want
in a standrard point of vew.
Specification
=============
Access rights Policy
--------------------
Remove Time Off - Team Leader access right
Leave_manager_id is now requried, by default it
is = parent_id for admin it is admin by default (data
employee_admin)
3 access rights:
- Internal User
- Time Off - All Approver
- Time Off - Administrator
3 fields for "manager"
- parent_id
- leave_manager_id
- manager_id on department
Department
Is just there for information. So never use it in
default filters
Rules Policy
------------
Don't forget to take the leave type configuration into
account
* no validation means automatic
* officer validation means you need to be at least
holidays_user to approve
* manager validation means anyone who is at least
leave_manager_id can approve
Internal User
-------------
In double validation mode he:
- can only do the first approval
- can see the everyone's leaves with a anonymisation of
the leave description
- can create a leave (even if leave type is directly approved)
- can refuse its own leaves (till not reported in payslip)
- can reset to draft his own leaves and reconfirm them
- can delete a leave in draft state
- can cancel a leave if the date_start is in the future
- cannot validate its own leaves
If leave type is configured in manager mode, he:
- can approve or refuse the leaves if he is leave_manager_id
If leave type is configured in both mode, he:
- can only do the first approval or refuse for the leave
if he is leave_manager_id
Time Off - All Approver
-----------------------
In double validation mode he:
- can only do the second approval
- can see, write, read all leaves and perform the second
approval.
- Can set a leaves as reported in payslip.
- Cannot validate its own leaves
- cannot configure leave type
- cannot create leaves in batch
Time Off - Administrator
------------------------
In double validation mode he:
- can do all the approvals
- can bypass all leaves (approve or refuse).
- can configure Time Off Types
- can create batch leaves
- can validate its own leaves
Menu
----
- My Time Off (access rights: internal user)
- Dashboard
- Time Off Requests
- Allocation Requests
- My Team (rename into "Everyone", access rights: internal
user. default filters on current year and group by
employee; default view: gantt can switch to list and form)
- Managers
- To Approve (internal user who are leave_manager_id
see and can approve. See only leave he has to approve
(domain))
- Time Off
- Allocation
- All
- Time Off
- Allocation
- Payroll
- Time Off to report.
- Reporting (access right: time off administrator)
- Time Off Analysis
- Report by Department
- Configuration (access right: time off administrator)
Usability
---------
- In all list of "manager menus", add actions to change
status in mass
- In leave type data:
- move Home Working from data to demo data
- There are 2 Paid time off, get rid of the company on
it and share it on all companies (keep only the one
in data)
- Leave type like this:
- Overtime Compensation/compensatory days (keep only
one of both, to avoid having 2 same leaves in
demo data). Validation by: team leader and hr
officer, no validity date
- Paid Time Off 2019. Validation by Team Leader
and Payroll Officer. Remove validity, remove 2019.
- Unpaid. Can be taken in hours. Approved by Payroll
officer and team leader. No allocation needed.
- New leave request: order of leave type in the m2o:
1. leaves where allocation are fixed by rh and remaining
> 0 and allocated > 0
2. leaves where free allocation. Where reaming is > 0
and allocated >0
3. One already taken
4. All other leaves.
- Remove the sequence widget in leave type
- The employee should get a notification when his leave is
refused "Your "leave_type_name_" planned on "start_date"
has been refused"
- from the dashboard calendar, the reset to draft should lead
to edit (avoid user has to click on edit)
- An employee should be notified when a leave is approved
"Your [leave_type_name] on [start date] has been approved"
Leave Dashboard V2
------------------
https://drive.google.com/file/d/1pMCqDlecqM7ngvmhJJdWtkG2_GiXHyIX/view?usp=sharing
Testing
-------
Everything concerning the leave requests has to be tested.
All the access rights have been reviewed and need testing.
Migration
---------
Don't forget to keep the filters in the calendar view (otherwise RIP perfomances and usability)
TaskID: 1950998The map view no longer shows the group-by option because grouping records is not useful in this context. This makes the search controls clearer and reduces confusion for users working with maps.
Original PR description
Groupby doesn't make any sense in map view.
Resolved issues and error corrections
This fix prevents Point of Sale errors when a customer's fiscal position removes a tax, and ensures taxes are recalculated correctly when switching to a customer without special tax rules. This helps cashiers avoid checkout disruptions and reduces the risk of applying the wrong tax to orders.
Original PR description
This commit fixes the following faulty behaviors: 1. There is a traceback in the pos ui when the selected customer has fiscal position that maps a tax to nothing. To prevent this behavior, we avoid…
This commit fixes the following faulty behaviors: 1. There is a traceback in the pos ui when the selected customer has fiscal position that maps a tax to nothing. To prevent this behavior, we avoid to add the undefined tax destination. 2. When you change the customer in pos ui from someone who has fiscal position to someone without, the tax in the order remains to be based on the previous customer. The tax should change to original tax of the product or to the tax mapped by the default fiscal position of the session. To avoid this behavior, we now set the default fiscal position on the order when a customer has no fiscal position. **To reproduce:** **Issue 1. Error when `product1` is selected for `partner1`** *Steps:* 1. create fiscal position `fpos` that maps `tax1` to nothing 2. assign `fpos` to `partner1` 3. activate fiscal position per order in pos.config and add `fpos` 4. assign `tax1` to `product1` (should be available in pos) 5. open new pos session 6. select `product1` 7. issue: error when selecting `partner1` as customer *Reason.* In `_map_tax_fiscal_position`, `tax=undefined` is pushed to `taxes`. **Issue 2. Tax for `partner1` is active in `partner2` even if `partner2` has no fiscal position.** *Steps:* 1. create fiscal position `fpos` that maps `tax1` to `tax2` 2. assign `fpos` to `partner1` 3. activate fiscal position per order in pos.config and add `fpos` 4. assign `tax1` to `product1` 5. open new pos session 6. select `product1` -> tax should be `tax1` since no customer 7. select `partner1` -> tax changed to `tax2` because of `fpos` in `partner1` 8. issue: select new customer without fiscal position -> tax should be `product1`'s original tax because no fiscal position, but tax from previous customer is not changed. *Reason.* If the newly selected customer has no fiscal position, order.fiscal_position is not updated so it takes the old fiscal position. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Installing a demo chart of accounts from the web interface now uses the correct demo company information instead of selecting from the user's allowed companies. This prevents critical installation errors and makes web-based demo company setup behave consistently with command-line installs.
Original PR description
If we try to install a chart of account from the demo to a new demo company: * When using CLI with -i module works perfectly * When installing from web interface (example runbot) it was failing and throwing a critical error. This was because was not taking into account the information in the demo data to load the chart of account of a specific company, insted it was using any of the users allowed companies. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes SMS chatter behavior so empty SMS notifications no longer show unnecessary popovers or tooltips. It also improves related SMS sending, composer messages, and number-format handling so users get clearer feedback and smoother updates.
Original PR description
PURPOSE Improve SMS UX integration SPECIFICATION Fix recent SMS merge: do not display tooltip / popover about SMS information in chatter if there was no recipients linked to the SMS message. LINKS Task 1922187
When users create or edit sales, expenses, and related analytic records, unit choices are now limited to the product's relevant category. This prevents incorrect unit selections after reopening records and helps keep orders and expenses consistent.
Original PR description
Enforce the domain of the UOM not by an onchange but by a domain. Example of an issue if the domain is enforced by an onchange: - create an order - add an order line - select the product - select an…
Enforce the domain of the UOM not by an onchange but by a domain. Example of an issue if the domain is enforced by an onchange: - create an order - add an order line - select the product - select an uom > the uom presented are the one from the product category. -Save - edit - select an uom > all UOM are presented even the ones of other categories This commit enforce this new logic at most places. Description of the issue/feature this PR addresses: Display only category's uom Current behavior before PR: At the time of editing a sale order line, it displays all category's uom. Desired behavior after PR is merged: At the time of creating or editing a sale order line, it displays only related category's uom. Task: https://www.odoo.com/web#id=2003959&action=333&active_id=809&model=project.task&view_type=form&menu_id=4720 Pad: https://pad.odoo.com/p/r.35c17fb973d768886a273c818f42ea02 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix updates French payroll configuration data to use the correct payroll type reference. It helps ensure employee payroll structures for executive and non-executive staff load and work as expected.
Subscription lines now consistently show only units of measure that match the selected product category, both when creating and editing records. This prevents users from accidentally selecting an incompatible unit and helps keep subscription data accurate.
Original PR description
Enforce the domain of the UOM not by an onchange but by a domain. Example of an issue if the domain is enforced by an onchange: - create a subscription - add subscription line - select the product - select an uom > the uom presented are the one from the product category. - save - edit - select an uom > all UOM are presented even the ones of other categories This commit enforce this new logic at most places. task - 2003959 Description of the issue/feature this PR addresses: Display only category's uom Current behavior before PR: At the time of editing a sale subscription line, it displays all category's uom. Desired behavior after PR is merged: At the time of creating or editing a subscription line, it displays only related category's uom. Task: https://www.odoo.com/web#id=2003959&action=333&active_id=809&model=project.task&view_type=form&menu_id=4720 Pad: https://pad.odoo.com/p/r.35c17fb973d768886a273c818f42ea02
This fixes an internal payroll accounting test that could sometimes cancel the wrong payslip because it relied on an unpredictable order. The change makes test results more consistent, helping reduce false failures during development and release checks.
Original PR description
In the test_04_hr_payslip we were depending on the order of the One2many slip_ids, but the order of the recordset is not guaranteed. This lead to non deterministic errors where the wrong payslip was cancelled.
Code cleanup and technical improvements
Stock valuation processes now use elevated access only where needed, reducing unnecessary administrator-level operations. This helps inventory accounting run more reliably for regular users while keeping permission handling tighter.
Original PR description
Carefully sudo when necessary. task-2034044