Tuesday, October 26, 2021
33 changes · master
Enhancements to existing features
The employee timesheet cost field has been renamed to “Cost” to make the label clearer and easier to understand. The cost field is also now included in the application group, improving consistency in how employee cost information is presented.
Original PR description
- Renamed title by 'Cost' of Time sheet Cost field in employee. - added Cost to Application group task- 2531442
Resource calendars now more reliably identify the end of a work shift when schedule searches span multiple days, such as in monthly or yearly Gantt views. This helps avoid missing valid working time for employees who only work on one of the searched days.
Original PR description
Assign a search_range for calendar_end in the _adjust_to_calendar method in all conditions. The search_range was only assigned a value if the start and end are on the same date before. The _adjust_to_calendar method receives a start and end from midnight to midnight in the resource timezone. Start and end datetimes can be set on a different day via the Gantt view set in month or year for example. This commit ensures that a search_range is always assigned to find the calendar_end and not only when start and end are on the same day. This allows to find the end of a shift searched over two days if the employee is only working one day. task-2628876 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Time off entries that apply to multiple employees now display the employees directly in the list view using their avatars. This makes it easier for managers and HR users to quickly see who is included without opening each request.
Original PR description
A time off for multiple employees was not showing who the employees were in the list view. Now it shows the avatar of all employees in the list view. TaskID: 2674062 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 tax field “Base Affected by Previous Taxes” is now only shown when debug mode is enabled. This keeps the regular tax configuration screen simpler for everyday users while preserving access for advanced troubleshooting or configuration needs.
Original PR description
Make tax field "Base Affected by Previous Taxes" only visible in debug mode. Task: 2608764
The edit payslip lines window now keeps horizontal and vertical scrolling together in one place. This makes it easier for payroll users to review and edit large payslips, especially on wide screens where the previous scrollbars could be awkward to use.
Original PR description
The scrollbar in the edit payslip lines wizard could be quite unusable in some cases. On large displays, if the payslip lines takes too much space both vertically and horizontally, both scrollbars would be separated from eachother. This commit makes it so that both scrollbars are on the same element in the view. TaskId-2659268
Miscellaneous changes
Fixes https://github.com/odoo/odoo/pull/78833 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#78902
Original PR description
Fixes https://github.com/odoo/odoo/pull/78833 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#78902
In the new version of Odoo and in the drivers we "map" the actions. The "mapped" functions must take at least 2 variables as parameters; Self and Data 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#78884
Original PR description
In the new version of Odoo and in the drivers we "map" the actions. The "mapped" functions must take at least 2 variables as parameters; Self and Data 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#78884
Steps to reproduce: ============== 1) Go to Project app and create a project A if you don't have any project. 2) Go to Project > Configuration > Settings. 3) Enable the "Project Stages" feature. 4) Go to Project > Configuration > Project Stages. 5) Show the Email template field in the list view and set a template on a stage. (create a stage before this step if none exists) 6) Go to the main view of Project App. 7) Move Project A to the stage with the template set. Expected Behavior:
Original PR description
Steps to reproduce: ============== 1) Go to Project app and create a project A if you don't have any project. 2) Go to Project > Configuration > Settings. 3) Enable the "Project Stages" feature. 4) Go to Project > Configuration > Project Stages. 5) Show the Email template field in the list view and set a template on a stage. (create a stage before this step if none exists) 6) Go to the main view of Project App. 7) Move Project A to the stage with the template set. Expected Behavior: ============== The system should use the template for the mail tracking. Current Behavior: ============ Traceback because the method `xmlid_to_res_id` does not exist in `ir.model.data`. Task-2677199 Forward-Port-Of: odoo/odoo#78920
ISSUE: The width of menu items is computed (in 'initAutoMoreMenu') to check for overflow and fold extra items in a "+" dropdown. [1] When the page is not in cache yet, the width is computed while font is not loaded yet and the value obtained is not the same when font is already available [2] (e.g. if we go to another page). This explains why we get an additional folded item comparing [1] and [2]. The goal of this PR is to fix this behaviour by waiting for font loading before th
Original PR description
ISSUE: The width of menu items is computed (in 'initAutoMoreMenu') to check for overflow and fold extra items in a "+" dropdown. [1] When the page is not in cache yet, the width is computed while font is not loaded yet and the value obtained is not the same when font is already available [2] (e.g. if we go to another page). This explains why we get an additional folded item comparing [1] and [2]. The goal of this PR is to fix this behaviour by waiting for font loading before the update. task-2618929 Forward-Port-Of: odoo/odoo#78347
Seems like depending the pillow version, the output image size could differ from one or two bytes. Now we check the expected size with a tolerance of +/- 1 byte. 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#78935
Original PR description
Seems like depending the pillow version, the output image size could differ from one or two bytes. Now we check the expected size with a tolerance of +/- 1 byte. 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#78935
I- mediaDialog/linkDialog: 1- Website editor > Add image/link using "/" commands. 2- The mediaDliaog/linkDialog will be shown to select item. 3- Click on "Add/Save" without selecting any image/setting any link. 4- traceback. II- mediaDialog (Video): The same flow for videos will add an empty <iframe> (with no src specified) to the DOM. The goal of this PR is to prevent this behaviour by adding a test on values passed to the 'save' event listeners. task-2628964 Forward-P
Original PR description
I- mediaDialog/linkDialog: 1- Website editor > Add image/link using "/" commands. 2- The mediaDliaog/linkDialog will be shown to select item. 3- Click on "Add/Save" without selecting any image/setting any link. 4- traceback. II- mediaDialog (Video): The same flow for videos will add an empty <iframe> (with no src specified) to the DOM. The goal of this PR is to prevent this behaviour by adding a test on values passed to the 'save' event listeners. task-2628964 Forward-Port-Of: odoo/odoo#76173
Mod 303's grid 61 is now divided in 4 new lines: 120, 122, 123 and 124. Grid 61 isn't used anymore. This takes effect starting July 1st 2021; previous periods are unaffected. Doc: https://www.agenciatributaria.es/AEAT.internet/Inicio/Ayuda/Disenos_de_registro/Modelos_300_al_399/Modelos_300_al_399.shtml https://iranon.es/modelo-303-cambios-a-partir-del-3t-y-mensual-de-julio-de-2021/ OPW 2662476 Forward-Port-Of: odoo/odoo#78651
Original PR description
Mod 303's grid 61 is now divided in 4 new lines: 120, 122, 123 and 124. Grid 61 isn't used anymore. This takes effect starting July 1st 2021; previous periods are unaffected. Doc: https://www.agenciatributaria.es/AEAT.internet/Inicio/Ayuda/Disenos_de_registro/Modelos_300_al_399/Modelos_300_al_399.shtml https://iranon.es/modelo-303-cambios-a-partir-del-3t-y-mensual-de-julio-de-2021/ OPW 2662476 Forward-Port-Of: odoo/odoo#78651
Description of the issue/feature this PR addresses: Typo 14% vs 24% Current behavior before PR: 14% percentage but it should be 24% Desired behavior after PR is merged: 24% instead of 14% -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#78846
Original PR description
Description of the issue/feature this PR addresses: Typo 14% vs 24% Current behavior before PR: 14% percentage but it should be 24% Desired behavior after PR is merged: 24% instead of 14% -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#78846
In activity view, the deadline date that has no timezone is formatted from UTC to local timezone, so if the timezone is negative, we display by error the previous day (eg. 24 october instead of 25 october). With this commmit, we interpret the date in local timezone so there is no timezone issue. note: no test added since this only happen on browser with negative timezone which would be hard to test. note: this was fixed similarily in 13.0 with 0735547086 but must have been lost in a refactori
Original PR description
In activity view, the deadline date that has no timezone is formatted from UTC to local timezone, so if the timezone is negative, we display by error the previous day (eg. 24 october instead of 25 october). With this commmit, we interpret the date in local timezone so there is no timezone issue. note: no test added since this only happen on browser with negative timezone which would be hard to test. note: this was fixed similarily in 13.0 with 0735547086 but must have been lost in a refactoring. opw-2629681 Forward-Port-Of: odoo/odoo#78717 Forward-Port-Of: odoo/odoo#78681
Purpose ======= Fix guest users receiving confirmation emails for events by "Public User" in 13.0. Specifications ============== Change confirmation message for events so that it's sent by Odoo Bot if the user is Guest else by the user itself or the Odoo bot. Center confirmation text after sending track idea. Task-2657588 Forward-Port-Of: odoo/odoo#78903 Forward-Port-Of: odoo/odoo#77477
Original PR description
Purpose ======= Fix guest users receiving confirmation emails for events by "Public User" in 13.0. Specifications ============== Change confirmation message for events so that it's sent by Odoo Bot if the user is Guest else by the user itself or the Odoo bot. Center confirmation text after sending track idea. Task-2657588 Forward-Port-Of: odoo/odoo#78903 Forward-Port-Of: odoo/odoo#77477
### Issue: - Our functionality for merging PDFs from multiple vendor bills relies on PyPDF2. It is well-known that PyPDF2 is sometimes unable to manipulate even perfectly normal PDFs. To provide a helpful error message to the user when this happens (i.e. give them the names of the vendor bills corresponding to the offending pdfs), the `_get_unreadeable_pdfs()` function is called right before we try to merge the PDFs in `_merge_pdfs`. This function is meant to identify the offending PDFs and pro
Original PR description
### Issue: - Our functionality for merging PDFs from multiple vendor bills relies on PyPDF2. It is well-known that PyPDF2 is sometimes unable to manipulate even perfectly normal PDFs. To provide a…
### Issue: - Our functionality for merging PDFs from multiple vendor bills relies on PyPDF2. It is well-known that PyPDF2 is sometimes unable to manipulate even perfectly normal PDFs. To provide a helpful error message to the user when this happens (i.e. give them the names of the vendor bills corresponding to the offending pdfs), the `_get_unreadeable_pdfs()` function is called right before we try to merge the PDFs in `_merge_pdfs`. This function is meant to identify the offending PDFs and provide them to the user. - However, _get_unreadable_pdfs did not notice the problem with 3 of my customer's pdfs, because the error was only triggered once the PdfFileWriter.write function was called in _merge_pdfs. This function, however, is not called in _get_unreadable_pdfs, therefore, it did not notice that anything was wrong. ### Fix: - Change _get_unreadable_pdfs so that it also makes a call to PdfFileWriter.write - As soon as PdfFileWriter.write fails once, it will continue failing when we append more PDF streams to the PdfFileWriter. I therefore suggest initialising a different PdfFileWriter at each iteration of the for loop in order for an offending PDF to not cause a false positive on subsequent PDFs. Forward-Port-Of: odoo/odoo#78905
*: account_sale_timesheet, project_hr_expense, project_mrp, project_purchase, sale_project_account This commit fixes issue regarding fields in project form stat buttons. Those fields are evaluated in any cases, and should rather be computed only when the user has the right group. Steps to reproduce : 1) Install project with one of this bridge 2) Connect with a user with only the group_project_admin right 3) Go to the form view 4) Issue: An internal user with the grou
Original PR description
*: account_sale_timesheet, project_hr_expense, project_mrp, project_purchase, sale_project_account This commit fixes issue regarding fields in project form stat buttons. Those fields are evaluated in any cases, and should rather be computed only when the user has the right group. Steps to reproduce : 1) Install project with one of this bridge 2) Connect with a user with only the group_project_admin right 3) Go to the form view 4) Issue: An internal user with the group "Project Administrator" is unable to access the form view of a project because of missing rights on the X model. Desired Behavior ================ The stat button should not be shown and the field not computed. opw-2675514 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#78929
It may happen that there is a property defined on some field that is not the default property, but rather the property associated to a record. For example ``` => select id,name,company_id,fields_id,value_reference,res_id from ir_property where name like '%property_stock_inventory%' +------+--------------------------+--------------+-------------+-------------------+----------------------+ | id | name | company_id | fields_id | value_reference | res_id
Original PR description
It may happen that there is a property defined on some field that is not the default property, but rather the property associated to a record. For example ``` => select…
It may happen that there is a property defined on some field that is not the default property, but rather the property associated to a record. For example ``` => select id,name,company_id,fields_id,value_reference,res_id from ir_property where name like '%property_stock_inventory%' +------+--------------------------+--------------+-------------+-------------------+----------------------+ | id | name | company_id | fields_id | value_reference | res_id | |------+--------------------------+--------------+-------------+-------------------+----------------------| | 528 | property_stock_inventory | 1 | 4665 | <null> | product.template,752 | | 6 | property_stock_inventory | <null> | 4665 | stock.location,5 | <null> | +------+--------------------------+--------------+-------------+-------------------+----------------------+ ``` In this case the property with id=528 is not a default property since res_id is not NULL. Alternatively the property id=6 is a default one. The issue here is that when searching for the missing locations we do not filter out the properties with res_id not NULL, thus we may get that a company has the location define while in fact it doesn't. Following the example above, this means that we incorrectly get property id=528 as the one defining the location for the company id=1 here: https://github.com/odoo/odoo/blob/c5c47da2e96fd5e37030c70d6bb1bae4c4047fa8/addons/stock/models/res_company.py#L107 This not only prevents the creation of the correct default property but also the default locations https://github.com/odoo/odoo/blob/c5c47da2e96fd5e37030c70d6bb1bae4c4047fa8/addons/stock/models/res_company.py#L36-L51 On this patch we fix the domain search for default property. This allows for the correct creation of the default locations and associated properties. This issue was observed during upgrade 40921, where it prevents the upgrade to 15.0 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#78949 Forward-Port-Of: odoo/odoo#78835
…rency Selection of multiple companies to view multi-company data was added in v13, but at the time there was no way to have reports correctly take into account currency rates when also working with multi-currency. v14 onwards is able to correctly apply the currency rates, therefore we fix the purchase report to do so. Steps to reproduce: 1. Start with existing demo data + add a new company with currency = EUR 2. Activate multi-currencies + set a currency rate (not 1) for Euro to $
Original PR description
…rency Selection of multiple companies to view multi-company data was added in v13, but at the time there was no way to have reports correctly take into account currency rates when also working with…
…rency Selection of multiple companies to view multi-company data was added in v13, but at the time there was no way to have reports correctly take into account currency rates when also working with multi-currency. v14 onwards is able to correctly apply the currency rates, therefore we fix the purchase report to do so. Steps to reproduce: 1. Start with existing demo data + add a new company with currency = EUR 2. Activate multi-currencies + set a currency rate (not 1) for Euro to $ 3. Open Purchase Report (Purchase > Reporting > Dashboard) 4. Activate demo company + new EUR company 5. Switch between USD and EUR company as selected company Expected result: Dashboard monetary quantities switch between $ and EUR, i.e. both the amount changes according to current exchange rate and symbol. Actual result: Currency symbol changes, but amount stays the same. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#75651
PURPOSE readonly attribute does not work on toggle_button widget. SPEC make toggle_button readonly if it has readonly attribute or readonly modifiers, it should not be clickable if it has readonly modifiers. TASK 2339995 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#78798 Forward-Port-Of: odoo/odoo#76426
Original PR description
PURPOSE readonly attribute does not work on toggle_button widget. SPEC make toggle_button readonly if it has readonly attribute or readonly modifiers, it should not be clickable if it has readonly modifiers. TASK 2339995 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#78798 Forward-Port-Of: odoo/odoo#76426
A related field copies the attributes from its target field, except for the attributes defined on the related field itself. The implementation of this feature was not working properly for attributes with a truthy default value. Forward-Port-Of: odoo/odoo#78996 Forward-Port-Of: odoo/odoo#78687
Original PR description
A related field copies the attributes from its target field, except for the attributes defined on the related field itself. The implementation of this feature was not working properly for attributes with a truthy default value. Forward-Port-Of: odoo/odoo#78996 Forward-Port-Of: odoo/odoo#78687
This PR adds python tests for the task dependencies. task-2663173 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#77979
Original PR description
This PR adds python tests for the task dependencies. task-2663173 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#77979
Description of the issue/feature this PR addresses: This fix adresses an issue when editing the control panel from Owl based views. Current behavior before PR: Currently, if you don't have a custom view set, the template editor will appear blank as the component misses its searchViewId value from its props. Desired behavior after PR is merged: The searchViewId is available from the props.info of the view component as expected. Then you can edit the search template and get the default t
Original PR description
Description of the issue/feature this PR addresses: This fix adresses an issue when editing the control panel from Owl based views. Current behavior before PR: Currently, if you don't have a custom view set, the template editor will appear blank as the component misses its searchViewId value from its props. Desired behavior after PR is merged: The searchViewId is available from the props.info of the view component as expected. Then you can edit the search template and get the default template -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#78941
"Material Availability" vs "Component Availability" label means the same think but it shoudn't. Renamme these and add a help string for both fields. Also change decoration to be green if the MO Readiness is 'ready' task-2668922 Forward-Port-Of: odoo/odoo#78391
Original PR description
"Material Availability" vs "Component Availability" label means the same think but it shoudn't. Renamme these and add a help string for both fields. Also change decoration to be green if the MO Readiness is 'ready' task-2668922 Forward-Port-Of: odoo/odoo#78391
The number that was there before was a TFN, not an ABN because of confusion between those two tax numbers. See https://github.com/arthurdejong/python-stdnum/commit/cc3a970e893ebe6635982bcd49c48e6549cb5ac3 https://github.com/odoo/odoo/commit/a72f7222c9f5987a20461be9c837e3de73801ff7 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#78894
Original PR description
The number that was there before was a TFN, not an ABN because of confusion between those two tax numbers. See https://github.com/arthurdejong/python-stdnum/commit/cc3a970e893ebe6635982bcd49c48e6549cb5ac3 https://github.com/odoo/odoo/commit/a72f7222c9f5987a20461be9c837e3de73801ff7 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#78894
Steps: - Login as the admin. - Create a field service task and assign it to the Demo user. - Login as Demo. - Go to the created task and start the timer. - Login as the admin and mark the task as done. - Login as the demo and go to the task. Result: > The timer is still running and there is no way to stop it. Solution: Display timer buttons if timer is still running even if task is closed. opw-2558598 Forward-Port-Of: odoo/enterprise#21862 Forward-Port-Of: odoo/enterprise#203
Original PR description
Steps: - Login as the admin. - Create a field service task and assign it to the Demo user. - Login as Demo. - Go to the created task and start the timer. - Login as the admin and mark the task as done. - Login as the demo and go to the task. Result: > The timer is still running and there is no way to stop it. Solution: Display timer buttons if timer is still running even if task is closed. opw-2558598 Forward-Port-Of: odoo/enterprise#21862 Forward-Port-Of: odoo/enterprise#20327
… bug Currently, there is a bug that occurs when trying to unfold lines in the report. They just disappear. There is also an indentation issue that makes the report unclear. If there is more than one account linked to a DNA category, and there are moves that have a vehicle_id on one account, and moves on the other account without vehicle_id, then it will appear at the bottom of the report, below a vehicle, making it look like it belongs to the vehicle, when it does not. And finall
Original PR description
… bug Currently, there is a bug that occurs when trying to unfold lines in the report. They just disappear. There is also an indentation issue that makes the report unclear. If there is more than one account linked to a DNA category, and there are moves that have a vehicle_id on one account, and moves on the other account without vehicle_id, then it will appear at the bottom of the report, below a vehicle, making it look like it belongs to the vehicle, when it does not. And finally, when creating disallowed expenses categories, it is possible to create and edit a new company. That behavior is not intended there. Forward-Port-Of: odoo/enterprise#21839
This PR adds the task dependencies tests that could not be written prior to the freeze. It also adresses: - A missing depends on _compute_display_warning_dependency_in_gantt. - A dependency problem with timesheet_uom service - Potentials async issues in gantt_connector_[renderer, controller] - Usage of owl throttle instead of the one from underscore (as requested by the JS team) task-2663173 Related PR: odoo/odoo#77979 Forward-Port-Of: odoo/enterprise#21512
Original PR description
This PR adds the task dependencies tests that could not be written prior to the freeze. It also adresses: - A missing depends on _compute_display_warning_dependency_in_gantt. - A dependency problem with timesheet_uom service - Potentials async issues in gantt_connector_[renderer, controller] - Usage of owl throttle instead of the one from underscore (as requested by the JS team) task-2663173 Related PR: odoo/odoo#77979 Forward-Port-Of: odoo/enterprise#21512
Steps : - Create a new POS and activate option Loyalty program. - Go to POS loyalty programs and create a new one. - Create a rule and/or a reward with a new product. - Delete the program. - Try to archive the product. Issue : Deleting loyalty programs does not delete loyalty rules not loyalty rewards. As a consequence, we get an error message when we then try to archive a product. Solution : > Add option "ondelete='cascade'" on both rules and rewards to delete them when
Original PR description
Steps : - Create a new POS and activate option Loyalty program. - Go to POS loyalty programs and create a new one. - Create a rule and/or a reward with a new product. - Delete the program. - Try to archive the product. Issue : Deleting loyalty programs does not delete loyalty rules not loyalty rewards. As a consequence, we get an error message when we then try to archive a product. Solution : > Add option "ondelete='cascade'" on both rules and rewards to delete them when deleting program opw-2662333 Forward-Port-Of: odoo/enterprise#21875 Forward-Port-Of: odoo/enterprise#21828
Issue ----- Since https://github.com/odoo/enterprise/commit/9f98add631d17c760c40165d019dcc80229522d4 slots that last lest than 1/2 hour, generate more slots than they should because the stop condition take into account only the hour of the start 14:00 < stop (14:30) ok then 14:30 => 14:00 still < stop (14:30) generate too much slots Solution -------- Take minutes into account for the stop condition 14:00 < 14:30 ok 14:30 not < 14:30 no more slot generate Forward-Port-Of: odoo
Original PR description
Issue ----- Since https://github.com/odoo/enterprise/commit/9f98add631d17c760c40165d019dcc80229522d4 slots that last lest than 1/2 hour, generate more slots than they should because the stop condition take into account only the hour of the start 14:00 < stop (14:30) ok then 14:30 => 14:00 still < stop (14:30) generate too much slots Solution -------- Take minutes into account for the stop condition 14:00 < 14:30 ok 14:30 not < 14:30 no more slot generate Forward-Port-Of: odoo/enterprise#21550 Forward-Port-Of: odoo/enterprise#20887
*: project_account_asset, project_hr_payroll_account, project_sale_subscription This commit fixes issue regarding fields in project form stat buttons. Those fields are evaluated in any cases, and should rather be computed only when the user has the right group. Steps to reproduce : 1) Install project with one of this bridge 2) Connect with a user with only the group_project_admin right 3) Go to the form view 4) Issue: An internal user with the group "Project Administrator" i
Original PR description
*: project_account_asset, project_hr_payroll_account, project_sale_subscription This commit fixes issue regarding fields in project form stat buttons. Those fields are evaluated in any cases, and should rather be computed only when the user has the right group. Steps to reproduce : 1) Install project with one of this bridge 2) Connect with a user with only the group_project_admin right 3) Go to the form view 4) Issue: An internal user with the group "Project Administrator" is unable to access the form view of a project because of missing rights on the X model. Desired Behavior ================ The stat button should not be shown and the field not computed. opw-2675514 Forward-Port-Of: odoo/enterprise#21870
Currently, when we sign the advantage sign request it will generate a traceback due to an invalid argument in the method. so in this commit, fix the type in argument name so the correct argument will be passed. Task-2642963 Forward-Port-Of: odoo/enterprise#21813
Original PR description
Currently, when we sign the advantage sign request it will generate a traceback due to an invalid argument in the method. so in this commit, fix the type in argument name so the correct argument will be passed. Task-2642963 Forward-Port-Of: odoo/enterprise#21813
Mod 303's grid 61 is now divided in 4 new lines: 120, 122, 123 and 124. Grid 61 isn't used anymore. This takes effect starting July 1st 2021; previous periods are unaffected. Doc: https://www.agenciatributaria.es/AEAT.internet/Inicio/Ayuda/Disenos_de_registro/Modelos_300_al_399/Modelos_300_al_399.shtml https://iranon.es/modelo-303-cambios-a-partir-del-3t-y-mensual-de-julio-de-2021/ OPW 2662476 Forward-Port-Of: odoo/enterprise#21790
Original PR description
Mod 303's grid 61 is now divided in 4 new lines: 120, 122, 123 and 124. Grid 61 isn't used anymore. This takes effect starting July 1st 2021; previous periods are unaffected. Doc: https://www.agenciatributaria.es/AEAT.internet/Inicio/Ayuda/Disenos_de_registro/Modelos_300_al_399/Modelos_300_al_399.shtml https://iranon.es/modelo-303-cambios-a-partir-del-3t-y-mensual-de-julio-de-2021/ OPW 2662476 Forward-Port-Of: odoo/enterprise#21790