Monday, February 12, 2024
32 changes · saas-17.1
Resolved issues and error corrections
Opening the Restaurant Point of Sale now works even when no floor plan has been configured. This prevents an avoidable startup failure and lets businesses use the restaurant interface without first creating floors.
Original PR description
Before this commit, opening a restaurant without any defined floors would result in a failure. This was due to the use of `activeFloor.background_color` to set the color, while activeFloor was not defined in cases where no floors were present. opw-3729416 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Miscellaneous changes
In b69917e[1] the cron implementation was changed to unlink old visitors in batches of 1000 records. This was meant to deal with memory/timeout errors when dealing with large amounts of records. However it still searches for records with no limit, which in high record count scenarios and based on instance resources may still generate memory/timeout errors. Technically it could be considered "fine" for the cron to timeout since every batch is committed, so previously unlinked records a
Original PR description
In b69917e[1] the cron implementation was changed to unlink old visitors in batches of 1000 records. This was meant to deal with memory/timeout errors when dealing with large amounts of records.…
In b69917e[1] the cron implementation was changed to unlink old visitors in batches of 1000 records. This was meant to deal with memory/timeout errors when dealing with large amounts of records. However it still searches for records with no limit, which in high record count scenarios and based on instance resources may still generate memory/timeout errors. Technically it could be considered "fine" for the cron to timeout since every batch is committed, so previously unlinked records are not rolled back and the cron should eventually delete them all. However there are some edge cases where memory/time out errors would not be fine, like the cron failing during the first batch, which means no unlink operations would be committed to the database. Errors that are "fine" also generate noise and leave administrators wondering which errors they should ignore and which they should not. It also alarms non-technical customers since after all, they are seeing a reported error. Therefore the search limit and batch size have been added as arguments to the cron. This is completely opt-in since they have the previous values as their defaults. This makes it easy to customize and tune the performance of the job accordingly if required. [1] https://github.com/odoo/odoo/commit/b69917ec0e508f8354d831525c5c48ee79b5967a --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#150476
Issue: When purchasing tickets for an event, if the quantity of tickets is reduced directly from the cart, payment can be processed for the reduced number of tickets while the excess registrations remain incorrectly open in the database. Steps to Reproduce: 1 Install Events Online Ticketing. 2 Create or select an event with open registrations. 3 Add 3 registrations to your cart and proceed to checkout. 4 In the payment process, go to 'Review Order' and reduce the quantity of tickets. 5 C
Original PR description
Issue: When purchasing tickets for an event, if the quantity of tickets is reduced directly from the cart, payment can be processed for the reduced number of tickets while the excess registrations…
Issue: When purchasing tickets for an event, if the quantity of tickets is reduced directly from the cart, payment can be processed for the reduced number of tickets while the excess registrations remain incorrectly open in the database. Steps to Reproduce: 1 Install Events Online Ticketing. 2 Create or select an event with open registrations. 3 Add 3 registrations to your cart and proceed to checkout. 4 In the payment process, go to 'Review Order' and reduce the quantity of tickets. 5 Complete the checkout and payment. 6 Upon inspecting the database for the same event, you'll notice an inconsistency: the number of attendees is higher than it should be. Solution: This issue arises from the implementation of `_compute_registration_status`, which only considers the sale order line and marks registrations as cancelled only if the entire order line is cancelled. This means either all 3 registrations are cancelled, or none. The solution introduced here addresses this by checking for registrations already marked as cancelled and incorporating them into the cancellation logic, ensuring accurate tracking of active and cancelled registrations. opw-3653452 Forward-Port-Of: odoo/odoo#150463
### Current behavior: Confirming a Purchase Order with more than 50 lines takes too much time to be processed. In the case of the client, they had PO with more than 200 lines which makes it impossible for them to confirm them. ### Step to reproduce: - Install mrp and mrp_subcontracting - Create PO with more than 50 order lines or more - Try to confirm it - Take a long time or timeout ### Benchmark (made in 16): | No. of PO lines | Before | After | |-----------------|:-------:|:---
Original PR description
### Current behavior: Confirming a Purchase Order with more than 50 lines takes too much time to be processed. In the case of the client, they had PO with more than 200 lines which makes it impossible for them to confirm them. ### Step to reproduce: - Install mrp and mrp_subcontracting - Create PO with more than 50 order lines or more - Try to confirm it - Take a long time or timeout ### Benchmark (made in 16): | No. of PO lines | Before | After | |-----------------|:-------:|:------:| | 9 | 1s30 | 1s30 | | 91 | 1min | 16s | | 273 | 4min | 50s | | 405 | 4min30s | 1min6s | ### Fix: Batch more actions and records to reduce the number of queries generated by the ORM. opw-3625892 Forward-Port-Of: odoo/odoo#149830 Forward-Port-Of: odoo/odoo#146442
Before this commit: When the user creates new stages or groups in Kanban view and adds new tasks with particular states and then if the user clicks on any colour in the progressbar then the filter gets applied on all the groups or stages. Observerd Behaviour: The filter is applied on all the groups or stages.So, if we click on a colour in the progressbar suppose colour Green to filter out Approved task(s) of a particular stage then in that stage or group only the Approved task(s) would be v
Original PR description
Before this commit: When the user creates new stages or groups in Kanban view and adds new tasks with particular states and then if the user clicks on any colour in the progressbar then the filter…
Before this commit: When the user creates new stages or groups in Kanban view and adds new tasks with particular states and then if the user clicks on any colour in the progressbar then the filter gets applied on all the groups or stages. Observerd Behaviour: The filter is applied on all the groups or stages.So, if we click on a colour in the progressbar suppose colour Green to filter out Approved task(s) of a particular stage then in that stage or group only the Approved task(s) would be visible. Also the filter would get applied on all other stages or groups created at that time. In those stages all the task with that state would be visible and rest of them would get blurred. Steps to produce: - Install `Project` and add a new project in it. - In the newly created project add some new stages or groups, each consisting some new tasks. - Give some states to those tasks through project state selector (for eg: Approved, Changes Requested). - Click on any particular colour in the `Progressbar` of any particular group or stage. Expected Behaviour: When the user clicks on any colour in the progressbar then it should filter out only those tasks which are associated with that color/state and only in that particular group or stage. Reason: https://github.com/odoo/odoo/blob/579ee6d9792050955fa80346fd57ad294efcdd62/addons/web/static/src/views/kanban/progress_bar_hook.js#L114 group.serverValue results as Undefined. Because when the data is being prepared here: https://github.com/odoo/odoo/blob/493d5c39982de79e6fb256dd8084bf592a740f77/addons/web/static/src/model/relational_model/dynamic_group_list.js#L222-L231 there is no serverValue provided. So, whenever a group is getting created here serverValue `Undefined` as value. https://github.com/odoo/odoo/blob/493d5c39982de79e6fb256dd8084bf592a740f77/addons/web/static/src/model/relational_model/group.js#L25 Note: - There was a need to change the function name from `getServerValueFromGroupData` to `getGroupServerValue` as now now this function calculates serverValue while the data is being created and not when the data is already created. - The function is exported into another file as this function defines the basis to calculate serverValue and there is a necessity to calculate serverValue while data is being created. Task-3620697 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#149694
When a user is modified to grant access to new groups, user is auto-enrolled to all slide courses that have a auto-enroll policy for any of the new groups. However, that auto-enrolling process was not working correctly due to how values to be written to the user are coming. In order to know what are the actual new groups, values need to be pre-processed, which was not being done. This commit fixes the above issue by pre-processing written values before extracting new groups. --- I co
Original PR description
When a user is modified to grant access to new groups, user is auto-enrolled to all slide courses that have a auto-enroll policy for any of the new groups. However, that auto-enrolling process was not working correctly due to how values to be written to the user are coming. In order to know what are the actual new groups, values need to be pre-processed, which was not being done. This commit fixes the above issue by pre-processing written values before extracting new groups. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#153138
When reading values in reactive objects, Owl's reactivity system will return reactive versions of the sub-objects to allow tracking reads in depth, so that changes to values in deep object hierarchies can still cause components to render themselves if needed. Luxon objects are immutable. Since they cannot change and values inside them cannot change either, tracking reads within luxon objects is pure overhead. This commit makes luxon objects non reactifiable by setting the Symbol.toStringTa
Original PR description
When reading values in reactive objects, Owl's reactivity system will return reactive versions of the sub-objects to allow tracking reads in depth, so that changes to values in deep object hierarchies can still cause components to render themselves if needed. Luxon objects are immutable. Since they cannot change and values inside them cannot change either, tracking reads within luxon objects is pure overhead. This commit makes luxon objects non reactifiable by setting the Symbol.toStringTag property on the luxon classes, which is what Owl uses internally to determine if objects can be made reactive. It will also cause some of these objects to serialize to more specific strings instead of just [object Object], eg [object LuxonZone]. Forward-Port-Of: odoo/odoo#153540 Forward-Port-Of: odoo/odoo#153387
Description of the issue/feature this PR addresses: Current behavior before PR: The original fix was done here https://github.com/odoo/odoo/pull/99856, but when copying multiple attachments it failed For example in the case of a mass.mailing sending 2 attachments, indexes every attachment, taking forever and never finishing. Desired behavior after PR is merged: On copy of multiple attachment, avoid indexing every time --- I confirm I have signed the CLA and read the PR guideline
Original PR description
Description of the issue/feature this PR addresses: Current behavior before PR: The original fix was done here https://github.com/odoo/odoo/pull/99856, but when copying multiple attachments it failed For example in the case of a mass.mailing sending 2 attachments, indexes every attachment, taking forever and never finishing. Desired behavior after PR is merged: On copy of multiple attachment, avoid indexing every time --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#152219
Have a grouped list view s.t. there's a group with enough records to have a pager in the group. Go to the second page of that group. Then, apply a filter such that there's only a single page remaining in the group. Before this commit, no record was displayed, because the previous offset wasn't reset to 0 it should have been. With this commit, the offset is recursively reset, so we correctly display the records of the first page after a reload. Description of the issue/feature this PR addresse
Original PR description
Have a grouped list view s.t. there's a group with enough records to have a pager in the group. Go to the second page of that group. Then, apply a filter such that there's only a single page remaining in the group. Before this commit, no record was displayed, because the previous offset wasn't reset to 0 it should have been. With this commit, the offset is recursively reset, so we correctly display the records of the first page after a reload. 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#153494
Steps to reproduce: - insert a global filter with double quotes in its name (e.g. my "special" filter) - reference that filter with ODOO.FILTER.VALUE (remember you have to escape the " in the formula with a backslash \ =ODOO.FILTER.VALUE("my \"special\" filter") => the filter is not found Task: 3697855 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#153337 Forward-Port-Of: odoo/odoo#150604
Original PR description
Steps to reproduce:
- insert a global filter with double quotes in its name (e.g. my "special" filter)
- reference that filter with ODOO.FILTER.VALUE (remember you have to escape the " in the formula with a backslash \ =ODOO.FILTER.VALUE("my \"special\" filter") => the filter is not found
Task: 3697855
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#153337
Forward-Port-Of: odoo/odoo#150604In this PR, the mobile/phone number is in sync with the partner if the partner is not there then it will be generated based on the applicant information Task-3635976 Forward-Port-Of: odoo/odoo#150820
Original PR description
In this PR, the mobile/phone number is in sync with the partner if the partner is not there then it will be generated based on the applicant information Task-3635976 Forward-Port-Of: odoo/odoo#150820
To reproduce ============ - Go to shop - in edit mode select a product - add a ribbon or modify it - save -> ribbon is not saved Problem ======= When changing the ribbon, there is no editable item that is marked dirty, because the ribbon doesn't have a savable parent. Solution ======== Flag the ribbon as dirty manually to trigger saving process Note ==== the reason why this is needed in 16.0 and not before is [1]. Before that we did not check for the presence of the dirty f
Original PR description
To reproduce ============ - Go to shop - in edit mode select a product - add a ribbon or modify it - save -> ribbon is not saved Problem ======= When changing the ribbon, there is no editable item…
To reproduce ============ - Go to shop - in edit mode select a product - add a ribbon or modify it - save -> ribbon is not saved Problem ======= When changing the ribbon, there is no editable item that is marked dirty, because the ribbon doesn't have a savable parent. Solution ======== Flag the ribbon as dirty manually to trigger saving process Note ==== the reason why this is needed in 16.0 and not before is [1]. Before that we did not check for the presence of the dirty flag (the "o_dirty" class) to determine if the page has to be saved. All of this has to be reviewed in the future, as explained by [2] and its following commits. Note that commits like [2] is probably the cause of ribbon not being savable anymore: parts of the DOM stopped being flagged with o_dirty by mistake... so the saving process was not triggered "by mistake" anymore. At the time of [1] for example: just clicking on a product image (to maybe then add a ribbon) was enough for it to be marked with the "o_dirty" class by mistake. This was probably solved later... creating the bug being solved here. [1]: https://github.com/odoo/odoo/commit/650a97d1bd59254cc2115d54d58940b6112a8d70 [2]: https://github.com/odoo/odoo/commit/e8a86b860dcba5b7782fc26c4290eee48d9fcdee opw-3674520 Forward-Port-Of: odoo/odoo#153298 Forward-Port-Of: odoo/odoo#152694
Adds a test following a fix done in https://github.com/odoo/odoo/pull/143381 That fix ensured that the public leave used to compute leaves intervals for the resources are in the same company as the resource. task-3668605 Forward-Port-Of: odoo/odoo#152827
Original PR description
Adds a test following a fix done in https://github.com/odoo/odoo/pull/143381 That fix ensured that the public leave used to compute leaves intervals for the resources are in the same company as the resource. task-3668605 Forward-Port-Of: odoo/odoo#152827
Steps: -------- - Install project. - Go to settings and select Custom Email Servers. - Add alias domain. - Then go to the project. - Create a new project. - The gap between the email alias and project title is too much. Issue: -------- -When we create a new project the gap between the email alias and project name is too much when only the project is installed and there are no options to display. Cause: ---------- -The margin-top taking too much space. Fix: ----- -After t
Original PR description
Steps: -------- - Install project. - Go to settings and select Custom Email Servers. - Add alias domain. - Then go to the project. - Create a new project. - The gap between the email alias and project title is too much. Issue: -------- -When we create a new project the gap between the email alias and project name is too much when only the project is installed and there are no options to display. Cause: ---------- -The margin-top taking too much space. Fix: ----- -After this commit the space between email-alias and project name is decreased. task-3550638 Forward-Port-Of: odoo/odoo#153277 Forward-Port-Of: odoo/odoo#139908
A user that is not admin cannot create an mail.alias. We can create the alias in sudo since we control the default_values and model that are created with the new alias. Check the _check_alias_domain_id_mc constraint in sudo because non amdin user cannot read model ir.model. Forward-Port-Of: odoo/odoo#153222
Original PR description
A user that is not admin cannot create an mail.alias. We can create the alias in sudo since we control the default_values and model that are created with the new alias. Check the _check_alias_domain_id_mc constraint in sudo because non amdin user cannot read model ir.model. Forward-Port-Of: odoo/odoo#153222
Prior to this commit, adding more than one pricelist to the available pricelists and attempting to create a partner from the Point of Sale would result in an error. opw-3703269 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#153314 Forward-Port-Of: odoo/odoo#151298
Original PR description
Prior to this commit, adding more than one pricelist to the available pricelists and attempting to create a partner from the Point of Sale would result in an error. opw-3703269 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#153314 Forward-Port-Of: odoo/odoo#151298
Prior to this commit, Gift cards assigned to a specific partner were restricted for use only by that partner. This commit rectifies the issue, enabling Gift cards to be usable by any customer as intended. opw-3689391 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#152950 Forward-Port-Of: odoo/odoo#149913
Original PR description
Prior to this commit, Gift cards assigned to a specific partner were restricted for use only by that partner. This commit rectifies the issue, enabling Gift cards to be usable by any customer as intended. opw-3689391 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#152950 Forward-Port-Of: odoo/odoo#149913
Before this PR: Canceling an activity linked to an event produces error because of non provided thread. Steps to reproduce: - Create an activity with event (call or meeting) in chatter - Try to cancel this activity - There is an error about undefined thread and activity remains on the chatter After this PR: - Thread is provided in `onUpdate` method to use in `load()` in chatter - `activityService` deletes the activity with event in `unlink` patch Forward-Port-Of: odoo/odoo#152737
Original PR description
Before this PR: Canceling an activity linked to an event produces error because of non provided thread. Steps to reproduce: - Create an activity with event (call or meeting) in chatter - Try to cancel this activity - There is an error about undefined thread and activity remains on the chatter After this PR: - Thread is provided in `onUpdate` method to use in `load()` in chatter - `activityService` deletes the activity with event in `unlink` patch Forward-Port-Of: odoo/odoo#152737
### [FIX] mail: Fix thread object transfer to chatter in CRM email preview This commit addresses a problem in CRM where it was not possible to send emails directly from the preview window. The issue arose when returning to the chatter interface from the preview window, as the thread object was not properly passed back (to the chatter). This fix ensures the thread object is reintegrated into the chatter interface, resolving the email sending issue. Issue was traced back to the commit
Original PR description
### [FIX] mail: Fix thread object transfer to chatter in CRM email preview This commit addresses a problem in CRM where it was not possible to send emails directly from the preview window. The issue arose when returning to the chatter interface from the preview window, as the thread object was not properly passed back (to the chatter). This fix ensures the thread object is reintegrated into the chatter interface, resolving the email sending issue. Issue was traced back to the commit [FIX] mail: do not reload chatter when not needed https://github.com/odoo/odoo/commit/5d99de10ec09244e10e4130573ad2e0c38e8600 ### [reproduce] - install crm - create activityTypes AT with an email template specified( crm/configuration/activityTypes) - open a Lead, ( crm/sales/MyPiepline) - schedule activity with activity type AT - click "preview" on the activity - click "send" or just close the preview -> BUG traceback opw-3680600 Forward-Port-Of: odoo/odoo#152698
Since [1], the websocket worker is started when a transient thread is added to the mail store. This occurs because this PR introduced a call to the `addChannel` method of the bus service when the current user was not member of the thread. Since transient threads are not yet created, they have a partial state that does not necessarily include channel members hence the impression that the current user is not member of the channel. This PR prevent starting the bus service for transient thread
Original PR description
Since [1], the websocket worker is started when a transient thread is added to the mail store. This occurs because this PR introduced a call to the `addChannel` method of the bus service when the current user was not member of the thread. Since transient threads are not yet created, they have a partial state that does not necessarily include channel members hence the impression that the current user is not member of the channel. This PR prevent starting the bus service for transient threads. [1]: https://github.com/odoo/odoo/pull/146800 Forward-Port-Of: odoo/odoo#153000
Previously, the order line quantity would inadvertently update if the Customer list screen was opened without clicking the search bar and typing numbers. This commit resolves the issue by disabling the event handler while a temp screen is open. Also, it enhances usability by focusing on the search bar upon opening the Customer list screen. opw-3634910 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#151606 Forward-Port-Of
Original PR description
Previously, the order line quantity would inadvertently update if the Customer list screen was opened without clicking the search bar and typing numbers. This commit resolves the issue by disabling the event handler while a temp screen is open. Also, it enhances usability by focusing on the search bar upon opening the Customer list screen. opw-3634910 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#151606 Forward-Port-Of: odoo/odoo#146993
Im timesheet_grid when starting a timer in the kanban view, the dropdowns are displayed behind the o_kanban_record, making it impossible to use. This is due to a change made on the pinned_header z-index introduced in commit[1]. This commit applies a z-index-1 on the pinned_header element, making the dropdowns contained inside this div being able to be displayed above the kanban cards. [1]: https://github.com/odoo/enterprise/commit/7b1f18398d0d1f66269d742ef2441ef2bb41f7e6 task-3684460
Original PR description
Im timesheet_grid when starting a timer in the kanban view, the dropdowns are displayed behind the o_kanban_record, making it impossible to use. This is due to a change made on the pinned_header z-index introduced in commit[1]. This commit applies a z-index-1 on the pinned_header element, making the dropdowns contained inside this div being able to be displayed above the kanban cards. [1]: https://github.com/odoo/enterprise/commit/7b1f18398d0d1f66269d742ef2441ef2bb41f7e6 task-3684460 | Before | | :----: | |  | | After | | | Forward-Port-Of: odoo/enterprise#54313
In #48767, we introduced the collapsing of a certain side panel feature relying on Bootstrap. Bootstrap apparenty has an internal "popote" to make the target node fold and unfold and one of our tests actually tests against this internal popote. Unfortunately, the test is not reliable and from a computer to the other or even depending on the browser you use, it does not behave consistently. This commit removes the unreliable step as it does not test our own codebase. Task: 3736963 Forw
Original PR description
In #48767, we introduced the collapsing of a certain side panel feature relying on Bootstrap. Bootstrap apparenty has an internal "popote" to make the target node fold and unfold and one of our tests actually tests against this internal popote. Unfortunately, the test is not reliable and from a computer to the other or even depending on the browser you use, it does not behave consistently. This commit removes the unreliable step as it does not test our own codebase. Task: 3736963 Forward-Port-Of: odoo/enterprise#56291
Before this commit: GST treatment for composition was under the domain of b2c* which is not the correct domain for composition UIN Holder treatment was inconsistently placed After this commit: composition GST treatment is fixed correctly under b2b and fixed the consistency for UIN Holder in l10n_in_reports* Forward-Port-Of: odoo/enterprise#56225
Original PR description
Before this commit: GST treatment for composition was under the domain of b2c* which is not the correct domain for composition UIN Holder treatment was inconsistently placed After this commit: composition GST treatment is fixed correctly under b2b and fixed the consistency for UIN Holder in l10n_in_reports* Forward-Port-Of: odoo/enterprise#56225
task-3533500 Forward-Port-Of: odoo/enterprise#55990
Original PR description
task-3533500 Forward-Port-Of: odoo/enterprise#55990
Before this commit, when a customer paid a subscription from 'Generate payment link' and got an error in the transaction or if it was canceled, Odoo was creating a draft invoice (it remained open) and saving the faulty token. After this commit. the draft invoice is canceled right after the error is detected and the token is saved only if the renewal state of the subscription is authorized. Task-id: 3734247 Forward-Port-Of: odoo/enterprise#56232
Original PR description
Before this commit, when a customer paid a subscription from 'Generate payment link' and got an error in the transaction or if it was canceled, Odoo was creating a draft invoice (it remained open) and saving the faulty token. After this commit. the draft invoice is canceled right after the error is detected and the token is saved only if the renewal state of the subscription is authorized. Task-id: 3734247 Forward-Port-Of: odoo/enterprise#56232
Versions: --------- - saas-16.2 Issue: ------ The partner address disappears after saving the record. Cause: ------ Starting from version 16.2, dynamic context keys are ignored for read RPCs. Solution: --------- Assign a context key that doesn't require evaluation, such as a field. task-3604404 Forward-Port-Of: odoo/enterprise#56179 Forward-Port-Of: odoo/enterprise#54534
Original PR description
Versions: --------- - saas-16.2 Issue: ------ The partner address disappears after saving the record. Cause: ------ Starting from version 16.2, dynamic context keys are ignored for read RPCs. Solution: --------- Assign a context key that doesn't require evaluation, such as a field. task-3604404 Forward-Port-Of: odoo/enterprise#56179 Forward-Port-Of: odoo/enterprise#54534
Purpose ======= On the 3 December 2023, we are using the API version 202211. However, the version 202209 is depreciated, so it might be the time to upgrade. Technical ========= The only technical change is the fact that projections are removed. Those were useful to fetch everything we needed in a single HTTP request, and so now, we have to make many HTTP requests to fetch the data (at least, one per "model"). Task-3620605 Forward-Port-Of: odoo/enterprise#56227 Forward-Port-Of: odoo
Original PR description
Purpose ======= On the 3 December 2023, we are using the API version 202211. However, the version 202209 is depreciated, so it might be the time to upgrade. Technical ========= The only technical change is the fact that projections are removed. Those were useful to fetch everything we needed in a single HTTP request, and so now, we have to make many HTTP requests to fetch the data (at least, one per "model"). Task-3620605 Forward-Port-Of: odoo/enterprise#56227 Forward-Port-Of: odoo/enterprise#52006
The key used was the id of the journal item, this is fine for most cases but will fail due to duplicate if the "Cash basis" function is set and a receivable aml is reconciled with two payment made at different dates. In this case the report will show the receivable aml split in two with the date/amount of each payment. To support this case, we now use a markup with the date of aml to produce unique keys. When the two payments have the same date, it's ok since the receivable aml is not split
Original PR description
The key used was the id of the journal item, this is fine for most cases but will fail due to duplicate if the "Cash basis" function is set and a receivable aml is reconciled with two payment made at different dates. In this case the report will show the receivable aml split in two with the date/amount of each payment. To support this case, we now use a markup with the date of aml to produce unique keys. When the two payments have the same date, it's ok since the receivable aml is not split in the report. Steps to reproduce 1/ Create an invoice 2/ Register 2 payments at different dates for this invoice 3/ General ledger with options "Unfold all" + "Cash basis" => Traceback `Got duplicate key in t-foreach: ~account.account~6|~account.move.line~1128` opw-3687800 Forward-Port-Of: odoo/enterprise#55136
## Description Add missing index on `user_id` and `partner_id` to support the searches done in `get_recent_phone_calls` and `_get_number_of_missed_calls`. In a long living database that is making heavy use of the module, the table can grow to the millions of records. Forward-Port-Of: odoo/enterprise#54710
Original PR description
## Description Add missing index on `user_id` and `partner_id` to support the searches done in `get_recent_phone_calls` and `_get_number_of_missed_calls`. In a long living database that is making heavy use of the module, the table can grow to the millions of records. Forward-Port-Of: odoo/enterprise#54710
### Steps to reproduce * install `l10n_es_reports` * switch to a Spanish company * open the Tax Report * on the top right, switch the report to "Tax Report (Mod 347) (ES)" * attempt to audit any line in that report (click on the amounts) You should be met with an empty list view. ### Cause When we attempt to get the domain for the lines to display, the `MOD_347_CUSTOM_ENGINES_DOMAINS` dict keys do not match with the custom engine function name. https://github.com/odoo/enterpri
Original PR description
### Steps to reproduce * install `l10n_es_reports` * switch to a Spanish company * open the Tax Report * on the top right, switch the report to "Tax Report (Mod 347) (ES)" * attempt to audit any line in that report (click on the amounts) You should be met with an empty list view. ### Cause When we attempt to get the domain for the lines to display, the `MOD_347_CUSTOM_ENGINES_DOMAINS` dict keys do not match with the custom engine function name. https://github.com/odoo/enterprise/blob/61e565517cc54ee0af9ed6123d3dc23b52c52522/l10n_es_reports/models/aeat_tax_reports.py#L101-L106 opw-3697928 Forward-Port-Of: odoo/enterprise#56199 Forward-Port-Of: odoo/enterprise#56044
In the intrastat report, each account move is now grouped by country (using norm ISO 3166), currency (norm ISO 4217) and commodity code. Each line can be unfolded to show each individual account move with its corresponding values. When only Arrival or Dispatch is selected, the total value for each group is shown as well as a total line for the total value of Arrivals or Dispatches. This change was done because usually people and organisation to which they must report this information ar
Original PR description
In the intrastat report, each account move is now grouped by country (using norm ISO 3166), currency (norm ISO 4217) and commodity code. Each line can be unfolded to show each individual account move with its corresponding values. When only Arrival or Dispatch is selected, the total value for each group is shown as well as a total line for the total value of Arrivals or Dispatches. This change was done because usually people and organisation to which they must report this information aren't interested in each individual move but rather to have an overall view of how much of a certain commodity was ship to a certain country. The previous report was too verbose. People still have the options to unfold all the lines if they need it. task-3605696 Forward-Port-Of: odoo/enterprise#56353 Forward-Port-Of: odoo/enterprise#31893