Thursday, September 17, 2020
28 changes · master
Enhancements to existing features
When users add another condition to a custom search filter, the new row now starts with the same field and operator as the condition they just used. This saves time and reduces repetitive selections when building multi-condition filters.
Original PR description
Taskid: 2222545 Description of the issue/feature this PR addresses: Searchview custom filters: presetting the dropdowns used in the previous condition is a better for what a user tries to filter than always starting the dropdowns at the top of their lists. Current behavior before PR: When one constucts a custom filter in the search view and clicks on the "ADD A CONDITION" button, the new condition dropdowns always start with the top of the lists. Desired behavior after PR is merged: This PR will instead default a new condition to the same field and operator as the previous one. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Miscellaneous changes
Remove file that was removed from assets file in commit https://github.com/odoo/odoo/pull/52585/commits/d6a23144d5c5b85c2a02097bcbb3e006a9c2c52a taskID: 2327552 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#57832 Forward-Port-Of: odoo/odoo#56721
Original PR description
Remove file that was removed from assets file in commit https://github.com/odoo/odoo/pull/52585/commits/d6a23144d5c5b85c2a02097bcbb3e006a9c2c52a taskID: 2327552 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#57832 Forward-Port-Of: odoo/odoo#56721
Meeting_room_allow_creation field is declared in website_event_meet. event.event.view.form.inherit.track.quiz uses this field in module website_event_track_quiz. This module depends from website_event_track but not from website_event_meet. This commit fix this issue and add the field in the appropriate module. Task ID: 2339901 Forward-Port-Of: odoo/odoo#57750
Original PR description
Meeting_room_allow_creation field is declared in website_event_meet. event.event.view.form.inherit.track.quiz uses this field in module website_event_track_quiz. This module depends from website_event_track but not from website_event_meet. This commit fix this issue and add the field in the appropriate module. Task ID: 2339901 Forward-Port-Of: odoo/odoo#57750
Description of the issue/feature this PR addresses: The original feature was introduced in 8248f0e153a and works fine for internal transfers, but fails for dropship. In case of dropship, if quantity is changed on confirmed PO line, new picking is created, even if the quantity was decreased, leaving the new draft picking empty. Current behavior before PR: New picking is created each time quantity is changed on confirmed PO line. This is true even for quantity decrease, which creates new
Original PR description
Description of the issue/feature this PR addresses: The original feature was introduced in 8248f0e153a and works fine for internal transfers, but fails for dropship. In case of dropship, if quantity is changed on confirmed PO line, new picking is created, even if the quantity was decreased, leaving the new draft picking empty. Current behavior before PR: New picking is created each time quantity is changed on confirmed PO line. This is true even for quantity decrease, which creates new empty picking. Desired behavior after PR is merged: Existing picking is updated. Same as for internal transfers. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#57113
Before this commit it was not possible to remove a channel from the followers. task-2324263 Forward-Port-Of: odoo/odoo#57756
Original PR description
Before this commit it was not possible to remove a channel from the followers. task-2324263 Forward-Port-Of: odoo/odoo#57756
Since 9f82605df111, any call to `_login_redirect()` without previously going through `web_login()` method would crash, as `login_success` is set there. In this case, it was: Dispatch -> web_login -> redirect (new dispatch) -> _login_redirect() task-2340941 Forward-Port-Of: odoo/odoo#57839
Original PR description
Since 9f82605df111, any call to `_login_redirect()` without previously going through `web_login()` method would crash, as `login_success` is set there. In this case, it was: Dispatch -> web_login -> redirect (new dispatch) -> _login_redirect() task-2340941 Forward-Port-Of: odoo/odoo#57839
This commit aims at fixing a random bug on the runbot. When loading the webclient, if there is no hash, a rpc is done to read the default action of the user. When this rpc comes back, we execute the given action (if any), or the first action (typically Discuss). The navbar is displayed as soon as possible, it doesn't wait for the first action to be executed. This means that the user can open the user menu and click on 'My Profile' before the first action is executed. Before this comm
Original PR description
This commit aims at fixing a random bug on the runbot. When loading the webclient, if there is no hash, a rpc is done to read the default action of the user. When this rpc comes back, we execute the…
This commit aims at fixing a random bug on the runbot. When loading the webclient, if there is no hash, a rpc is done to read the default action of the user. When this rpc comes back, we execute the given action (if any), or the first action (typically Discuss). The navbar is displayed as soon as possible, it doesn't wait for the first action to be executed. This means that the user can open the user menu and click on 'My Profile' before the first action is executed. Before this commit, if the user clicked before the read rpc on 'res.users' returned, the default action (or the first) one, was executed, even though the user clicked on 'My Profile' and thus asked for a specific action. So basically, the user form view was briefly shown, and then replaced by the default or first action. Whereas this is a very rare usecase in practice (the timing is realling short), this sometimes made the totp tour fail. However, even if it is unlikely, the client must be robust and correctly react to concurrent requests. This commit fixes the issue by executing the 'My Profile' action in the DropPrevious. That way, if any 'doAction' is performed, other pending operations (also done in DropPrevious) are dropped. This commit also ensures that the "brand name" part in the navbar (containing the name of the current app) is hidden when there is no current app, as in the scenario described above, we land in a webclient with no current app. Note that not being in an app was something that was already handled, but not at startup. Forward-Port-Of: odoo/odoo#57840
The attribute Exception.message is no longer available in Python 3, and newer versions of pylint check for this and raise an error during test_lint, with this commit we take care of these codesites in the following manner: * For test_convert, the access was in a function that is effectively dead code, and thus it has been removed. * In modules.py, it is accessed in code that is used *BUT* is within a pycompat.PY2 block, which means it'll only be called if running under py
Original PR description
The attribute Exception.message is no longer available in Python 3, and
newer versions of pylint check for this and raise an error during
test_lint, with this commit we take care of these codesites in the
following manner:
* For test_convert, the access was in a function that is effectively
dead code, and thus it has been removed.
* In modules.py, it is accessed in code that is used *BUT* is within a
pycompat.PY2 block, which means it'll only be called if running
under python 2 which is legal, therefore we just add a comment for
pylint to ignore this specific call
With this, we can upgrade pylint to the newest version and fix a
longstanding bug with MRO building in pylint.
Linked to https://github.com/odoo/enterprise/pull/13219
Forward-Port-Of: odoo/odoo#57882
Forward-Port-Of: odoo/odoo#57697Issue - Install 'hr_timesheet' module - Go to any employee and click on stat button 'Timesheets' - Create timesheet - Remove employee from filter then add it back No timesheets displayed for current employee. Cause There is no "employee_id" in list view. However, 'timesheet_view_tree_user' view (who inherit from concerned list view) does have an "employee_id" field but the mode is "primary" and therefore not available for the main view. Solution Add "employee_id"
Original PR description
Issue - Install 'hr_timesheet' module - Go to any employee and click on stat button 'Timesheets' - Create timesheet - Remove employee from filter then add it back No timesheets displayed for current employee. Cause There is no "employee_id" in list view. However, 'timesheet_view_tree_user' view (who inherit from concerned list view) does have an "employee_id" field but the mode is "primary" and therefore not available for the main view. Solution Add "employee_id" in main list view and alter inherited view to update attributes of "employee_id" field. opw-2338055 Forward-Port-Of: odoo/odoo#57906 Forward-Port-Of: odoo/odoo#57868
Fine-tuning of 9d7d618220e27024321a75be0058db2289115af2 Although the mentioned commit delays the consumption of a sequence number at creation, it has the drawback to not generate one if the user modifies the name. In practice, we still want to generate a RMA number even if there is a custom name. A good balance is to generate the RMA number if the user leaves the `/` at the beginning of the name. If the user removes the `/`, we don't generate the RMA number. opw-2301412 Descript
Original PR description
Fine-tuning of 9d7d618220e27024321a75be0058db2289115af2 Although the mentioned commit delays the consumption of a sequence number at creation, it has the drawback to not generate one if the user modifies the name. In practice, we still want to generate a RMA number even if there is a custom name. A good balance is to generate the RMA number if the user leaves the `/` at the beginning of the name. If the user removes the `/`, we don't generate the RMA number. opw-2301412 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#57608
due to breaking changes in https://github.com/odoo/odoo/pull/55995/commits/bf32b22ce247c19fda94ded74e37f7c6120ce2c4 and especially the part: "NOTE 1. If the default_get within the onchange returns a value for a field that is not in the view, we ignore it, and it won't be saved. Before, that value was kept and sent upon save. This change in behavior may prove problematic, although the overall risk is small. Decision has been made to keep heavy comments and code snippets if we were to r
Original PR description
due to breaking changes in https://github.com/odoo/odoo/pull/55995/commits/bf32b22ce247c19fda94ded74e37f7c6120ce2c4 and especially the part: "NOTE 1. If the default_get within the onchange returns a value for a field that is not in the view, we ignore it, and it won't be saved. Before, that value was kept and sent upon save. This change in behavior may prove problematic, although the overall risk is small. Decision has been made to keep heavy comments and code snippets if we were to revert back somehow to the previous situation." the wizard to update user password was broken as the field user_id which is required was not present in the view and was thus ignored by to web client when calling 'create'. Closes https://github.com/odoo/odoo/issues/57149 Closes https://github.com/odoo/odoo/issues/57926 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#57922
Fix #57780 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#57834
Original PR description
Fix #57780 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#57834
Current behavior before PR: Auto-generated SQL fails with ERROR: missing FROM-clause entry for table when table alias names exceed the target length of 63 characters. This is because odoo.osv.expression.py handles shortening the table name alias in generate_table_alias, but not in get_join_conditions. In the resulting SQL, shortened aliases are used in the FROM clause, whereas in the join conditions, the full alias is used, which is both exceeding the Postgres limit and not matching the table n
Original PR description
Current behavior before PR: Auto-generated SQL fails with ERROR: missing FROM-clause entry for table when table alias names exceed the target length of 63 characters. This is because odoo.osv.expression.py handles shortening the table name alias in generate_table_alias, but not in get_join_conditions. In the resulting SQL, shortened aliases are used in the FROM clause, whereas in the join conditions, the full alias is used, which is both exceeding the Postgres limit and not matching the table name alias in the FROM clause. Desired behavior after PR is merged: auto-generated SQL runs without errors. Description of the issue/feature this PR addresses: - refactor alias shortening into new function _shorten_alias to make it reusable - Use _shorten_alias in both generate_table_alias and get_join_conditions -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#57909 Forward-Port-Of: odoo/odoo#54730
- channel_seen is now called even for own message and only when needed - channel_seen is now called with a message_id which transfer the decision of what is seen to the client which makes more sense task-2282235 task-2282248 Forward-Port-Of: odoo/odoo#54689
Original PR description
- channel_seen is now called even for own message and only when needed - channel_seen is now called with a message_id which transfer the decision of what is seen to the client which makes more sense task-2282235 task-2282248 Forward-Port-Of: odoo/odoo#54689
Steps to reproduce the bug: - Create a customer invoice I for customer C with no payment term and no invoice date - Set a payment term date to a date D in the futur - Validate I Bug: The payment term date was changed to today as the invoice date. opw:2328668 Forward-Port-Of: odoo/odoo#57430 Forward-Port-Of: odoo/odoo#57048
Original PR description
Steps to reproduce the bug: - Create a customer invoice I for customer C with no payment term and no invoice date - Set a payment term date to a date D in the futur - Validate I Bug: The payment term date was changed to today as the invoice date. opw:2328668 Forward-Port-Of: odoo/odoo#57430 Forward-Port-Of: odoo/odoo#57048
Assume field B depends on A, and searching on B is rewritten as a domain that mentions A. If A is modified, and then we search on B, one has to flush A to the database before searching. Forward-Port-Of: odoo/odoo#57936 Forward-Port-Of: odoo/odoo#57861
Original PR description
Assume field B depends on A, and searching on B is rewritten as a domain that mentions A. If A is modified, and then we search on B, one has to flush A to the database before searching. Forward-Port-Of: odoo/odoo#57936 Forward-Port-Of: odoo/odoo#57861
Usecase to reproduce: - Launch 2 procurements for 2 manufactured products. Only the last MO created has finished moves. It happens since the list is wipped at each iteration. Forward-Port-Of: odoo/odoo#57170
Original PR description
Usecase to reproduce: - Launch 2 procurements for 2 manufactured products. Only the last MO created has finished moves. It happens since the list is wipped at each iteration. Forward-Port-Of: odoo/odoo#57170
If IoT Box is on access point mode the box try to reach https://iot-proxy.odoo.com to get pairing code. So the box try while 5 minutes to reach iot-proxy and send request on network every 10 secondes. Now we add a condition `if not access_point()` to send these request. 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
Original PR description
If IoT Box is on access point mode the box try to reach https://iot-proxy.odoo.com to get pairing code. So the box try while 5 minutes to reach iot-proxy and send request on network every 10 secondes. Now we add a condition `if not access_point()` to send these request. 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#57673
With evdev version 1.3.0 we have a lot of Traceback in IoT Box. A RuntimeError in the library with the function 'get_event_loop()' So we roll back to version 1.2.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#57679
Original PR description
With evdev version 1.3.0 we have a lot of Traceback in IoT Box. A RuntimeError in the library with the function 'get_event_loop()' So we roll back to version 1.2.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#57679
The path to folder of images of IoT has change. So we adapt the path for the upgrade of IoT 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#57935
Original PR description
The path to folder of images of IoT has change. So we adapt the path for the upgrade of IoT 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#57935
Before in a DB with 6000 `mrp.production.shedule`, 6800 product and 3000 bom the loading of the "Master Production Schedule" was very slow: - For 20 `mrp.production.shedule`: 19.63 +- 0.93 sec - For 50 `mrp.production.shedule`: 71.94 +- 0.45 sec To improve performance: - Avoid filtering in a loop, use dict + one loop. - Refactor `_get_indirect_demand_ratio` to be batched (`_get_indirect_demand_ratio_mps`) and tranverse only one time the tree. - Cached at the most of possible results
Original PR description
Before in a DB with 6000 `mrp.production.shedule`, 6800 product and 3000 bom the loading of the "Master Production Schedule" was very slow: - For 20 `mrp.production.shedule`: 19.63 +- 0.93 sec - For…
Before in a DB with 6000 `mrp.production.shedule`, 6800 product and 3000 bom the loading of the "Master Production Schedule" was very slow: - For 20 `mrp.production.shedule`: 19.63 +- 0.93 sec - For 50 `mrp.production.shedule`: 71.94 +- 0.45 sec To improve performance: - Avoid filtering in a loop, use dict + one loop. - Refactor `_get_indirect_demand_ratio` to be batched (`_get_indirect_demand_ratio_mps`) and tranverse only one time the tree. - Cached at the most of possible results of mapped. - Avoid `in` check in list (in a loop) and use set or OrderedDict instead. Also the hidden bom was fixed. Before if a product doesn't have a `mrp.production.schedule` but was in the tree of production of a other product, it wasn't take in account. Fallback to bom_find in this case. (Unfortunately it descreases performance). After this commit, performance is far better but still can be improve: - For 20 `mrp.production.shedule`: 2.8 +- 0.13 sec - For 50 `mrp.production.shedule`: 4.07 +- 0.26 sec opw-2085309 Forward-Port-Of: odoo/enterprise#13285
Missing part of 3f17637b806a9997bf883905c346977735cb12f5 COM PR odoo/odoo#57834 Forward-Port-Of: odoo/enterprise#13315
Original PR description
Missing part of 3f17637b806a9997bf883905c346977735cb12f5 COM PR odoo/odoo#57834 Forward-Port-Of: odoo/enterprise#13315
task-2333127 Forward-Port-Of: odoo/enterprise#13026
Original PR description
task-2333127 Forward-Port-Of: odoo/enterprise#13026
This commit is the counterpart of odoo/odoo#57840. It ensures that the "brand name" part in the navbar (containing the name of the current app) is hidden when there is no current app at startup. Forward-Port-Of: odoo/enterprise#13277
Original PR description
This commit is the counterpart of odoo/odoo#57840. It ensures that the "brand name" part in the navbar (containing the name of the current app) is hidden when there is no current app at startup. Forward-Port-Of: odoo/enterprise#13277
Before this commit, the cache could not been refreshed by the user. With this commit, the user can refresh the cache from the pivot side panel. Task-id 2330179 Forward-Port-Of: odoo/enterprise#13261
Original PR description
Before this commit, the cache could not been refreshed by the user. With this commit, the user can refresh the cache from the pivot side panel. Task-id 2330179 Forward-Port-Of: odoo/enterprise#13261
In case fetching tweets fails with an error code different from 88 or 195, we don't raise any error. Consequently, `result.json()` crashes since `result` is a `dict`. We return the error message from Twitter instead of crashing. opw-2337789 Forward-Port-Of: odoo/enterprise#13282
Original PR description
In case fetching tweets fails with an error code different from 88 or 195, we don't raise any error. Consequently, `result.json()` crashes since `result` is a `dict`. We return the error message from Twitter instead of crashing. opw-2337789 Forward-Port-Of: odoo/enterprise#13282
Timer widget must not be included in all timesheet time widget. taskID 2327552 Forward-Port-Of: odoo/enterprise#13271 Forward-Port-Of: odoo/enterprise#12749
Original PR description
Timer widget must not be included in all timesheet time widget. taskID 2327552 Forward-Port-Of: odoo/enterprise#13271 Forward-Port-Of: odoo/enterprise#12749
Creating a chart currently crashes since the lib is not loaded. Forward-Port-Of: odoo/enterprise#13306 Forward-Port-Of: odoo/enterprise#13293
Original PR description
Creating a chart currently crashes since the lib is not loaded. Forward-Port-Of: odoo/enterprise#13306 Forward-Port-Of: odoo/enterprise#13293