Monday, October 14, 2024
37 changes · saas-17.4
Enhancements to existing features
Demo cash journals created for different Point of Sale setups are now given clearer names, such as “Cash Restaurant,” so they are easier to identify. They are also removed from default accounting dashboard favorites, reducing clutter for users reviewing accounting information.
Original PR description
Point of Sale installs many demo data shops to offer a demo business as close as possible to the client's needs. Each of these shop has its own cash journal, and all of these journals have the same name. This makes the accounting dashboard hard to read and the database messy. This commit will rename the cash demo journals according to their use: for example the previous "Cash" journal created by the Restaurant POS will now be named "Cash Restaurant". We also removed these journals from favorites journals, so that they are no longer shown by default on the Accounting dashboard task-4200476  
Resolved issues and error corrections
Non-accounting users will no longer see bank and miscellaneous journal setup prompts they cannot use. This keeps dashboards cleaner and avoids confusion by showing configuration actions only to users with the right permissions.
Original PR description
…ountant *: account_reports, account_online_synchronization Configuration steps on empty Bank, Misc journals should not be shown for users that do not have the Administrator/Accountant rights. They don't have the necessary rights to execute those actions anyway. This commit hide the configuration steps for non-accountant users. task-4149584
Miscellaneous changes
This commit hides the unit price of products in the catalog, in case that the catalog was opened from a manufacturing or a repair order. This is because the catalog in this case is used to add a component so the price information is irrelevant. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#182575
Original PR description
This commit hides the unit price of products in the catalog, in case that the catalog was opened from a manufacturing or a repair order. This is because the catalog in this case is used to add a component so the price information is irrelevant. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#182575
Fixed an issue in Marketing Automation where opening an email template in full-screen mode could leave the activity setup window layered on top of it. This prevents accidental closure of the whole activity and makes campaign email editing smoother.
Original PR description
Steps to reproduce: 1. create a marketing campaign 2. Add an Activity 3. Select email as the activity type and create one 4. Select a template and click on full-screen mode in the snippet 5. The activity wizard will overlap the email template 6. Closing it will close the whole activity Technical Reason: When we switch to full screen, the 'o-overlay-item' class has a higher z-index priority. After this commit: The activity wizard will not overlap with the email template. Task-4178640
Shared document links can now preview videos correctly in Chrome. The change keeps the existing protection against loading unrelated content while allowing the video file itself to load from the same Odoo site, avoiding a blocked preview experience for users.
Original PR description
Before, the content_security_policy was set to block all content. That forbids chrome from loading video preview. After this commit we allow media from the same origin. Reproduce --- - -i documents - open video via sharable link from documents - BUG: the preview isn't opening in chrome ``` Refused to load media from 'URL' because it violates the following Content Security Policy directive: "default-src 'none'". Note that 'media-src' was not explicitly set, so 'default-src' is used as a fallback. ``` opw-4192598
The marketing automation template editor now adjusts its content height to fit the dialog properly. This removes an unnecessary extra scrollbar and makes choosing and editing email templates smoother for users.
Original PR description
How to reproduce ----------------- 1. Inside the marketing automation module, enter any campaign. 2. Click on the title of any of the hierarchy card. 3. From the dialog box, type a new name and then select `Create and edit`. 4. In the `Create Marketing Template` dialog box opened, select the `Event Promo` template. 5. Scroll on the outer scroll bar of the dialog box and you will notice the snippets' box height does not extend to the bottom. Issue ----- - The height of the main marketing template is not set, hence an extra scroll bar appears on the dialog box.  Reason ------ - The template comes directly from the `body_arch` field, hence carrying it's own height. Fix --- - We set the `height` to `auto`, so it adjusts according to the dimensions of the dialog box. Task - 4137980
Task: 41734 Odoo-task: 1239 Description of the issue/feature this PR addresses: This task was created to modify the demo data for Argentina, to avoid using real partner information except for their VAT number. Current behavior before PR: Desired behavior after PR is merged: Edit the demo data with fake information except for the VAT number. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#182780 Forward-Port-Of:
Original PR description
Task: 41734 Odoo-task: 1239 Description of the issue/feature this PR addresses: This task was created to modify the demo data for Argentina, to avoid using real partner information except for their VAT number. Current behavior before PR: Desired behavior after PR is merged: Edit the demo data with fake information except for the VAT number. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#182780 Forward-Port-Of: odoo/odoo#175390
On mobile, whwen a domain is selected in the SearchPanel, there is a red dot that indicates there is a domain applied. This red dot is useless because we actually see that the domain is selected. This commit removes it. task-4246980 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#183136
Original PR description
On mobile, whwen a domain is selected in the SearchPanel, there is a red dot that indicates there is a domain applied. This red dot is useless because we actually see that the domain is selected. This commit removes it. task-4246980 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#183136
## Pull Request HOOT (PRHOOT) - part 25 Part 1: https://github.com/odoo/odoo/pull/152930 Part 2: https://github.com/odoo/odoo/pull/153018 Part 3: https://github.com/odoo/odoo/pull/153023 Part 4: https://github.com/odoo/odoo/pull/153203 Part 5: https://github.com/odoo/odoo/pull/153425 Part 6: https://github.com/odoo/odoo/pull/153700 Part 7: https://github.com/odoo/odoo/pull/154054 Part 8: https://github.com/odoo/odoo/pull/154579 Part 9: https://github.com/odoo/odoo/pull/155073 Part 10
Original PR description
## Pull Request HOOT (PRHOOT) - part 25 Part 1: https://github.com/odoo/odoo/pull/152930 Part 2: https://github.com/odoo/odoo/pull/153018 Part 3: https://github.com/odoo/odoo/pull/153023 Part 4:…
## Pull Request HOOT (PRHOOT) - part 25 Part 1: https://github.com/odoo/odoo/pull/152930 Part 2: https://github.com/odoo/odoo/pull/153018 Part 3: https://github.com/odoo/odoo/pull/153023 Part 4: https://github.com/odoo/odoo/pull/153203 Part 5: https://github.com/odoo/odoo/pull/153425 Part 6: https://github.com/odoo/odoo/pull/153700 Part 7: https://github.com/odoo/odoo/pull/154054 Part 8: https://github.com/odoo/odoo/pull/154579 Part 9: https://github.com/odoo/odoo/pull/155073 Part 10: https://github.com/odoo/odoo/pull/155639 Part 11: https://github.com/odoo/odoo/pull/156255 / https://github.com/odoo/enterprise/pull/58135 Part 12: https://github.com/odoo/odoo/pull/156869 Part 13: https://github.com/odoo/odoo/pull/158384 / https://github.com/odoo/enterprise/pull/59019 Part 14: https://github.com/odoo/odoo/pull/158916 Part 15: https://github.com/odoo/odoo/pull/160292 / https://github.com/odoo/enterprise/pull/59971 Part 15.5: https://github.com/odoo/odoo/pull/166463 Part 16: https://github.com/odoo/odoo/pull/166311 Part 17: https://github.com/odoo/odoo/pull/168328 Part 18: https://github.com/odoo/odoo/pull/171004 / https://github.com/odoo/enterprise/pull/65657 Part 19: https://github.com/odoo/odoo/pull/171242 / https://github.com/odoo/enterprise/pull/65767 Part 20: https://github.com/odoo/odoo/pull/173332 / https://github.com/odoo/enterprise/pull/66895 Part 21: https://github.com/odoo/odoo/pull/174337 Part 22: https://github.com/odoo/odoo/pull/176777 / https://github.com/odoo/enterprise/pull/68721 Part 23: https://github.com/odoo/odoo/pull/179660 / https://github.com/odoo/enterprise/pull/69728 Part 24: https://github.com/odoo/odoo/pull/181971 This pull requests brings various improvements and fixes to Hoot and the Odoo unit test ecosystem. See the different commit messages for more details. Note: these changes are made in stable to avoid having to support multiple versions of the HOOT API. As such, these changes are intended to be strictly limited to unit tests as to not put the rest of the code base at risk. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#183358
Versions -------- - saas-17.2+ Steps ----- 1. Go to eCommerce; 2. go to a product page with variants; 3. open editor; 4. drag & drop a "Products" block from Dynamic Content; 5. click on the newly added block; 6. set filter to "Recently Viewed Products"; 7. save; 8. change an attribute of the current product; 9. use the added carousel to go back to the previous variant. >[!Important] > For products to register as "recently viewed," you need to wait a few seconds on their eComme
Original PR description
Versions -------- - saas-17.2+ Steps ----- 1. Go to eCommerce; 2. go to a product page with variants; 3. open editor; 4. drag & drop a "Products" block from Dynamic Content; 5. click on the newly…
Versions -------- - saas-17.2+ Steps ----- 1. Go to eCommerce; 2. go to a product page with variants; 3. open editor; 4. drag & drop a "Products" block from Dynamic Content; 5. click on the newly added block; 6. set filter to "Recently Viewed Products"; 7. save; 8. change an attribute of the current product; 9. use the added carousel to go back to the previous variant. >[!Important] > For products to register as "recently viewed," you need to wait a few seconds on their eCommerce page. Issue ----- Nothing happens. Cause ----- Commit 016a72bae9c3 changed the event listener on website_sale from `hashchange` to `popevent` with a check on the event's `state?.newURL` attribute. Issue is that this will always be `undefined`, as there's no logic in place to push or replace states[^1] when viewing products. Solution -------- Revert the change, and have the listener trigger on `hashchange` events[^2] again. > [!Note] > In the future we could consider moving away from using the URL hash property[^3] for storing product attribute ids to a more conventional practice, as was intended by the commit that made this change. opw-4150284 [^1]: https://developer.mozilla.org/en-US/docs/Web/API/PopStateEvent/state [^2]: https://developer.mozilla.org/en-US/docs/Web/API/Window/hashchange_event [^3]: https://developer.mozilla.org/en-US/docs/Web/API/URL/hash Forward-Port-Of: odoo/odoo#183210
When installing Event via the Apps menu, you actually install website_event (and therefore Website). This means that the next action the user has to take is installing a theme. In the case of a demo setup, the cron for the mail scheduler of Event will launch immediately post-install and will run for a rather long time, preventing any other module from installing (because module installations are blocked whilst a cron is running). This means that after installing the Website event in a d
Original PR description
When installing Event via the Apps menu, you actually install website_event (and therefore Website). This means that the next action the user has to take is installing a theme. In the case of a demo setup, the cron for the mail scheduler of Event will launch immediately post-install and will run for a rather long time, preventing any other module from installing (because module installations are blocked whilst a cron is running). This means that after installing the Website event in a demo setup, the user is the prevented from finishing the website setup until the cron is finished. This commit introduces a 'grace period' of 15min until the cron first runs, making it possible to finish the website setup right away. Forward-Port-Of: odoo/odoo#182488
## Description of the issue/feature this PR addresses: Prior to this commit, the health route is responding with a 200 status even when the database server is down or unreachable. In deployment scenario (CI/CD), this route (/web/health) is (can be) used in order to get the deployement state. This is actually the only one that can be used in order to check it without an active session or credentials or master password. Including the optional db_server_status arg will allow integrating th
Original PR description
## Description of the issue/feature this PR addresses: Prior to this commit, the health route is responding with a 200 status even when the database server is down or unreachable. In deployment…
## Description of the issue/feature this PR addresses: Prior to this commit, the health route is responding with a 200 status even when the database server is down or unreachable. In deployment scenario (CI/CD), this route (/web/health) is (can be) used in order to get the deployement state. This is actually the only one that can be used in order to check it without an active session or credentials or master password. Including the optional db_server_status arg will allow integrating the postgresql server state without breaking any eventual existing overrides. ## Current behavior before PR: When the postgresql database is not up / not reachable the route is returning a 200 code. ## Desired behavior after PR is merged: When the postgresql database is not up / not reachable the route is returning a 500 code. As we are in stable, an optional argument has been added to the route in order not to break any potential existing overrides. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#182840 Forward-Port-Of: odoo/odoo#182537
Description of the issue/feature this PR addresses: sys.settrace prevents coverage.py from working properly: https://coverage.readthedocs.io/en/7.5.3/trouble.html The main cause of the problem is that when executing the SyncCollector profiler we will settrace(None). This makes the coverage result invalid since the settrace added by the coverage is not resumed. Also, it would be possible to have a similar problem with nested SyncCollector, or if any other tool/code uses sys.settrace.
Original PR description
Description of the issue/feature this PR addresses: sys.settrace prevents coverage.py from working properly: https://coverage.readthedocs.io/en/7.5.3/trouble.html The main cause of the problem is that when executing the SyncCollector profiler we will settrace(None). This makes the coverage result invalid since the settrace added by the coverage is not resumed. Also, it would be possible to have a similar problem with nested SyncCollector, or if any other tool/code uses sys.settrace. So, an error is logged when the profiler starts. Current behavior before PR: The coverage.py report doesn't correctly track which tests have been run. Desired behavior after PR is merged: coverage.py will report all the correct tests. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#167379
In the Calendar app with the Arabic language, there is no AM/PM distinction or 24-hour clock option. Users can only select a time between 1 and 12 without the ability to specify AM or PM. This issue is caused by the missing %p placeholder in the Arabic record of the res.lang.csv file. OPW-4182242 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#180858
Original PR description
In the Calendar app with the Arabic language, there is no AM/PM distinction or 24-hour clock option. Users can only select a time between 1 and 12 without the ability to specify AM or PM. This issue is caused by the missing %p placeholder in the Arabic record of the res.lang.csv file. OPW-4182242 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#180858
## Description After importing a large quantity of pending bills with no `invoice_date`, the dashboard can be significantly slow. The bottleneck comes primarily from the hot loop in `_count_results_and_sum_amounts`, as it's iterating over a potentially enormous list of dictionary of query results. This patch improvement consists mostly of hoisting invariants out of this hot loop, most impactful is the call to `context_today`, which does a lot of computation/conversions to apply the proper tim
Original PR description
## Description After importing a large quantity of pending bills with no `invoice_date`, the dashboard can be significantly slow. The bottleneck comes primarily from the hot loop in…
## Description After importing a large quantity of pending bills with no `invoice_date`, the dashboard can be significantly slow. The bottleneck comes primarily from the hot loop in `_count_results_and_sum_amounts`, as it's iterating over a potentially enormous list of dictionary of query results. This patch improvement consists mostly of hoisting invariants out of this hot loop, most impactful is the call to `context_today`, which does a lot of computation/conversions to apply the proper timezone and localize the date. ## Benchmark | len(results_dict) | Before | After | Speedup | |-------------------|--------|-------|---------| | Timings (10k) | 250ms | 50ms | 5x | | Timings (50k) | 1.2s | 300ms | 4x | | Timings (100k) | 2.7s | 820ms | 3.3x | | Timings (250k) | 6.7s | 1.7s | 3.9x | | Timings (~600k) | 13s | 4s | 3.25x | ## Reference opw-4235252 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#183342
Task: 4228916 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#183056 Forward-Port-Of: odoo/odoo#182595
Original PR description
Task: 4228916 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#183056 Forward-Port-Of: odoo/odoo#182595
Description this PR addresses: Fixes #181899: Prevents data loss when migrating attachments from DB to filestore by adding a writable permission check before migration. Current behavior before PR: Migration to filestore proceeds even if the target directory is not writable, resulting in data loss. Desired behavior after PR is merged: Writable permissions are checked before migration. If the target directory is not writable, an exception will be raised --- I confirm I have signed
Original PR description
Description this PR addresses: Fixes #181899: Prevents data loss when migrating attachments from DB to filestore by adding a writable permission check before migration. Current behavior before PR: Migration to filestore proceeds even if the target directory is not writable, resulting in data loss. Desired behavior after PR is merged: Writable permissions are checked before migration. If the target directory is not writable, an exception will be raised --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#181998
Since [1], the ".o_default_text_snippet" class has not been correctly removed when text is modified within a content-editable element. This commit resolves the issue. Steps to reproduce: - Drag and drop the "Pricelist block" into the page. - Click on the snippet newly inserted to display the options on the right panel. - Enable the "Descriptions" option under the Pricelist block options to display descriptions. - Edit some descriptions directly in the snippet. - Disable and re-
Original PR description
Since [1], the ".o_default_text_snippet" class has not been correctly removed when text is modified within a content-editable element. This commit resolves the issue. Steps to reproduce: - Drag and drop the "Pricelist block" into the page. - Click on the snippet newly inserted to display the options on the right panel. - Enable the "Descriptions" option under the Pricelist block options to display descriptions. - Edit some descriptions directly in the snippet. - Disable and re-enable the "Descriptions" option. - Bug: The edited descriptions are replaced by the default text. [1]: https://github.com/odoo/odoo/commit/03c552690b15cbf2e7d6b7812386ac64042219af#diff-52a4f9d2c217548e69e6b7fd097f286f1754a6389734eea254b87255e501cbef task-4084956 task-4147162 (first part) Forward-Port-Of: odoo/odoo#177588
Steps to reproduce the error 1.create a db in odoo 15.0 install hr_holiday and l10n_be_hr_payroll 2.create a leave with existing leave type from l10n_be_hr_payroll module 3.upgrade db to 16.0 the below mentioned traceback will raise traceback ```py Traceback (most recent call last): File "/home/odoo/src/odoo/16.0/odoo/tools/convert.py", line 698, in _tag_root f(rec) File "/home/odoo/src/odoo/16.0/odoo/tools/convert.py", line 599, in _tag_record record = model._load_recor
Original PR description
Steps to reproduce the error 1.create a db in odoo 15.0 install hr_holiday and l10n_be_hr_payroll 2.create a leave with existing leave type from l10n_be_hr_payroll module 3.upgrade db to 16.0 the…
Steps to reproduce the error
1.create a db in odoo 15.0 install hr_holiday and l10n_be_hr_payroll
2.create a leave with existing leave type from l10n_be_hr_payroll module
3.upgrade db to 16.0 the below mentioned traceback will raise
traceback
```py
Traceback (most recent call last):
File "/home/odoo/src/odoo/16.0/odoo/tools/convert.py", line 698, in _tag_root
f(rec)
File "/home/odoo/src/odoo/16.0/odoo/tools/convert.py", line 599, in _tag_record
record = model._load_records([data], self.mode == 'update')
File "/home/odoo/src/odoo/16.0/odoo/models.py", line 4393, in _load_records
data['record']._load_records_write(data['values'])
File "/home/odoo/src/odoo/16.0/odoo/models.py", line 4324, in _load_records_write
self.write(values)
File "/home/odoo/src/odoo/16.0/odoo/models.py", line 3806, in write
real_recs._validate_fields(vals, inverse_fields)
File "/home/odoo/src/odoo/16.0/odoo/models.py", line 1365, in _validate_fields
check(self)
File "/home/odoo/src/odoo/16.0/addons/hr_holidays/models/hr_leave_type.py", line 188, in check_allocation_requirement_edit_validity
raise UserError(_("The allocation requirement of a time off type cannot be changed once leaves of that type have been taken. You should create a new time off type instead."))
odoo.exceptions.UserError: The allocation requirement of a time off type cannot be changed once leaves of that type have been taken. You should create a new time off type instead.
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
File "/home/odoo/src/odoo/16.0/odoo/service/server.py", line 1310, in preload_registries
registry = Registry.new(dbname, update_module=update_module)
File "<decorator-gen-16>", line 2, in new
File "/home/odoo/src/odoo/16.0/odoo/tools/func.py", line 87, in locked
return func(inst, *args, **kwargs)
File "/home/odoo/src/odoo/16.0/odoo/modules/registry.py", line 91, in new
odoo.modules.load_modules(registry, force_demo, status, update_module)
File "/home/odoo/src/odoo/16.0/odoo/modules/loading.py", line 484, in load_modules
processed_modules += load_marked_modules(cr, graph,
File "/home/odoo/src/odoo/16.0/odoo/modules/loading.py", line 372, in load_marked_modules
loaded, processed = load_module_graph(
File "/home/odoo/src/odoo/16.0/odoo/modules/loading.py", line 231, in load_module_graph
load_data(cr, idref, mode, kind='data', package=package)
File "/home/odoo/src/odoo/16.0/odoo/modules/loading.py", line 71, in load_data
tools.convert_file(cr, package.name, filename, idref, mode, noupdate, kind)
File "/home/odoo/src/odoo/16.0/odoo/tools/convert.py", line 763, in convert_file
convert_xml_import(cr, module, fp, idref, mode, noupdate)
File "/home/odoo/src/odoo/16.0/odoo/tools/convert.py", line 829, in convert_xml_import
obj.parse(doc.getroot())
File "/home/odoo/src/odoo/16.0/odoo/tools/convert.py", line 749, in parse
self._tag_root(de)
File "/home/odoo/src/odoo/16.0/odoo/tools/convert.py", line 711, in _tag_root
raise ParseError('while parsing %s:%s, somewhere inside\n%s' % (
odoo.tools.convert.ParseError: while parsing /home/odoo/src/enterprise/16.0/l10n_be_hr_payroll/data/hr_leave_type_data.xml:14, somewhere inside
<record id="holiday_type_maternity" model="hr.leave.type">
<field name="name">Maternity Time Off</field>
<field name="requires_allocation">no</field>
<field name="leave_validation_type">no_validation</field>
<field name="request_unit">half_day</field>
<field name="color_name">lavender</field>
<field name="leave_notif_subtype_id" ref="hr_holidays.mt_leave"/>
<field name="work_entry_type_id" ref="work_entry_type_maternity"/>
<field name="icon_id" ref="hr_holidays.icon_11"/>
<field name="company_id" eval="False"/>
</record>
```
why this traceback is raised because while loading ``l10n_be_hr_payroll`` moduel this data file will load during that if record is noupdate false then it will go for write call so in that requires_allocation will also go for write call even the value is same. So, the newly introduced [``constraints``](https://github.com/odoo/odoo/commit/33da34b842f2fe700efaf55915d4cb9828e139d7) will trigger and check if any record
of leave is present with the that leavetype constraint will trigger .For fixing this issue pop the value of ``requires_allocation`` if the values are same otherwise record is modified by user.
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#182533To reproduce the issue: (Need website_sale) 1. Set up a website shop for ES company - With demo payment method 2. In Settings: - Website > Automatic Invoice: enabled 3. With a portal user, add a product to the cart 4. Open the cart 5. Pay with Demo Error: The client is redirected to a page "Internal server error: The partner needs a set tax identification number or VAT number" When post-processing the payment, and because of step 2, it leads to https://github.com/odoo/odoo/
Original PR description
To reproduce the issue: (Need website_sale) 1. Set up a website shop for ES company - With demo payment method 2. In Settings: - Website > Automatic Invoice: enabled 3. With a portal user, add a…
To reproduce the issue: (Need website_sale) 1. Set up a website shop for ES company - With demo payment method 2. In Settings: - Website > Automatic Invoice: enabled 3. With a portal user, add a product to the cart 4. Open the cart 5. Pay with Demo Error: The client is redirected to a page "Internal server error: The partner needs a set tax identification number or VAT number" When post-processing the payment, and because of step 2, it leads to https://github.com/odoo/odoo/blob/20365bcab548c4a2d93194c8c2b8b2577d14d3ce/addons/l10n_es_edi_facturae/wizard/account_move_send.py#L86-L88 Where we will generate the data for the Facturae XML. There, we check few things, like the vat number of the partner: https://github.com/odoo/odoo/blob/e157cb2d8640fac1365beb135763cb25cff554f5/addons/l10n_es_edi_facturae/models/account_move.py#L312-L313 And since the portal user does not have any vat number, the error is raised. The Facturae feature should only be enabled for B2B flows OPW-4121724 Forward-Port-Of: odoo/odoo#181653
Steps to reproduce: - Project > Pick any task > Debug Mode - Studio > View tab > Tick 'Show invisible elements' - Scroll to 'Sales Order' and click it - Untick 'Invisible' then tick and untick readonly - Close > you should have a Sales Order field on the task - Click to change it's value An error occurs because the 'commercial_partner_id' field was removed from task in 17.0 in dcbdb6e690f29bc5327d7067688c93071d9a6b2d. Because of this the domain which filters 'Sales Order' (which contain
Original PR description
Steps to reproduce: - Project > Pick any task > Debug Mode - Studio > View tab > Tick 'Show invisible elements' - Scroll to 'Sales Order' and click it - Untick 'Invisible' then tick and untick readonly - Close > you should have a Sales Order field on the task - Click to change it's value An error occurs because the 'commercial_partner_id' field was removed from task in 17.0 in dcbdb6e690f29bc5327d7067688c93071d9a6b2d. Because of this the domain which filters 'Sales Order' (which contains this field) cannot be evaluated. Since the field is still available on the sale_order model, we can simply invert the child_of relation: from sale_order.partner_id child_of task.commercial_partner_id to sale_order.commercial_partner_id parent_of task.partner_id Which should serve essentially the same purpose. opw-4199947 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#182945
Steps to reproduce ====================== Go to the user profile. Click on tags. You will be redirected to the courses instead of redirecting to the tags. Technical ========== Click event is there on the whole card as our tags are inside the card so the click event of a parent is triggering instead of the child. and we are redirected to the course page. After this PR =========== We will be redirected to tags when clicking on tag. Task-4203676 Forward-Port-Of: odoo/odoo#183079 F
Original PR description
Steps to reproduce ====================== Go to the user profile. Click on tags. You will be redirected to the courses instead of redirecting to the tags. Technical ========== Click event is there on the whole card as our tags are inside the card so the click event of a parent is triggering instead of the child. and we are redirected to the course page. After this PR =========== We will be redirected to tags when clicking on tag. Task-4203676 Forward-Port-Of: odoo/odoo#183079 Forward-Port-Of: odoo/odoo#181499
Currently, when using any browser on an Ipad, qr codes will not be shown on the printed receipt, when printed for the first time. When printing it a second time, it will appear. Steps to reproduce: ------------------- * Use an Ipad (or simulate one) * Go to the **Point of sale** App * Select **Configuration** > **Settings** * Enable QR code on receipt * Open shop session * Make an order and pay it * Print the receipt > Observation: QR code does not appear, big white space where it sh
Original PR description
Currently, when using any browser on an Ipad, qr codes will not be shown on the printed receipt, when printed for the first time. When printing it a second time, it will appear. Steps to reproduce:…
Currently, when using any browser on an Ipad, qr codes will not be shown on the printed receipt, when printed for the first time. When printing it a second time, it will appear.
Steps to reproduce:
-------------------
* Use an Ipad (or simulate one)
* Go to the **Point of sale** App
* Select **Configuration** > **Settings**
* Enable QR code on receipt
* Open shop session
* Make an order and pay it
* Print the receipt
> Observation: QR code does not appear, big white space where it should be
* Print it again
> Observation: QR code is printed
Why the fix:
------------
```js
function createImage(url) {
return new Promise((resolve, reject) => {
const img = new Image();
img.onload = () => resolve(img);
img.decode = () => resolve(img);
img.onerror = reject;
img.crossOrigin = "anonymous";
img.decoding = "async";
img.src = url;
});
}
```
In this piece of code, `img.decode = () => resolve(img);` is supposed to ensure that the image is fully processed but is misused. Decode is not a setter, it's a method that returns a promise when the image is fully decoded. While this code wait for the image to load it does not wait for it to be fully ready (processed).
`img.decode()` ensures that the image has been fully decoded before continuing.
We go one step further with `requestAnimationFrame`. This defers the execution and will ensure that the resolved image is rendered in the next frame. It's more important in devices like Ipad because the broswers tend to handle image operations differently, thus creating rendering and timing issues.
With this fix, we now wait longer to make sure that the image is not only loaded but also fully processed and ready to be shown.
opw-4144049
Forward-Port-Of: odoo/odoo#182803In the new IoT image we use Chromium instead of Firefox, however it comes bundled with some extensions, namely uBlock, which use up disk space in the background. This leads to the `/tmp` directory getting full, which causes various errors and instability. After this change, the `/tmp` directory only reaches around 50% capacity, even after many restarts and webpage visits. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/
Original PR description
In the new IoT image we use Chromium instead of Firefox, however it comes bundled with some extensions, namely uBlock, which use up disk space in the background. This leads to the `/tmp` directory getting full, which causes various errors and instability. After this change, the `/tmp` directory only reaches around 50% capacity, even after many restarts and webpage visits. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#182953 Forward-Port-Of: odoo/odoo#182883
The DisplayDriver class uses the `xdotool` command to send keypresses to the browser. However for Chromium, it is using the wrong process name causing the keystrokes not to be received. The symptom of this is the Pairing Code does not disappear after 5 minutes as intended, leaving an invalid code on the screen. This PR fixes the issue by using the correct process name for Chromium. Related PR for 18.0+: https://github.com/odoo/odoo/pull/180286 --- I confirm I have signed the CL
Original PR description
The DisplayDriver class uses the `xdotool` command to send keypresses to the browser. However for Chromium, it is using the wrong process name causing the keystrokes not to be received. The symptom of this is the Pairing Code does not disappear after 5 minutes as intended, leaving an invalid code on the screen. This PR fixes the issue by using the correct process name for Chromium. Related PR for 18.0+: https://github.com/odoo/odoo/pull/180286 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#182745
When automatic entries are generated, a sequence number should not be assigned on them as long as they are on draft state. This is done because it may be confusing to see a sequenced name for a move in draft. This commit ensures that the name of the entries is 'Draft' (or '/') when the move is generated. A sequence number will be assigned once the move is posted. Before this commit, it was possible to generate a draft move with a sequence number when doing an automatic transfer in the future or
Original PR description
When automatic entries are generated, a sequence number should not be assigned on them as long as they are on draft state. This is done because it may be confusing to see a sequenced name for a move in draft. This commit ensures that the name of the entries is 'Draft' (or '/') when the move is generated. A sequence number will be assigned once the move is posted. Before this commit, it was possible to generate a draft move with a sequence number when doing an automatic transfer in the future or with accrued orders. task-4069862 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#181779
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#182667
Original PR description
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#182667
The active flag [can be included](https://github.com/odoo/odoo/blob/17.0/addons/mrp/models/stock_warehouse.py#L259-L277) in the values to update when calling function `_create_or_update_sequences_and_picking_types`, for example [during upgrades](https://github.com/odoo/upgrade/blob/master/migrations/stock/saas~17.3.1.1/end-migrate.py#L16). This will raise the Validation Error even if the flag is being kept as active. upg-2034998 Forward-Port-Of: odoo/odoo#180292
Original PR description
The active flag [can be included](https://github.com/odoo/odoo/blob/17.0/addons/mrp/models/stock_warehouse.py#L259-L277) in the values to update when calling function `_create_or_update_sequences_and_picking_types`, for example [during upgrades](https://github.com/odoo/upgrade/blob/master/migrations/stock/saas~17.3.1.1/end-migrate.py#L16). This will raise the Validation Error even if the flag is being kept as active. upg-2034998 Forward-Port-Of: odoo/odoo#180292
This task was created to modify the demo data for Argentina, to avoid using real partner information. latam-task-1239 adhoc-task-41734 Forward-Port-Of: odoo/enterprise#71471 Forward-Port-Of: odoo/enterprise#71230
Original PR description
This task was created to modify the demo data for Argentina, to avoid using real partner information. latam-task-1239 adhoc-task-41734 Forward-Port-Of: odoo/enterprise#71471 Forward-Port-Of: odoo/enterprise#71230
The definition of these records include the field `requires_allocation`, so updating them will trigger the constraint for that field. There's already a [fix for this](https://github.com/odoo/odoo/pull/182533) but it will be interesting to still mark these records as noupdate to be coherent with all the other `hr.leave.type` records. To reproduce: - Install `l10n_hk_hr_payroll` with demo data - Upgrade the module Forward-Port-Of: odoo/enterprise#71844
Original PR description
The definition of these records include the field `requires_allocation`, so updating them will trigger the constraint for that field. There's already a [fix for this](https://github.com/odoo/odoo/pull/182533) but it will be interesting to still mark these records as noupdate to be coherent with all the other `hr.leave.type` records. To reproduce: - Install `l10n_hk_hr_payroll` with demo data - Upgrade the module Forward-Port-Of: odoo/enterprise#71844
Steps to reproduce: - open a first tab - create a new spreadsheet - open a second tab - from that new tab, delete the spreadsheet (send to trash, then permanently delete it from the trash) - create a new spreadsheet => update a few cells, the websocket connection is broken. Task: 4252590 Forward-Port-Of: odoo/enterprise#71802
Original PR description
Steps to reproduce: - open a first tab - create a new spreadsheet - open a second tab - from that new tab, delete the spreadsheet (send to trash, then permanently delete it from the trash) - create a new spreadsheet => update a few cells, the websocket connection is broken. Task: 4252590 Forward-Port-Of: odoo/enterprise#71802
Before this commit the following error was observed: File "/data/build/enterprise/test_sale_subscription/tests/test_subscription_payment_integration.py", line 112, in test_subscription_invoice_automate self.assertInvoicePaid(self.invoice) File "/data/build/enterprise/test_sale_subscription/tests/test_subscription_payment_integration.py", line 66, in assertInvoicePaid self.assertEqual(invoice.amount_paid, invoice.amount_total, "Amount should match") AssertionError: 1206.3700000
Original PR description
Before this commit the following error was observed:
File "/data/build/enterprise/test_sale_subscription/tests/test_subscription_payment_integration.py", line 112, in test_subscription_invoice_automate
self.assertInvoicePaid(self.invoice)
File "/data/build/enterprise/test_sale_subscription/tests/test_subscription_payment_integration.py", line 66, in assertInvoicePaid
self.assertEqual(invoice.amount_paid, invoice.amount_total, "Amount should match")
AssertionError: 1206.3700000000001 != 1206.37 : Amount should match
Runbot errors: 100947, 100946, 100945, 100944, 100944
Forward-Port-Of: odoo/enterprise#71843### [FIX] account_report: fix indentation in xlsx export Currently the indentation of XLSX export of reports was sometimes broken. The current implementation only supported up to three levels of indentation in the export as well. This fix supports a virtually infinite number of indentation levels and fixes the indentation in the XLSX exports. ### [I18N] account_reports: update terms ### [IMP] account_reports: move account code column to the right in xlsx Currently, when exporting an a
Original PR description
### [FIX] account_report: fix indentation in xlsx export Currently the indentation of XLSX export of reports was sometimes broken. The current implementation only supported up to three levels of indentation in the export as well. This fix supports a virtually infinite number of indentation levels and fixes the indentation in the XLSX exports. ### [I18N] account_reports: update terms ### [IMP] account_reports: move account code column to the right in xlsx Currently, when exporting an accounting report as XLSX file, we add a column for the account codes on the very left of the sheet. This looks a bit weird and is not the most important information to have as a first column. In this commit, we move the column to the right so the name of the line will be first, followed by the account code (if applicable). We also add a column name for the account codes. task-3986483 Forward-Port-Of: odoo/enterprise#71486 Forward-Port-Of: odoo/enterprise#67111
Steps to reproduce: - Insert a pivot view of timesheet - Insert a list view of project - Add a new global filter based on project => you actually cannot select id for the list view of project, but we should be able to filter the list view based on the project id. This commit adds the id field to the allowed fields for the relation global filters. Task: 4228916 Forward-Port-Of: odoo/enterprise#71612 Forward-Port-Of: odoo/enterprise#71365
Original PR description
Steps to reproduce: - Insert a pivot view of timesheet - Insert a list view of project - Add a new global filter based on project => you actually cannot select id for the list view of project, but we should be able to filter the list view based on the project id. This commit adds the id field to the allowed fields for the relation global filters. Task: 4228916 Forward-Port-Of: odoo/enterprise#71612 Forward-Port-Of: odoo/enterprise#71365
The end date on the Holiday Attest (N-1) was wrong. It should be the same as the end of the notice period. Forward-Port-Of: odoo/enterprise#71642
Original PR description
The end date on the Holiday Attest (N-1) was wrong. It should be the same as the end of the notice period. Forward-Port-Of: odoo/enterprise#71642
When automatic entries are generated, a sequence number should not be assigned on them as long as they are on draft state. This is done because it may be confusing to see a sequence name for a move in draft. This commit ensures that the name of the entries is 'Draft' (or '/') when the move is generated. A sequence number will be assigned once the move is posted. Before this commit, it was possible to generate a draft move with a sequence number when doing a deferred entries with some entries in
Original PR description
When automatic entries are generated, a sequence number should not be assigned on them as long as they are on draft state. This is done because it may be confusing to see a sequence name for a move in draft. This commit ensures that the name of the entries is 'Draft' (or '/') when the move is generated. A sequence number will be assigned once the move is posted. Before this commit, it was possible to generate a draft move with a sequence number when doing a deferred entries with some entries in the future. task-4069862 Forward-Port-Of: odoo/enterprise#70855
1. Enable "auto-detect" on the Avatax fiscal position, 2. Go to "Abigail Peterson" contact and set "United States" as country 3. Expenses > My Expenses > New 4. Enter a description, set a total and "Abigail Peterson" as employee 5. "Create Report" > "Submit to Manager" > "Approve" > "Post Journal Entries" Issue: Validation error will raise because of the incomplete address However we only handle customer invoices and customer invoice refunds (aka credit notes) with external tax integr
Original PR description
1. Enable "auto-detect" on the Avatax fiscal position, 2. Go to "Abigail Peterson" contact and set "United States" as country 3. Expenses > My Expenses > New 4. Enter a description, set a total and "Abigail Peterson" as employee 5. "Create Report" > "Submit to Manager" > "Approve" > "Post Journal Entries" Issue: Validation error will raise because of the incomplete address However we only handle customer invoices and customer invoice refunds (aka credit notes) with external tax integrations so the constraint should only show for journal entries of this type. opw-4151193 Forward-Port-Of: odoo/enterprise#71747 Forward-Port-Of: odoo/enterprise#71543