Daily updates from Odoo
Navigate
Branch
Thursday, December 19, 2019
22 changes
New functionality added to Odoo
This update adds Polish states to the country and address data. Users can now select the appropriate Polish state when entering or maintaining addresses, improving data accuracy for contacts and businesses in Poland.
Original PR description
Description of the issue/feature this PR addresses: Polish states Current behavior before PR: Polish states are not available Desired behavior after PR is merged: The possibility of choosing Polish states in address -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Enhancements to existing features
This update tightens timesheet access so employees can be limited to seeing only their own entries, while managers and administrators retain broader validation rights. It also improves the timer experience in list and kanban views and supports more controlled invoicing of timesheet-based services by date.
Original PR description
Access rights ============= Purpose ------- Currently, the lowest access right level for Timesheets allows a user to see the timesheets from all employees. Some companies do not want to have this…
Access rights
=============
Purpose
-------
Currently, the lowest access right level for Timesheets allows a user
to see the timesheets from all employees. Some companies do not want
to have this information shared.
As we already have three levels of access rights, creating a new one
would be too much. Instead, we are using this opportunity to
clean/simplify the current access right levels.
Specification
-------------
Remove the current access rights and replace them with the following:
- 'See own timesheets' the user can:
- read/write/create/delete his own timesheets only
- cannot timesheet on projects whose Visibility is set on
'Invited employees' if the user is not a follower
- see the 'My Timesheets' and the 'Timesheet App' menus
- 'See all timesheets' the user can:
- read/write/create/delete all timesheets
- cannot see the Timesheets of Projects whose Visibility is set
on 'Invited employees' if the user is not a follower
- see the 'My Timesheets' + 'All Timesheets' + 'Timesheet App' +
'To Validate' menus
- validate the timesheets of whom he is the 'Timesheet
Responsible' or the 'Manager'
- 'Administrator' the user can:
- read/write/create/delete all timesheets
- see all menus
- validate the Timesheets of all employees
- Write tests
New Validation Process
======================
Purpose
-------
Currently, timesheets are validated by employees as a whole. However,
as a manager, it is difficult to evaluate the timesheets of an
employee for projects you know nothing about. Therefore, it would make
more sense for a manager to validate the timesheets of his projects
and to leave the rest to the other managers.
In addition, having a date on the employees leaves room for error and
performance issues, so we are introducing a new checkbox at the
timesheet level.
Specification
-------------
Remove the 'Timesheets Validation Date' field on the employee
- replace it with a 'Timesheet Validated' checkbox (hidden field) on
the timesheet entry
- By default, this field is set to false
- Once the manager validates the timesheets, switch the field to
true
- Filtering on 'Validated' timesheets should display timesheets for
which 'Timesheet Validated' is true
- Filtering on 'Non-Validated' timesheets should display timesheets
for which 'Timesheet Validated' is false
Rename the title of the validation menus into:
- To Validate > Last Weeks -> Timesheets from Last Week to Validate
- To Validate > Last Month -> Timesheets from Last Month to Validate
Grid view: display projects on which the user timesheeted in the
past 30 days (group_expand), or the employees who timesheeted in the
past 30 days for the 'To Validate' menus)
Open the 'To Validate' menus on the oldest non-validated timesheet
you can find.
Clicking on 'Validate' should validate all the timesheets displayed
on the screen. List all the elements displayed in the view based on
the group by applied in the 'Validate the timesheets' modal.
When validating timesheets, bypass timesheets that were already
validated in the past in order to avoid performance issues
Timer list
==========
Purpose
-------
Have an overview of the timesheets you need to do during the day.
Easily track time spent on tasks using the timer instead of having to
write down somewhere at what time you started an activity. Allow more
flexibility if an activity if interrupted by another one (so you
don't need to do mental arithmetic to determine how much time the
first activity took substracted by the time spent on the second
activity).
Specification
-------------
- Move the time from fsm to hr_timesheet.
- Add fa-play-circle and fa-stop-circle icons in the 'My Timesheets'
menu:
- on the left of the 'Duration' field in the list view
- on the top right corner of the kanban card in the kanban view
- on the right of the first column in the grid view
- Display these icons
- for non-validated timesheets only
- if the Encoding Unit is Hours
- Clicking on the play button should start and display the timer and
switch to the stop icon
- Clicking on the stop button should halt and stop displaying the
timer and switch to the play icon
- While the timer is running, the 'Duration' field should not
be editable
- Only one timer can run at the same time. If the user clicks on the
start button of timesheet B while the timer is running for
timesheet A, timesheet B should start and timesheet A should stop.
Time selection when invoicing
=============================
Purpose
-------
Allow selecting a timeframe to invoice when the user is invoicing on
a periodical basis. For instance, the user invoices each time at the
end of the month. For some reason (he got sick, there was a bank
holiday...), he only invoices of the 4th of the following month.
Now the timesheets that are about to be invoiced include some that
were recorded in the meantime.
Specification
-------------
- Add an 'Invoice timesheets up to mm/dd/yyyy' field on the Invoice
Creation modal
- display this field only when creating an Invoice for a Service
whose Invoicing Policy is on 'Timesheets on tasks'
- not required
- Set today's date by default
- if this field is set, the quantity to invoice should only
include the not yet invoiced (and validated) timesheets up to
this date (included)
- if this field is not set, include all not yet invoiced (and
validated) timesheets without distinction.
- Add the following tooltip: Only timesheets not yet invoiced
(and validated, if applicable) up to this date included will be
invoiced. If no date is indicated, all timesheets not yet
invoiced (and validated, if applicable) will be invoiced
without distinction.
Miscellaneous
=============
Purpose
-------
Small usability improvements.
- Move 'Create SO from Task' to sale_timesheet -> Means Enterprise to
Community).
- Add the pivot view to the 'All Timesheets' menu
- Add the 'Today' button on the grid view of all menus (see the
Reporting > Timesheets by Project menu for reference)
Co-authored-by: Lucas Lefèvre <lul@odoo.com>
Co-authored-by: Yannick Tivisse <yti@odoo.com>
TaskID: 2088586Point of Sale customer lists now show only contacts that have previously acted as customers, reducing clutter from unrelated partners. Each paid POS order also increases the customer ranking for the buyer, helping keep customer records accurate over time.
Original PR description
Following the removing of the vendor and customer field, when we wanted to display customer in the pos, we saw all. Now, we only see partner with a customer rank higher than 0. We also increase the customer rank each time a pos order is paid. task-id: 2092483 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Default values are now selected based on the company being set on a new record, rather than always using the current user's company. This improves consistency in multi-company setups and helps avoid records being created with values from the wrong company.
Original PR description
**Description of the issue/feature this PR addresses:** Suppose a model that have "A" and "company_id" fields. In multi-company, the user in company C creates a record of this model with company_id =…
**Description of the issue/feature this PR addresses:** Suppose a model that have "A" and "company_id" fields. In multi-company, the user in company C creates a record of this model with company_id = C2. In the creation of this record, the `default_get` method is executed. If in context doesn't exist a "`default_A`", then A field will have the value obtained in `get_model_defaults` method. But this method will return the default in company C instead of the default in company C2. So, it's not consistent to have a record in company C2 and one of its attributes (subfields) in company C. **Current behavior before PR:** The `get_model_defaults` method always considers the company of the user for finding default values. **Desired behavior after PR is merged:** The `get_model_defaults` method first considers the `default_company_id` context for finding default values, and if doesn't exist this context then finds with the company of the user. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Timesheet access is now more private, so employees only see the records they are allowed to see while managers and administrators retain the right approval tools. The approval process is more precise by validating individual timesheet entries by project or task, and users gain easier time tracking with timers in key timesheet views.
Original PR description
Access rights ============= Purpose ------- Currently, the lowest access right level for Timesheets allows a user to see the timesheets from all employees. Some companies do not want to have this…
Access rights
=============
Purpose
-------
Currently, the lowest access right level for Timesheets allows a user
to see the timesheets from all employees. Some companies do not want
to have this information shared.
As we already have three levels of access rights, creating a new one
would be too much. Instead, we are using this opportunity to
clean/simplify the current access right levels.
Specification
-------------
Remove the current access rights and replace them with the following:
- 'See own timesheets' the user can:
- read/write/create/delete his own timesheets only
- cannot timesheet on projects whose Visibility is set on
'Invited employees' if the user is not a follower
- see the 'My Timesheets' and the 'Timesheet App' menus
- 'See all timesheets' the user can:
- read/write/create/delete all timesheets
- cannot see the Timesheets of Projects whose Visibility is set
on 'Invited employees' if the user is not a follower
- see the 'My Timesheets' + 'All Timesheets' + 'Timesheet App' +
'To Validate' menus
- validate the timesheets of whom he is the 'Timesheet
Responsible' or the 'Manager'
- 'Administrator' the user can:
- read/write/create/delete all timesheets
- see all menus
- validate the Timesheets of all employees
- Write tests
New Validation Process
======================
Purpose
-------
Currently, timesheets are validated by employees as a whole. However,
as a manager, it is difficult to evaluate the timesheets of an
employee for projects you know nothing about. Therefore, it would make
more sense for a manager to validate the timesheets of his projects
and to leave the rest to the other managers.
In addition, having a date on the employees leaves room for error and
performance issues, so we are introducing a new checkbox at the
timesheet level.
Specification
-------------
Remove the 'Timesheets Validation Date' field on the employee
- replace it with a 'Timesheet Validated' checkbox (hidden field) on
the timesheet entry
- By default, this field is set to false
- Once the manager validates the timesheets, switch the field to
true
- Filtering on 'Validated' timesheets should display timesheets for
which 'Timesheet Validated' is true
- Filtering on 'Non-Validated' timesheets should display timesheets
for which 'Timesheet Validated' is false
Rename the title of the validation menus into:
- To Validate > Last Weeks -> Timesheets from Last Week to Validate
- To Validate > Last Month -> Timesheets from Last Month to Validate
Grid view: display projects on which the user timesheeted in the
past 30 days (group_expand), or the employees who timesheeted in the
past 30 days for the 'To Validate' menus)
Open the 'To Validate' menus on the oldest non-validated timesheet
you can find.
Clicking on 'Validate' should validate all the timesheets displayed
on the screen. List all the elements displayed in the view based on
the group by applied in the 'Validate the timesheets' modal.
When validating timesheets, bypass timesheets that were already
validated in the past in order to avoid performance issues
Timer list
==========
Purpose
-------
Have an overview of the timesheets you need to do during the day.
Easily track time spent on tasks using the timer instead of having to
write down somewhere at what time you started an activity. Allow more
flexibility if an activity if interrupted by another one (so you
don't need to do mental arithmetic to determine how much time the
first activity took substracted by the time spent on the second
activity).
Specification
-------------
- Move the time from fsm to hr_timesheet.
- Add fa-play-circle and fa-stop-circle icons in the 'My Timesheets'
menu:
- on the left of the 'Duration' field in the list view
- on the top right corner of the kanban card in the kanban view
- on the right of the first column in the grid view
- Display these icons
- for non-validated timesheets only
- if the Encoding Unit is Hours
- Clicking on the play button should start and display the timer and
switch to the stop icon
- Clicking on the stop button should halt and stop displaying the
timer and switch to the play icon
- While the timer is running, the 'Duration' field should not
be editable
- Only one timer can run at the same time. If the user clicks on the
start button of timesheet B while the timer is running for
timesheet A, timesheet B should start and timesheet A should stop.
Time selection when invoicing
=============================
Purpose
-------
Allow selecting a timeframe to invoice when the user is invoicing on
a periodical basis. For instance, the user invoices each time at the
end of the month. For some reason (he got sick, there was a bank
holiday...), he only invoices of the 4th of the following month.
Now the timesheets that are about to be invoiced include some that
were recorded in the meantime.
Specification
-------------
- Add an 'Invoice timesheets up to mm/dd/yyyy' field on the Invoice
Creation modal
- display this field only when creating an Invoice for a Service
whose Invoicing Policy is on 'Timesheets on tasks'
- not required
- Set today's date by default
- if this field is set, the quantity to invoice should only
include the not yet invoiced (and validated) timesheets up to
this date (included)
- if this field is not set, include all not yet invoiced (and
validated) timesheets without distinction.
- Add the following tooltip: Only timesheets not yet invoiced
(and validated, if applicable) up to this date included will be
invoiced. If no date is indicated, all timesheets not yet
invoiced (and validated, if applicable) will be invoiced
without distinction.
Miscellaneous
=============
Purpose
-------
Small usability improvements.
- Move 'Create SO from Task' to sale_timesheet -> Means Enterprise to
Community).
- Add the pivot view to the 'All Timesheets' menu
- Add the 'Today' button on the grid view of all menus (see the
Reporting > Timesheets by Project menu for reference)
Co-authored-by: Lucas Lefèvre <lul@odoo.com>
Co-authored-by: Yannick Tivisse <yti@odoo.com>
TaskID: 2088586The push notification component now stores its Firebase support files in the expected shared library location. This keeps the module’s assets better organized and helps reduce maintenance issues without changing the user experience.
Resolved issues and error corrections
This update fixes several small issues in the website editor's left panel so options refresh correctly and controls display more consistently. It helps users edit pages with fewer confusing or misplaced settings.
The consolidation chart's Groups button now filters results to show only the groups linked to the current chart. This prevents users from seeing unrelated groups and makes consolidation navigation clearer and more accurate.
Original PR description
"Groups" button on consolidation chart view used to display all groups when clicked, instead of only showing the groups linked to the current chart.
Code cleanup and technical improvements
The website editor now handles hidden page elements more consistently by showing or hiding their editing options instead of triggering actions directly on invisible content. This makes editing snippets such as countdowns, popups, and mailing blocks clearer and reduces confusing behavior when content is hidden or saved.
Original PR description
* website, website_mass_mailing
Instead of triggering an event on the invisible element when its related
button in the left panel is clicked, the invisible element's options are
now toggled (shown if were hidden and hidden if were shown). To do that
the new 'onTargetShow' and 'onTargetHide' methods are called, and the
appropriate action can be done there.
Those two new methods are also automatically called in other cases:
- When dropped in the page, after onBuild, 'onTargetShow' is called
for any snippet.
- Before cleanForSave: 'onTargetHide' is called for snippets with the
'o_snippet_invisible' and 'onTargetShow' is called for the others.
In case the element visibility should be toggled another way (like the
close button of a modal), the option can trigger_up an event named
'snippet_option_visibility_update' with a 'show' parameter so that the
the UI is updated accordingly (and so that the options are hidden if
necessary).Miscellaneous changes
Ensure that expression.OR and expression.AND and some other expression.py methods do not propagate or rely on TRUE_DOMAIN and FALSE_DOMAIN that may be muted on some instance. For example, if we did: self.search(expression.OR([])) then in the search method we do something like: received_domain.append(('res_field', '=', False)) before this commit, FALSE_DOMAIN would be altered for any succeeding code that try to use it in `[(0, '=', 1), ('res_field', '=', 'False')]`. Without the changese
Original PR description
Ensure that expression.OR and expression.AND and some other
expression.py methods do not propagate or rely on TRUE_DOMAIN and
FALSE_DOMAIN that may be muted on some instance.
For example, if we did:
self.search(expression.OR([]))
then in the search method we do something like:
received_domain.append(('res_field', '=', False))
before this commit, FALSE_DOMAIN would be altered for any succeeding code
that try to use it in `[(0, '=', 1), ('res_field', '=', 'False')]`.
Without the changeset, the added test would fail with:
[(1, '=', 1), ('id', '=', 1)] != [(1, '=', 1)]
[(0, '=', 1), ('id', '=', 1)] != [(0, '=', 1)]
[(0, '=', 1), ('id', '=', 1)] != [(0, '=', 1)]
[(1, '=', 1), ('id', '=', 1)] != [(1, '=', 1)]
[(1, '=', 1), ('id', '=', 1)] != [(1, '=', 1)]
note: another commit referenced in #41968 should make the TRUE_DOMAIN
and FALSE_DOMAIN immutable.
related to work on opw-2154448
Forward-Port-Of: odoo/odoo#42216
Forward-Port-Of: odoo/odoo#42107Before this commit, users encountered some difficulties to tap/click on the "optional columns" dropdown in list views. This issue only occured on Chrome: rather annoying to use the mobile app. "width: 10px" was used in inline list view but didn't have any sense in the other case. Worse still, Chrome miscalculated the size of the clickable area by a smaller one. This is due to the fact that we add some padding that exceed 10px. See: odoo/enterprise@2f13205 opw-2071605 Description o
Original PR description
Before this commit, users encountered some difficulties to tap/click on the "optional columns" dropdown in list views. This issue only occured on Chrome: rather annoying to use the mobile app. "width: 10px" was used in inline list view but didn't have any sense in the other case. Worse still, Chrome miscalculated the size of the clickable area by a smaller one. This is due to the fact that we add some padding that exceed 10px. See: odoo/enterprise@2f13205 opw-2071605 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 Forward-Port-Of: odoo/odoo#42183
(one step, propagation_cancel = True) Before this - If we have follwing configuration - Manufacturing -> Propagate Cancel -> True Buy -> Propagate Cancel -> True * BOM of a Car - 1) Component 1 -> Iron (MTO & Buy) Now create a SO of product Car and confirm it. It will create a MO (Car) and then PO (Iron). Now if PO is cancelled, it will cancel its move_dest_ids and on change of it MO will be cancelled but delivery move will be remain as it. To cancel this, just called action_
Original PR description
(one step, propagation_cancel = True) Before this - If we have follwing configuration - Manufacturing -> Propagate Cancel -> True Buy -> Propagate Cancel -> True * BOM of a Car - 1) Component 1 -> Iron (MTO & Buy) Now create a SO of product Car and confirm it. It will create a MO (Car) and then PO (Iron). Now if PO is cancelled, it will cancel its move_dest_ids and on change of it MO will be cancelled but delivery move will be remain as it. To cancel this, just called action_cancel() method which already takes care of cancelling moves. Task-2117832 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 Forward-Port-Of: odoo/odoo#41824
My individual CLA. I need it for a PR. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#41829
Original PR description
My individual CLA. I need it for a PR. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#41829
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 Forward-Port-Of: odoo/odoo#42141
Original PR description
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 Forward-Port-Of: odoo/odoo#42141
Validating a move line will remove the reservation on other move line that will take quantity on the same quant. The querry searching for those move lines needs the state of their relative stock move to be neither 'done' nor 'cancel'. This constraint add a join in the SQL querry that slow largely the request This commit removes the `move` state in the querry and replace it by the the move line state to speed it up. Thanks to 39b65ef and 23e77b8, it's will give the same result as the
Original PR description
Validating a move line will remove the reservation on other move line that will take quantity on the same quant. The querry searching for those move lines needs the state of their relative stock move to be neither 'done' nor 'cancel'. This constraint add a join in the SQL querry that slow largely the request This commit removes the `move` state in the querry and replace it by the the move line state to speed it up. Thanks to 39b65ef and 23e77b8, it's will give the same result as the move line state is related stored of its relative move. Forward-Port-Of: odoo/odoo#42133
Accountant who change the lock date is not always a pos user, and then cannot read pos sessions, which prevent him to change the lock date. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#41994
Original PR description
Accountant who change the lock date is not always a pos user, and then cannot read pos sessions, which prevent him to change the lock date. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#41994
Commit 2106dd3cd10da44cd0b25897aaa5104f93aea703 changed the model of account.move.reversal but didn't change the demo data of l10n_ar Second commit fixes a missing field in `view_account_journal_form` -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#42159
Original PR description
Commit 2106dd3cd10da44cd0b25897aaa5104f93aea703 changed the model of account.move.reversal but didn't change the demo data of l10n_ar Second commit fixes a missing field in `view_account_journal_form` -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#42159
Not having a tax group, we can have a side effect. It hasn't failed before because the field is required only on screen, but not on DB. Forward-port of #39780 as the bot seems to not work. @Tecnativa Forward-Port-Of: odoo/odoo#42052 Forward-Port-Of: odoo/odoo#42046
Original PR description
Not having a tax group, we can have a side effect. It hasn't failed before because the field is required only on screen, but not on DB. Forward-port of #39780 as the bot seems to not work. @Tecnativa Forward-Port-Of: odoo/odoo#42052 Forward-Port-Of: odoo/odoo#42046
If an operator executes the /lead commands, the visitor was not linked to the visitor. This commit fixed that. The visitor is now linked to the lead but the visitor does not take the lead's name. (As '/lead something' creates a lead with 'something' as name. 'Something is not the contact name) This PR also includes somes fixes : - Add acls to salesmen to see visitors and page views : The security file was not loaded in the manifest. Also, the tracking model name has changed to website_t
Original PR description
If an operator executes the /lead commands, the visitor was not linked to the visitor. This commit fixed that. The visitor is now linked to the lead but the visitor does not take the lead's name. (As '/lead something' creates a lead with 'something' as name. 'Something is not the contact name) This PR also includes somes fixes : - Add acls to salesmen to see visitors and page views : The security file was not loaded in the manifest. Also, the tracking model name has changed to website_track. - Allow only livechat users to see lead livechat sessions Done in v13 and not in master as this functionality is needed to make crm visitor integration work properly. Task ID: 2081534 Forward-Port-Of: odoo/odoo#38706
Company used to get defaults was user.company_id and not current company in the environment. Fixes #41679 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#41791
Original PR description
Company used to get defaults was user.company_id and not current company in the environment. Fixes #41679 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#41791
If a visitor has access to a task through access_token, he should have access to the task attachments. He already see the list of attachment and their name, but since the task access_token is not propagated to the attachment he doesn't have the rights to see them. In this PR, we generate the attachments access_token and provide them to the user that is viewing a task with an access_token. opw-2125252 Forward-Port-Of: odoo/odoo#41881
Original PR description
If a visitor has access to a task through access_token, he should have access to the task attachments. He already see the list of attachment and their name, but since the task access_token is not propagated to the attachment he doesn't have the rights to see them. In this PR, we generate the attachments access_token and provide them to the user that is viewing a task with an access_token. opw-2125252 Forward-Port-Of: odoo/odoo#41881
Issue - Download the customer db: stargue-inc - Go on the website in mobile mode Traceback & the second item in the carousel is not displayed. Cause Traceback: we use `this.$iframe` without checking if it's defined Second item not displayed: the first video promise is overriden by the second video promise. Solution Check if this.$iframe is defined and resolve the old promise instead of overriding it. OPW-2152690 -- I confirm I have sig
Original PR description
Issue
- Download the customer db: stargue-inc
- Go on the website in mobile mode
Traceback & the second item in the carousel is not displayed.
Cause
Traceback: we use `this.$iframe` without checking if it's defined
Second item not displayed: the first video promise is overriden
by the second video promise.
Solution
Check if this.$iframe is defined and resolve the old promise
instead of overriding it.
OPW-2152690
--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#42098