Sunday, August 6, 2023
5 changes · master
Miscellaneous changes
Since #121376 a clear_cache was removed when unlinking an attachment This clear_cache was not useful when restarting a server with new sources, an other operation changing the content of an assets should invalidate the cache manually. This is the case of ir.asset CUD operations. Unfortunately, a manual update was left missing in website, when archiving ir.assets used for snippets. This was discovered on runbot, with two workers, when the first workers generates assets before the cron,
Original PR description
Since #121376 a clear_cache was removed when unlinking an attachment This clear_cache was not useful when restarting a server with new sources, an other operation changing the content of an assets…
Since #121376 a clear_cache was removed when unlinking an attachment This clear_cache was not useful when restarting a server with new sources, an other operation changing the content of an assets should invalidate the cache manually. This is the case of ir.asset CUD operations. Unfortunately, a manual update was left missing in website, when archiving ir.assets used for snippets. This was discovered on runbot, with two workers, when the first workers generates assets before the cron, and the second one after the cron. The second worker unlinks attachments creating an inconsistency in the cache of the first one. This problem can be solved quickly by invalidating the assets cache in the cron manually but this will be done in all cases. The proposed solution will check the ir.asset that should change and only clear the cache if the state changed. The global logic remains the same, ordering assets by id and only checking the first module found for one snippet+version+type. Additional note: Regarding performances, this should actually be a slight improvement in query count since at the cost of one more select to prefetch the record we can avoid multiple update, one per snippet. In most case no update at all should be done, at most 2 can be done (one for archive, one for unarchive). Example with some assets to unarchive: Before: TOTAL ENTRIES: 277 SELECT: 158 (~0.16591858863830566s) UNKWOW: 54 (~0.0202481746673584s) UPDATE: 65 (~0.03202557563781738s) After: TOTAL ENTRIES: 214 SELECT: 159 (~0.1663439826965332s) UNKWOW: 54 (~0.029229164123535156s) UPDATE: 1 (~0.0002865791320800781s) If the number of query is lowered, the python processing is slightly higher. Locally the test time is similar, slightly longer since an additional call to _disable_unused_snippets_assets was added to check the cache invalidation Forward-Port-Of: odoo/odoo#130743
`default_get` is bad m'kay? Reproduce: * Accounting > Configuration > Taxes > Create * Just add a name, save. There are no repartition lines, but there should be at least one line for the base line. This happens because `default_get` was only computing the main field `repartition_line_ids` and it was allowed because the contraint was not checking that same field. Forward-Port-Of: odoo/odoo#129771 Forward-Port-Of: odoo/odoo#121386
Original PR description
`default_get` is bad m'kay? Reproduce: * Accounting > Configuration > Taxes > Create * Just add a name, save. There are no repartition lines, but there should be at least one line for the base line. This happens because `default_get` was only computing the main field `repartition_line_ids` and it was allowed because the contraint was not checking that same field. Forward-Port-Of: odoo/odoo#129771 Forward-Port-Of: odoo/odoo#121386
Miscellaneous improvements: 1. In analytic tags, the percentage is now a prefix. 2. In the widget, 0% accounts are now hidden. 3. In the analytic items list/pivot views, it is now possible to search by: - Financial Account. - Cross by. 4. By default, the pivot view is now grouped by plans and then analytic accounts. 5. An "Analytic Reporting" menuitem that opens the pivot view is added in Reporting > Management. task-3446504 --- I confirm I have signed the CLA and read the PR guide
Original PR description
Miscellaneous improvements: 1. In analytic tags, the percentage is now a prefix. 2. In the widget, 0% accounts are now hidden. 3. In the analytic items list/pivot views, it is now possible to search by: - Financial Account. - Cross by. 4. By default, the pivot view is now grouped by plans and then analytic accounts. 5. An "Analytic Reporting" menuitem that opens the pivot view is added in Reporting > Management. task-3446504 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#130666
Before this commit, when the user starts a timer on a timesheet linked to a project without company set, the timer header will display the following message: "A timer is running in another company.". This message is not correct since the project has no company and so the project is visible for all companies. This commit fixes the issue by checking first if the project's company is set before checking if the company is in the current ones. By doing that, the user can now edit the timesheet dat
Original PR description
Before this commit, when the user starts a timer on a timesheet linked to a project without company set, the timer header will display the following message: "A timer is running in another company.". This message is not correct since the project has no company and so the project is visible for all companies. This commit fixes the issue by checking first if the project's company is set before checking if the company is in the current ones. By doing that, the user can now edit the timesheet data in timesheet timer header component. Forward-Port-Of: odoo/enterprise#45322
Currently, in the project.task Gantt view, the row of the current user is always displayed, even if empty and if a search is performed on the assignees of tasks. This behavior is fixed to hide this row should if a filter is applied on user_ids. Steps ===== - Install project_enterprise - Go in the Gantt view of a project - Search for an assignee in the search bar - The current user row is always visible Issue ===== The current user row is always visible, even if the filter on user_id
Original PR description
Currently, in the project.task Gantt view, the row of the current user is always displayed, even if empty and if a search is performed on the assignees of tasks. This behavior is fixed to hide this row should if a filter is applied on user_ids. Steps ===== - Install project_enterprise - Go in the Gantt view of a project - Search for an assignee in the search bar - The current user row is always visible Issue ===== The current user row is always visible, even if the filter on user_ids does not match the current user. Cause ===== The group expand method on user_ids is designed to always add the current user. Fix === A check is performed on the domain to see if a filter is applied on user_ids. If it's the case, the current user is not automatically added to the resulting group. task-3429600 Forward-Port-Of: odoo/enterprise#45310 Forward-Port-Of: odoo/enterprise#44224