Wednesday, December 13, 2023
36 changes · 17.0
Enhancements to existing features
This update improves how the Austrian financial reports calculate values by switching to a more efficient formula approach. Instead of using redundant domain formulas, the system now uses aggregation formulas, which allows the reporting engine to work more effectively and produce cleaner, more reliable financial reports.
Original PR description
The aim of this commit is changing 2 lines where we are using domain formula instead of aggregation formula. The idea is that we don't want to have "redundant" domains and we want to use the power of report engine by using the right formula, in that case, the aggregation one. task-id: 3627640 Forward-Port-Of: odoo/enterprise#52202
Resolved issues and error corrections
This fix removes an overly short survey test step that could end before the system was fully ready, causing occasional automated test failures. Survey session setup is now handled directly in test code, improving reliability without changing the user-facing survey experience.
Original PR description
This commit fixes a nondeterministic runbot issue during the survey session management tour suite (that actually contains multiple tours).
It turns out that the first tour is so short that it does not let enough time to the web framework to correctly initialize everything before it gets killed (as the tour steps are completed almost instantly).
It's hard to say exactly where the issue comes from, as the error does not mention anything (we only know that it's a rejected promise): """
Error received after termination:
PromiseRejectionEvent(
isTrusted=true,
reason=Event,
type='unhandledrejection',
target=Window,
currentTarget=Window)"
"""
Removing this first tour also removes the nondeterministic issue.
It seems like an acceptable compromise as this tour was not really testing anything anyway, we now directly start the session from the python code.
(Note: this issue only started occurring in v17).
Task-3637591Miscellaneous changes
Currently, when a peppol document is received, we log a success message regardless of whether the account_move has been created properly or not. This commit changes to only show the message if everything went well. A follow-up to a fix for opw-3628030 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#146202
Original PR description
Currently, when a peppol document is received, we log a success message regardless of whether the account_move has been created properly or not. This commit changes to only show the message if everything went well. A follow-up to a fix for opw-3628030 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#146202
Fixes the event registration confirmation email preview so the QR code displays as a proper square instead of appearing compressed. This helps attendees and staff scan registration QR codes reliably from event emails.
Original PR description
Current behaviour: --- QR code is squished, it's 77x21 px Expected behaviour: --- QR code should be 100x100 px Steps to reproduce: --- 1. Go Email Templates 2. Find 'Event: Registration Confirmation' 3. Click on preview 4. QR code is squished opw-3625701 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Fixes an issue where portal breadcrumbs could show the same page title twice after installing subcontracting-related modules. This keeps customer-facing navigation clearer across pages like projects, tasks, timesheets, and tickets.
Original PR description
…cts' twice Steps to Reproduce: - install service apps and website - install website related bridge modules - install quality and related mrp_subcontracting bridge module - click on website , click on My account - click on project ,or timesheet,or tasks,or tickets Issue: - after clicking,we will notice that breadcrumb indicates 'title' twice Cause: - this is because,in mrp_subcontracting , the title for productions is given without checking the page_name , so that will affect all the titles. Solution: - if we gave condition to check the page name for production this issue is solved. task-3607053 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 project update view now counts the relevant sale order item correctly for billable projects. This helps users trust the stat button total and open the expected sale order item without seeing misleading counts.
Original PR description
In the project update view, the sale order items stat button does not display the right count of item. This is because sale order lines are not taken into account for the stat button To reproduce: - Install sale_project - Create a billable project with a customer - Open the project update view and add some sol. - The stat button count should display `1` and when opened, it should only display the `project.project.sale_line_id` task-3573591 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This change reverses a previous adjustment to project views that could break existing customizations and cause installation errors for related field service functionality. It preserves compatibility for customers already using the stable version, reducing the risk of disruption during installs or upgrades.
Original PR description
Revert [1] Changing `t` into `span` is not allowed in stable, in case some customization already exist and have xpath that target `t`. The change OE side [2] is problematic too: if a DB has the old XML version (`t`) and the user tries to install `industry_fsm`, an error will be raised: `Element '<xpath expr="//span[@t-if=&https://github.com/odoo/odoo/issues/39;record.partner_id.value&https://github.com/odoo/odoo/issues/39;]">'` `cannot be located in parent view` [1] https://github.com/odoo/odoo/commit/b3e3c92b52ce326661c262046cc455c3439fa1a1 [2] https://github.com/odoo/enterprise/commit/094009669beaac46ed6ebb7689ecffea59c375ae OPW-3629163 sentry-4700256130
This fixes a display issue in the restaurant point-of-sale screen where category counts could fail to show correctly. It ensures the interface can reliably render the category list, reducing confusion for restaurant staff during ordering.
Original PR description
In the commit 7675905 a t-for loop was introduced in the `ActionpadWidget` override from `pos_restaurant` where the t-key value was undefined. This commit fixes the issue by giving a proper value to the t-key. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The date and time picker now correctly detects when a selected value has not changed, preventing unnecessary update actions. This reduces avoidable processing and helps keep user interactions smoother and more predictable.
Original PR description
### [FIX] web: do not apply same datetime picker value
Before this commit, the equality check performed by the datetime service
relied on a JSON-strigified version of the value on one end, and on an
array of ISO strings on the other end. This meant that the value was
never equal to itself and that the `onApply` callback would be called
even if the value remained unchanged.
This commit fixes that by ensuring that the compared values have the
same shape.
### [REF] web: add missing types for datetime hook & service
This commit adds missing type definitions for both the datetime picker
hook and service.
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis update fixes a missing translation in the website shop so customers can see the intended localized text. It helps provide a more consistent shopping experience for visitors using translated versions of the site.
Original PR description
--- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update corrects the abnormal spacing between the 'New' and 'Validate' buttons in the Timesheet to Validate Kanban view. The fix removes an unnecessary spacing property that was left over from a previous version, resulting in a cleaner and more consistent button layout.
Original PR description
**Steps:** - Open Timesheet > Timesheet to Validate - Switch to the Kanban View **Issue:** - Abnormal spacing between the buttons 'New' and 'Validate' **Cause:** - The button 'Validate' is given the property ms-2 which was appropriate for the older version, but it won't be needed in the new code as gap-1 is given. **Fix:** - Removing ms-2 class from the Validate button **Task:** 3394985 Forward-Port-Of: odoo/enterprise#43583
The accounting dashboard was displaying two reconcile buttons for cash journals that needed reconciliation. This fix removes the duplicate button so only one appears, resolving a display issue that resulted from an earlier update that should have been limited to older versions.
Original PR description
Description of the issue/behavior this commit fixes: On the accounting dashboard, when at least one items is to be reconciled on a cash journal, the box of that journal shows two reconcile buttons. This behavior comes from opw-3384351 which was targetting 16.2 and was fw to master while it should have stopped at 16.3. From 16.4, the reconcile button is managed for cash journals. --- Desired behavior after this commit is merged: This commit reverses the problematic fix as from 16.4. With this commit, only one button shows up at any time. --- task-3624210 Forward-Port-Of: odoo/enterprise#52241
Commit [1] removed the `email_from` field from the `project.task` model but forgot to adapt/delete some field occurences. One of those is related to the form in the website builder which allows to create task when the form is sent. Two errors were detected: - Non critical: The field is still passed to the form field whitelisting process. Since the whitelisting is done in raw SQL, it didn't crash or log anything even if the column did not exist anymore. - Critical: The field
Original PR description
Commit [1] removed the `email_from` field from the `project.task` model but forgot to adapt/delete some field occurences. One of those is related to the form in the website builder which allows to…
Commit [1] removed the `email_from` field from the `project.task` model but forgot to adapt/delete some field occurences.
One of those is related to the form in the website builder which allows to create task when the form is sent.
Two errors were detected:
- Non critical:
The field is still passed to the form field whitelisting process. Since the whitelisting is done in raw SQL, it didn't crash or log anything even if the column did not exist anymore.
- Critical:
The field was still marked as model required in the form JS registry, altering the form builder behaviors. One of those is that when the form input related to this field was re-created (eg when changing / hovering an option in the right panel), it would lose it's "name" attribute. Two possible issues from that point:
1. When a visitor submit the form, the email is not send anymore and is just lost, you have no way to reach back to him.
2. (Minor) The auto-fill behavior of the form was not working anymore
Probably more issues were introduced but only those ones got detected as of today.
Step to reproduce:
- Drop a website form, choose "Create a Task"
- Focus the default "Email" field
- Hover the mouse on the "eye" icon ("Invisible") next to the Position attribute. If you inspect the DOM, the the input has now lost the `name` attribute.
- If you save, you will face the issues reported above.
- If you thenreopen the editor and focus the email field again, the tooltip will now say that the "null" field is required.
[1]: https://github.com/odoo/odoo/commit/a424cf481c676a230beeb6102fc67bedf472a882
opw-3626573
Forward-Port-Of: odoo/odoo#145559## Description Indexes on a Selection field are never used in a `NOT IN` where clause, as PostgreSQL doesn't have the complementary values (in DB a Selection field is just a VarChar) to make use of an index on the field. The ORM currently doesn't invert `not in <selection>` -> `in <complement of selection>`. ## Benchmark Positive impact in the project modules all around, specially for long running projects where the proportion of "done" tasks are >90% of the project's task. On a populated
Original PR description
## Description Indexes on a Selection field are never used in a `NOT IN` where clause, as PostgreSQL doesn't have the complementary values (in DB a Selection field is just a VarChar) to make use of an index on the field. The ORM currently doesn't invert `not in <selection>` -> `in <complement of selection>`. ## Benchmark Positive impact in the project modules all around, specially for long running projects where the proportion of "done" tasks are >90% of the project's task. On a populated project with 10k tasks, 200 of those are open, there were around 10x improvement on the requests linked to rendering the kanban view of the project. More elaborate benchmarks are available in the referenced task. ## Reference task-3576802 ## Related PR https://github.com/odoo/enterprise/pull/52689 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#146120
Lacking a flush to database before the query used to compute the gap-in-sequence warning, the gap-in-sequence warning would stay active even when the all-users lock-date was set. Which is confusing for the user as they can't do anything about it. This - adds the required flushes - adds a tooltip explaining the warning in more details as it was deemed confusing - Adds all the moves that took a sequence number in the query Task-3613058 Description of the issue/feature this PR addres
Original PR description
Lacking a flush to database before the query used to compute the gap-in-sequence warning, the gap-in-sequence warning would stay active even when the all-users lock-date was set. Which is confusing for the user as they can't do anything about it. This - adds the required flushes - adds a tooltip explaining the warning in more details as it was deemed confusing - Adds all the moves that took a sequence number in the query Task-3613058 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#145998 Forward-Port-Of: odoo/odoo#144567
This issue has been introduced in Odoo 14.0. Description of the issue/feature this PR addresses: The view set a domain with `share = False` but the model search for users with group `group_mrp_user` ``` user_id = fields.Many2one( 'res.users', 'Responsible', default=lambda self: self.env.user, states={'done': [('readonly', True)], 'cancel': [('readonly', True)]}, domain=lambda self: [('groups_id', 'in', self.env.ref('mrp.group_mrp_user').id)]) ``` Curren
Original PR description
This issue has been introduced in Odoo 14.0.
Description of the issue/feature this PR addresses:
The view set a domain with `share = False` but the model search for users with group `group_mrp_user`
```
user_id = fields.Many2one(
'res.users', 'Responsible', default=lambda self: self.env.user,
states={'done': [('readonly', True)], 'cancel': [('readonly', True)]},
domain=lambda self: [('groups_id', 'in', self.env.ref('mrp.group_mrp_user').id)])
```
Current behavior before PR:
All internal users can be Responsible of a production order.
Desired behavior after PR is merged:
Only users owned by group `group_mrp_user` will be selectable as Responsible.
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#145973
Forward-Port-Of: odoo/odoo#144722Current behavior: When a reward is applied on an order containing different product with different taxes, the rewarded is divided in multiple lines (one per tax) This cause issue when calling, the `_updateRewardLines` method. Because it will consider each line as a full reward, and therefore will apply the reward multiple times even though the reward is only applied once. Steps to reproduce: - Create a reward with a discount of 5$ in exchange of 100 points - The reward should give 1 point
Original PR description
Current behavior: When a reward is applied on an order containing different product with different taxes, the rewarded is divided in multiple lines (one per tax) This cause issue when calling, the `_updateRewardLines` method. Because it will consider each line as a full reward, and therefore will apply the reward multiple times even though the reward is only applied once. Steps to reproduce: - Create a reward with a discount of 5$ in exchange of 100 points - The reward should give 1 point per 1$ spent - Create a product with a price of 100$ and a tax of 10% - Create a product with a price of 100$ and no tax - Open the POS and add the 2 products to the order - Select a customer, and click the reward button - The reward will be applied 2 times (4 reward lines are created) opw-3583174 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#145582 Forward-Port-Of: odoo/odoo#142738
Steps to reproduce ================== - Go to users - Open the export dialog - Expand the Groups field - Add the Groups > Groups/Access Controls field - Check the import compatibility option - Expand the Groups field again => `TypeError: this.knownFields[id] is undefined` Solution ======== The expandedFields were not reset. We also need to update the t-key to take the compatibility state into account. opw-3378834 Forward-Port-Of: odoo/odoo#145901
Original PR description
Steps to reproduce ================== - Go to users - Open the export dialog - Expand the Groups field - Add the Groups > Groups/Access Controls field - Check the import compatibility option - Expand the Groups field again => `TypeError: this.knownFields[id] is undefined` Solution ======== The expandedFields were not reset. We also need to update the t-key to take the compatibility state into account. opw-3378834 Forward-Port-Of: odoo/odoo#145901
Versions: --------- - 16.0+ Steps to reproduce: ------------------- 1. In Timesheets, add a new line; 2. link it to a Sale Order project; 3. make it non-billable by clearing the Sale Order Item field; 4. select related project in Project / Configuration / Projects; 5. in Invoicing tab, add yourself and a Sales Order Item, then save; 6. go back to Timesheets; 7. check the Sales Order Item field of the timesheet you created. Issue: ------ Sales Order Item was changed automaticall
Original PR description
Versions: --------- - 16.0+ Steps to reproduce: ------------------- 1. In Timesheets, add a new line; 2. link it to a Sale Order project; 3. make it non-billable by clearing the Sale Order Item…
Versions: --------- - 16.0+ Steps to reproduce: ------------------- 1. In Timesheets, add a new line; 2. link it to a Sale Order project; 3. make it non-billable by clearing the Sale Order Item field; 4. select related project in Project / Configuration / Projects; 5. in Invoicing tab, add yourself and a Sales Order Item, then save; 6. go back to Timesheets; 7. check the Sales Order Item field of the timesheet you created. Issue: ------ Sales Order Item was changed automatically, this shouldn't happen after a manual change. Cause: ------ The `so_line_field` widget used the `this.changeOnEmpty` attribute to check whether `is_so_line_edited` should be set, but this was removed in 1ecdbfcfbffae66544bfec578359ac4a6b6bc416, hence the field will never be set when clearing the `so_field` value. Solution: --------- On a field change, compare the previous ID of `so_line` with the new ID, and set `is_so_line_edited` to `true` if they're different. Related: -------- odoo/enterprise#52544 opw-3547725 Forward-Port-Of: odoo/odoo#145821
Usecase to reproduce: - Install purchase and mrp - On a product set both routes manufacture and buy - Create a BoM for the product and define a seller - Sell a unit - Open the replenishment. Buy or manufacture is set as route - Go to the settings and set the route not sellected to the smallest sequence - Delete the orderpoint and open the replenishment menu again. Expected behavior: The new route with smallest sequence is selected Current behavior: The same rule is selected and th
Original PR description
Usecase to reproduce: - Install purchase and mrp - On a product set both routes manufacture and buy - Create a BoM for the product and define a seller - Sell a unit - Open the replenishment. Buy or…
Usecase to reproduce: - Install purchase and mrp - On a product set both routes manufacture and buy - Create a BoM for the product and define a seller - Sell a unit - Open the replenishment. Buy or manufacture is set as route - Go to the settings and set the route not sellected to the smallest sequence - Delete the orderpoint and open the replenishment menu again. Expected behavior: The new route with smallest sequence is selected Current behavior: The same rule is selected and the order used by _get_rule and to compute the lead time is bypass It happens because both override of the method are at the same level (super of stock) and are call arbitrary one before the other. In order to fix it uses rule_ids that was computed before calling the function and it contains the real rules used to compute the lead time 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#143836
Before this commit the clean_assetbundle could unlink invalid attachment, mostly when generating a no website assetbundle with a different version than a website one, the website assetbundle will be deleted. ``` Generating a new asset bundle attachment /web/assets/439-b4c80c3/1/web.assets_frontend.min.css (id:439) Generating a new asset bundle attachment /web/assets/440-3723971/web.assets_frontend.min.css (id:440) Deleting attachments [439] (matching /web/assets/%-%/web.assets_frontend.m
Original PR description
Before this commit the clean_assetbundle could unlink invalid attachment, mostly when generating a no website assetbundle with a different version than a website one, the website assetbundle will be…
Before this commit the clean_assetbundle could unlink invalid attachment, mostly when generating a no website assetbundle with a different version than a website one, the website assetbundle will be deleted. ``` Generating a new asset bundle attachment /web/assets/439-b4c80c3/1/web.assets_frontend.min.css (id:439) Generating a new asset bundle attachment /web/assets/440-3723971/web.assets_frontend.min.css (id:440) Deleting attachments [439] (matching /web/assets/%-%/web.assets_frontend.min.css) because it was replaced with /web/assets/%-3723971/%%% ``` The issue is that `%-%/` will match `439-b4c80c3/1/` and not only `439-b4c80c3/` Note that it looks like this issue existed for a while but was invisible because before 16.4 clean_attachment was invalidating the ormcache, hiding the fact that a still valid asset was deleted and regenerated. The proposed fix replaces the domain with `%-_______/`. The unique is always 7 character long. Note that this change was already made in 17.0 when removing the id from the asset url so this doesn't need to be completely forward-ported. A self.clean_attachments(extension) is also added when copying an assets because this was cleaned by side effect before. (to check) opw-3558552 Forward-Port-Of: odoo/odoo#144515
Issue Description: ================== Issue: Inability to validate transfers generated from the POS's "ship later" feature. Steps to Reproduce: =================== 1. Create a new user or configure Marc Demo to have only User access in Sales, Inventory, and POS. 2. Create a storable product that can be sold in POS, where the product category uses automatic FIFO valuation. 3. In the POS configuration, enable the "Ship Later" feature. 4. Log in as the new user (e.g., Marc Demo). 5. Sell
Original PR description
Issue Description: ================== Issue: Inability to validate transfers generated from the POS's "ship later" feature. Steps to Reproduce: =================== 1. Create a new user or configure…
Issue Description: ================== Issue: Inability to validate transfers generated from the POS's "ship later" feature. Steps to Reproduce: =================== 1. Create a new user or configure Marc Demo to have only User access in Sales, Inventory, and POS. 2. Create a storable product that can be sold in POS, where the product category uses automatic FIFO valuation. 3. In the POS configuration, enable the "Ship Later" feature. 4. Log in as the new user (e.g., Marc Demo). 5. Sell the new product in POS, choose "ship later," and confirm the order. 6. Go to Inventory and locate the created transfer (reference Shop/000X). You may need to disable all filters to find it. 7. Attempt to validate the transfer and encounter an access error because the User is not an Accounting or Purchase user. Proposed Solution: ================== The solution involves adding sudo privileges to the creation of account moves in the POS. This will allow the validation of transfers generated by the "ship later" feature, even for users who are not designated as Accounting or Purchase users. By implementing sudo, we can ensure that the inventory valuation and account moves are correctly processed, resolving the access issue that arises during transfer validation in the POS system. opw-3572111 Forward-Port-Of: odoo/odoo#145523
Prior to this commit, pressing the backspace key to remove an orderline when no orderline was present resulted in a traceback error. opw-3622679 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#145832 Forward-Port-Of: odoo/odoo#144714
Original PR description
Prior to this commit, pressing the backspace key to remove an orderline when no orderline was present resulted in a traceback error. opw-3622679 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#145832 Forward-Port-Of: odoo/odoo#144714
Steps to reproduce: - Install l10n_fr - Switch to a French Company (i.e. FR Company) - Create an invoice for a contact from Monaco with a VAT number => The default fiscal position is "Import/Export Hors Europe + DOM-TOM". In France, for Monaco, it should be "Domestique - France". Solution: Create a country group with France and Monaco and set it to "Domestique - France" fiscal position. opw-3617761 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.c
Original PR description
Steps to reproduce: - Install l10n_fr - Switch to a French Company (i.e. FR Company) - Create an invoice for a contact from Monaco with a VAT number => The default fiscal position is "Import/Export Hors Europe + DOM-TOM". In France, for Monaco, it should be "Domestique - France". Solution: Create a country group with France and Monaco and set it to "Domestique - France" fiscal position. opw-3617761 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#145959 Forward-Port-Of: odoo/odoo#145412
### Summary Foreign companies that trade with non-enterprises in the EU may have a VATIN starting with "EU" instead of a country code. However, the tax ID validation does not account for that. ### Steps to reproduce * install base_vat and contacts * create a Canadian company with a tax with the format EU00000000 => you should be met with a validation error. opw-3551347 Forward-Port-Of: odoo/odoo#140630
Original PR description
### Summary Foreign companies that trade with non-enterprises in the EU may have a VATIN starting with "EU" instead of a country code. However, the tax ID validation does not account for that. ### Steps to reproduce * install base_vat and contacts * create a Canadian company with a tax with the format EU00000000 => you should be met with a validation error. opw-3551347 Forward-Port-Of: odoo/odoo#140630
Fix a typo in an account name. Forward-Port-Of: odoo/odoo#145923 Forward-Port-Of: odoo/odoo#145713
Original PR description
Fix a typo in an account name. Forward-Port-Of: odoo/odoo#145923 Forward-Port-Of: odoo/odoo#145713
Issue: ====== Marking an activity of calender event as marked with text raises an error. Steps to reproduce the issue: ============================= -Go to any contact and create a meeting with him as an activity in the chatter. - Mark the actvity as done and add some text as feedback. - An error showing that the record is deleted. The origin of the issue: ======================== The parts of writing the description and calling `_action_done` are swapped , we need first to write t
Original PR description
Issue: ====== Marking an activity of calender event as marked with text raises an error. Steps to reproduce the issue: ============================= -Go to any contact and create a meeting with him as an activity in the chatter. - Mark the actvity as done and add some text as feedback. - An error showing that the record is deleted. The origin of the issue: ======================== The parts of writing the description and calling `_action_done` are swapped , we need first to write the description to be used later in message to be posted and also marking the activity as done will unlink the activity which will unlink the calendar event too so we can't access it anymore. opw-3623719 Forward-Port-Of: odoo/odoo#145911 Forward-Port-Of: odoo/odoo#145781
Description of the issue/feature this PR addresses: When installing the Singaporean loca, the Tax ID label is renamed to "GST No.". This is global change meaning the label is changed for Singaporean companies but also for any other company. This should not happen as the rename should only be applied when using a Singaporean company and viewing any company. For example : - Belgian company viewing Belgian company : GST No. - Belgian company viewing Singaporean company : GST No. - Singapo
Original PR description
Description of the issue/feature this PR addresses: When installing the Singaporean loca, the Tax ID label is renamed to "GST No.". This is global change meaning the label is changed for Singaporean…
Description of the issue/feature this PR addresses: When installing the Singaporean loca, the Tax ID label is renamed to "GST No.". This is global change meaning the label is changed for Singaporean companies but also for any other company. This should not happen as the rename should only be applied when using a Singaporean company and viewing any company. For example : - Belgian company viewing Belgian company : GST No. - Belgian company viewing Singaporean company : GST No. - Singaporean company viewing Belgian company : GST No. - Singaporean company viewing Singaporean company : GST No. --- Desired behavior after the PR is merged: This commit changes the way the Tax ID label is changed. The label is not changed upon installation of the Singaporean loca but is actually adapted on each opening of a company view so that the tax id label of the company being USED is applied instead of the default one. For example : - Belgian company viewing Belgian company : Tax ID - Belgian company viewing Singaporean company : Tax ID - Singaporean company viewing Belgian company : GST No. - Singaporean company viewing Singaporean company : GST No. --- task-3530802 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#137966
Speedup computation of tax_country_id by first filtering on record with `fiscal_position_id.foreign_vat`. Then group records without foreign_vat by company_id and call `__setitem__` on each group. This reduces the number of calls to field.write and provide an overall speedup on average. In the worst case, where each record has a fiscal_position_id with foreign_vat, the speed is the same as the one prior to this PR. #### speedup Customer database with 60k account_moves, 150k account_move_li
Original PR description
Speedup computation of tax_country_id by first filtering on record with `fiscal_position_id.foreign_vat`. Then group records without foreign_vat by company_id and call `__setitem__` on each group.…
Speedup computation of tax_country_id by first filtering on record with `fiscal_position_id.foreign_vat`. Then group records without foreign_vat by company_id and call `__setitem__` on each group. This reduces the number of calls to field.write and provide an overall speedup on average. In the worst case, where each record has a fiscal_position_id with foreign_vat, the speed is the same as the one prior to this PR. #### speedup Customer database with 60k account_moves, 150k account_move_lines, 1 company Best case database with 1 company and all fiscal_position_id.foreign_vat is NULL `_compute_tax_country_id` increasing size of recordset. | Number of records | Before PR | After PR | |:-------------------------:|:--------------:|:-----------:| | 25 | 191ms | 25ms | | 100 | 0.84s | 60ms | | 500 | 4.03s | 220ms | | 1000 | 7.37s | 456ms | --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#145625 Forward-Port-Of: odoo/odoo#143224
An empty header was left in invoicing config settings after the refactoring of res_config_settings. This commit removes the empty header that creates empty space in Customer Invoices section of the settings. task-3619987 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#144821
Original PR description
An empty header was left in invoicing config settings after the refactoring of res_config_settings. This commit removes the empty header that creates empty space in Customer Invoices section of the settings. task-3619987 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#144821
### Steps - Create a sale order - Send it to the customer - Go to the link in the mail ### Issue The avatar of the sender is not displayed in the portal chatter but should be. ### Reason Since 16.0 some rules have been added on ``sale.order`` Model, so you need to log in to get the read right ### Solution After discussing with reth, we can create a new route in ``portal`` controller just for avatar to be showed by bypassing record access rules but ensure token used is valid. op
Original PR description
### Steps - Create a sale order - Send it to the customer - Go to the link in the mail ### Issue The avatar of the sender is not displayed in the portal chatter but should be. ### Reason Since 16.0 some rules have been added on ``sale.order`` Model, so you need to log in to get the read right ### Solution After discussing with reth, we can create a new route in ``portal`` controller just for avatar to be showed by bypassing record access rules but ensure token used is valid. opw-3383983 Forward-Port-Of: odoo/odoo#144855 Forward-Port-Of: odoo/odoo#141414
In a Safari or with GNOME web browser: - Run a Odoo server without the password policy app - Go to Settings->User->Select an user - Click on the action menu and "Change Password" Current Behaviour ----------------- The "New password" column have a width of 0.  Expected Behaviour ------------------ The "New password" column is shown. This commit sets a min width to the new password colu
Original PR description
In a Safari or with GNOME web browser: - Run a Odoo server without the password policy app - Go to Settings->User->Select an user - Click on the action menu and "Change Password" Current Behaviour ----------------- The "New password" column have a width of 0.  Expected Behaviour ------------------ The "New password" column is shown. This commit sets a min width to the new password column to avoid this weird shenanigan from Safari of setting the width to 0. After some reverse engineering of understanding why Safari does that I was not able to find why. task-id: 3573558 Forward-Port-Of: odoo/odoo#145447 Forward-Port-Of: odoo/odoo#143353
Description of the issue/feature this PR addresses: When selecting the "group by date" option in the timesheet portal view, a traceback error occurs. Fix: This PR addresses the traceback error by improving the handling of recordsets when grouping by date. task:3468392 Forward-Port-Of: odoo/odoo#135005
Original PR description
Description of the issue/feature this PR addresses: When selecting the "group by date" option in the timesheet portal view, a traceback error occurs. Fix: This PR addresses the traceback error by improving the handling of recordsets when grouping by date. task:3468392 Forward-Port-Of: odoo/odoo#135005
The issue of the start date appearing before the task name in the project task list view is caused by a duplication of the company_id in the list view definition. Consequently, this problem is linked to the task with ID 3213526. task-3468392 Forward-Port-Of: odoo/odoo#130231
Original PR description
The issue of the start date appearing before the task name in the project task list view is caused by a duplication of the company_id in the list view definition. Consequently, this problem is linked to the task with ID 3213526. task-3468392 Forward-Port-Of: odoo/odoo#130231
Steps: --------- - installed mrp_account and hr_timesheet - Got to timesheet > my timesheet list view - Select multi timesheet - Click on print action - Print WIP report - Issue: ------- When mrp_account is installed, the WIP report is shown in the print action of the timesheet.throw the traceback when we select multi timesheet line and print the WIP report. Fixed: ------- we fixed traceback when we select multiple analytic line and print the WIP Report. t
Original PR description
Steps: --------- - installed mrp_account and hr_timesheet - Got to timesheet > my timesheet list view - Select multi timesheet - Click on print action - Print WIP report - Issue: ------- When mrp_account is installed, the WIP report is shown in the print action of the timesheet.throw the traceback when we select multi timesheet line and print the WIP report. Fixed: ------- we fixed traceback when we select multiple analytic line and print the WIP Report. task-3465424 Forward-Port-Of: odoo/odoo#132005
field relation is undefined when the field is available in view while adding a new section at that time set the relation value but while the edit time relation value is missing so getting the error that's why I add the relation value REF:-https://github.com/odoo/enterprise/blob/16.0/documents/static/src/views/search/documents_search_panel.js#L170 opw:-3518115 Ref video link:- https://www.awesomescreenshot.com/video/21528415?key=0cbe93d602195c3a82f2820bec8a93ce Forward-Port-Of: od
Original PR description
field relation is undefined when the field is available in view while adding a new section at that time set the relation value but while the edit time relation value is missing so getting the error that's why I add the relation value REF:-https://github.com/odoo/enterprise/blob/16.0/documents/static/src/views/search/documents_search_panel.js#L170 opw:-3518115 Ref video link:- https://www.awesomescreenshot.com/video/21528415?key=0cbe93d602195c3a82f2820bec8a93ce Forward-Port-Of: odoo/enterprise#52081 Forward-Port-Of: odoo/enterprise#48839