Wednesday, May 3, 2023
72 changes · master
New functionality added to Odoo
This adds a self-ordering experience for restaurants and point-of-sale users, including QR menu and ordering flows. Businesses can let customers browse and place orders more independently, reducing staff workload and improving service speed.
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
Enhancements to existing features
Users can now hide the “Add a Property” button in property fields, freeing up space on forms once properties are set up. The button can still be made available through an action when needed, and related usability fixes make the property editing experience smoother.
Original PR description
Purpose ======= When this option is enabled, the button to create new properties is invisible. We create a client action instead, and when the user executes client action for the first time, the button becomes visible until the user refreshes the page. This is useful because most of the time, the user will create the properties and then won't change them. So this button uses space unnecessarily in the form view (for the most of the use cases). Task-3188915
Resolved issues and error corrections
This fixes a crash that could occur when a message was shown without an associated conversation thread. The change makes the mail interface more reliable in edge cases, reducing interruptions for users.
Original PR description
Before this PR, using the message component wihtout a thread could crash because props.thread could be undefined (as thread is an optional props). This PR just add the guard.
Code cleanup and technical improvements
This internal refactoring makes JavaScript module dependencies explicit instead of being automatically detected. It simplifies the platform's web asset handling and should make future maintenance more reliable, with no intended change for end users.
Original PR description
This commit makes the `dependencies` param of `odoo.define` mandatory. It was optional and when omitted, a regexp read the function to find the dependencies. We can simplify it now almost all js modules have been converted to esm. The transpiler already adds the param for the es modules except if the module has an alias. task id: 3271352 enterprise PR: https://github.com/odoo/enterprise/pull/40040
Miscellaneous changes
This commit updates the documentation URLs to the current URLs, although there are already redirect rules in place as a fallback. Related odoo/documentation pull requests: Calendar: https://github.com/odoo/documentation/pull/4032 task-3217827 POS https://github.com/odoo/documentation/pull/4226 task-3284514 Inventory https://github.com/odoo/documentation/pull/2556 Forward-Port-Of: odoo/odoo#120300 Forward-Port-Of: odoo/odoo#119824
Original PR description
This commit updates the documentation URLs to the current URLs, although there are already redirect rules in place as a fallback. Related odoo/documentation pull requests: Calendar: https://github.com/odoo/documentation/pull/4032 task-3217827 POS https://github.com/odoo/documentation/pull/4226 task-3284514 Inventory https://github.com/odoo/documentation/pull/2556 Forward-Port-Of: odoo/odoo#120300 Forward-Port-Of: odoo/odoo#119824
Invoice onboarding now includes a step to configure Stripe payments, helping businesses get paid online more easily during initial setup. When onboarding is completed in related apps, the system can recognize that progress across apps to reduce repeated setup work, with special handling for Sales.
Original PR description
To improve onboarding experience, configuring Stripe has been added in Invoice onboarding process. For db with other apps(ecommerce or sales) if onboarding is done in one place it is considered done in other places with exclusion of Sales, unless it was done in Sales. task-3208045 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 Gantt view now shows an empty row for the current user when there are no visible scheduled tasks. This makes it easier for users to create or schedule their own tasks without browsing through all users, keeping the view focused and performant.
Original PR description
Ease the creation/scheduling of tasks when the Gantt view is empty. Indeed, by default, only the 'unassigned tasks' line is visible, which feels unnatural to use when tasks are already assigned to some users, and you simply want to plan them. As we can't display all users without distinction for performance (and navigation) issues, we are displaying an empty line for the current user instead. task-3254242
Kitchen printer functionality has been moved into the main Point of Sale app, so it can be used beyond restaurant setups. Epson printer support is also consolidated, simplifying setup and reducing duplicated printer-specific modules.
Original PR description
*:pos_epson_printer,pos_epson_printer_restaurant,point_of_sale,pos_restaurant,pos_hr_restaurant Before the printers only worked in the `pos_restaurant` and not in the `point_of_sale`. Indeed, the methods managing the printers were located in the `pos_restaurant`. Now all these methods have been moved. For the community part here are the affected modules: - The methods in `pos_epson_printer_restaurant` have been moved to `pos_epson_printer`. - The methods in `pos_restaurant` have been moved to `point_of_sale`. - The module `pos_epson_printer_restaurant` has been removed as it only handled printers. Some of these methods have been adapted/renamed to better suit the needs. This branch the first part of the following task: 3224508 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
HR users can now approve, validate, or refuse employee time off requests directly from the calendar dashboard. This reduces the number of steps needed to manage leave requests and helps HR teams act faster.
Original PR description
Purpose: HR can view employee leave records from the calendar but can not approve, validate or refuse it from there. In case they want to make action, they have to go through menu < time off < approvals < time off < find the employee < find the requested time off < open it < approve. In this commit the action buttons are added on the dashboard. task - 3175495
Calendar events can now only be edited from the calendar view by people who are attending the event. This prevents users from accidentally or intentionally changing other employees' events, such as time-off entries, improving control over shared calendar data.
Original PR description
This task change the people who can edit a calendar event. This calendar event currently allow every user to modify every event in the calendar. This cause issue where one user can modify the time-off event for other employees. This PR change the right to modify an event from the calendar view in the calendar app. With these changes, only the people attending an event will be able to modify it from the calendar view. task-id : 3185743 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Payment providers now have a cleaner way to control when required currencies are shown, reducing the need to customize shared payment screens. This helps AsiaPay and future payment integrations adapt their settings with less maintenance risk.
Original PR description
avoid overriding payment views by creating new computed field in the payment provider property and override it if needed in inherited payment models task-3120983
This update removes an unnecessary internal template assignment in the mail pinned messages panel. It does not change what users see, but it helps keep the code simpler and easier to maintain.
The delete confirmation button now says “Delete” instead of “Ok” across key Odoo views. This makes the action clearer for users and helps reduce accidental confirmations when removing records.
Original PR description
This commit changes the label of the delete modal confirm button from 'Ok' to 'Delete'. TaskID-3264614
This improvement lets Odoo run custom actions immediately before and after a record is saved. It gives teams more flexibility to validate, prepare, or react to saved information without changing the core save flow.
Original PR description
The purpose of this commit is to add the possibility to hook before and after the save of a record in the Record component. We will therefore add the possibility to pass onWillSaveRecord/onRecordSaved props that will be executed before/after the record save. 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
Course managers can now set one or more required courses that learners should complete before starting another course. Learners are informed about these prerequisites on the website, while managers can still grant access when an exception is needed.
Original PR description
This commit allows the course manager to add a prerequisite course to a course so that the final user will be notified on the frontend he has to take a course before the one he wants. He could however request access to the course and take it without taking the prerequisite before if the access has been granted. It's not possible to delete a prerequisite course without deleting the subsequent course at the same time. Task-3213628 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Web data reads can now include details from reference-style fields, letting screens and searches retrieve related record information in one response. This improves consistency for features that depend on dynamic links between records and reduces extra data lookups.
Original PR description
add support for fields of type `reference` and `many2one_reference` to `web_read` and `unity_web_search_read`
for both you can add a field_spec requesting fields of the "co-model":
request:
```python
{
#reference
'field_reference':
{
'fields': {'write_date': {}},
}
#many2one_reference
'm2o_reference_id':
{
'fields': {'display_name': {}, 'write_date': {}},
},
'm2o_reference_model': {}
}
```
response:
```python
{
'id': ...,
#reference
'field_reference': {
'id': {'id': 3, 'model': 'comodel_name'},
'write_date': '2004-11-23 11:30'
}
#many2one_reference
'm2o_reference_id': {
'id': 3,
'display_name': "special first day",
'write_date': '2004-11-23 11:30'
},
'm2o_reference_model': 'comodel_name',
}
```
task-id: 3284222The Planning Gantt view now labels the delete confirmation button as "Delete" instead of "Ok". This makes the action clearer for users and reduces the chance of confusion when removing planning entries.
Original PR description
This commit changes the label in gantt view of planning in delete dialogbox from 'Ok' to 'Delete'. **Task**-3264614
Document requests now show the requester as the file owner, making ownership clearer in activity views. Users can also handle email replies with attachments more smoothly and send manual reminder emails for overdue document requests.
Original PR description
This commit is a review of the document request process. The owner of the file will now be the requester, not the requestee. This has an impact on the activity view as the requester will be displayed next to the activity instead of the requestee. Attachment sent by reply on the request document email will be caught and act as if the file was uploaded regularly, it only works for the first file however. A reminder mail template has been added to be able to manually send a reminder on late document requests. TaskId-3107229
Spreadsheet toolbar and context menu items now include custom icons, making actions easier to recognize and navigate. This improves day-to-day usability for users working with spreadsheets and spreadsheet-based dashboards.
Original PR description
## Task Description The aim of this task is to add icons to all the menu items in the toolbar and in the context menu. While lots of icons has been inspired by GSheet, each one of them has been totaly by hand, with some icons being totaly hand-made (freeze pane, insert row/col/cell, ...) ## Related Task - Task-3145722
The Helpdesk ticket screen now hides the "Add A Property" button by default and guides users through the intended client action instead. This reduces visual clutter and helps users follow the standard workflow, with a related Knowledge test adjustment to keep automated checks reliable.
Original PR description
Purpose ======= Hide the "Add A Property" button by default, and instead use the client action. Task-3188915
Kitchen printer management has been moved from the restaurant-specific app into the broader Point of Sale setup, allowing printer-related workflows to work beyond restaurant configurations. Related preparation display, IoT, and compliance modules were adjusted so responsibilities are clearer and obsolete restaurant IoT code is removed.
Original PR description
*:l10n_de_pos_res_cert,pos_blackbox_be,pos_iot,pos_preparation_display,pos_restaurant_iot,pos_restaurant_preparation_display Before the printers only worked in the `pos_restaurant` and not in the `point_of_sale`. Indeed, the methods managing the printers were located in the `pos_restaurant`. Now all these methods have been moved. For the enterprise part, here are the affected modules: - The methods in `pos_restaurant_iot` have been moved to pos_iot. - The methods managing the tables in `pos_preparation_display` have been moved to `pos_restaurant_preparation_display`. - The dependencies of the `pos_blackbox_be` module have been modified. - The `pos_restaurant_iot` module has been removed as it only handled printers. Some of these methods have been adapted/renamed to better suit the needs. This branch the first part of the following task: 3224508 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
HR users can now choose whether a contract signature request is sent to an employee's private or work email address. If the selected address is unavailable, the system uses another available email, and the employee signature history now shows requests sent to either address.
Original PR description
Currently, when sending a sign request to an employee, you are not able to chose the destination mail (private or work email), this commit will give the possibility to chose to the user. If the chosen email is not defined, any available one will be used. This commit also changes the retrieved sign requests in the smart button, now all signature requests sent to the employee will be fetched (private and work email) task - 3256394
Payroll teams now receive additional dashboard warnings for missing employee information such as bank account, PAN, UAN, and ESIC numbers. The update also highlights probationary employees whose contracts are close to expiring, helping teams address issues before payroll processing.
Original PR description
_* = l10n_in_hr_payroll In this commit, we have added the following warning message for the payroll -Employees Without Bank Account Number -Employees Without PAN Numbers -Employees Without UAN Number -Employees Without ESIC Number -Employees who are on probation & their contracts expire within a week task:-3220775
The payroll dashboard now stores its to-do notes directly on the company record instead of using the separate Notes app data model. This keeps the dashboard behavior stable while reducing dependency on a model that is being merged elsewhere.
Original PR description
The payroll dashboard was relying on `note.note` for the dashboard's todo, but as this model will soon be merged into `project.task` it was decided to make the notes of the dashboard simpler and to rely on a simple HTML field on the company instead. Related: https://github.com/odoo/upgrade/pull/4407 task-3142411
The appointment invitation form now places the share link URL on a new line below its label. This makes the link easier to read and copy, improving clarity for users sharing appointment details.
Original PR description
Before this commit: The link URL appears inline with its label. After this commit: The link URL now starts from a new line, below its label.
This update fixes and polishes recent changes around partner bank account setup in Accounting. It makes account creation work correctly for trusted new records, opens documentation links in a separate browser tab, and places the related setting in a clearer Accounting section.
Original PR description
Improve some aspects of the recent res partner bank improvement:
- the url toward the docs open in a new tab
- fix the account creation by disabling the readonly when trusted
while the record isn't existing in the database yet
- improve the visual of the setting by putting it in the accounting
section
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-prA new automated test checks that spreadsheet JSON downloads keep the correct file name. This helps prevent a previously seen regression from returning during future updates.
Original PR description
Add a test for d32a169 We wouldn't had a buggy forward-port (480b8a5) if it was tested from the begining :)
The barcode parsing component was modernized so related apps use a single, consistent way to prepare barcode rules. This should make barcode-related features easier to maintain without changing day-to-day user workflows.
Original PR description
In this commit, we are converting the `BarcodeParser` to js class. As a consequence, instead of having 2 options of instantiating the parser -- via nomenclature_id or via nomenclature -- we are…
In this commit, we are converting the `BarcodeParser` to js class. As a consequence, instead of having 2 options of instantiating the parser -- via nomenclature_id or via nomenclature -- we are removing the first option. Instantiating the parser will now only require the built nomenclature object. This is possible because in all the pathways where the parser is instantiated, the web services are ready, meaning `rpc` and/or `orm` services are ready. As a result, the consumer of the parser can just build the nomenclature object itself by fetching the nomenclature details from the server. A helper static method called `fetchNomenclature` is introduced in the `BarcodeParser` class to aid in building the nomenclature object it needed. Furthermore, the methods that return the required nomenclature and rule fields are converted to static fields which can still be patched (check barcodes_gs1_nomenclature in enterprise). --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update reorganizes the barcode parsing logic in Inventory Barcode into a more modern structure. It should not change day-to-day behavior, but it makes the code easier to maintain and improve over time.
Original PR description
For more info, check: https://github.com/odoo/odoo/pull/120228
The Sign app received an internal code cleanup to align with newer JavaScript loading standards. This reduces legacy processing behind the scenes and helps keep the application easier to maintain without changing user-facing behavior.
Original PR description
This commit makes the `dependencies` param of `odoo.define` mandatory. It was optional and when omitted, a regexp read the function to find the dependencies. We can simplify it now almost all js modules have been converted to esm. The transpiler already adds the param for the es modules except if the module has an alias. task id: 3271352 community PR: https://github.com/odoo/odoo/pull/119145
**Description of the issue/feature this PR addresses:** Fixes a situation where users who are part of the Attendances Officer (or Manager) group but without access to private employee data would see the following error when trying to book time off. `ValueError: Invalid field 'last_check_in' on model 'hr.employee.public'` Other instances of the same ValueError were observed by managers trying to approve employee leave and employee expenses. **Current behavior before PR:** Users w
Original PR description
**Description of the issue/feature this PR addresses:** Fixes a situation where users who are part of the Attendances Officer (or Manager) group but without access to private employee data would see the following error when trying to book time off. `ValueError: Invalid field 'last_check_in' on model 'hr.employee.public'` Other instances of the same ValueError were observed by managers trying to approve employee leave and employee expenses. **Current behavior before PR:** Users with Attendance Officer rights but without rights to access private employee data would experience a ValueError when trying to book time off. **Desired behavior after PR is merged:** Members of the Attendance Officer group but without access to private employee data can book time off. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#120259 Forward-Port-Of: odoo/odoo#119109
When the payment method was detached from the customer, trying to pay with the linked payment token would end up with a crash because Stripe failed to send us the payment intent, as it could not create it. With this commit, we test for the existence of the returned payment intent and prematurely return in `_send_payment_request` to prevent a cursor rollback. The transaction is set in 'error' and the error message is logged in the stdout and on the transaction's state message field. Forward-P
Original PR description
When the payment method was detached from the customer, trying to pay with the linked payment token would end up with a crash because Stripe failed to send us the payment intent, as it could not create it. With this commit, we test for the existence of the returned payment intent and prematurely return in `_send_payment_request` to prevent a cursor rollback. The transaction is set in 'error' and the error message is logged in the stdout and on the transaction's state message field. Forward-Port-Of: odoo/odoo#120013
**Current behavior before PR:** When using shift+enter to move to a new line, now applying bold, italics, underline, etc and then trying to add a color to both lines would result in lines merging. **Desired behavior after PR is merged:** Now when the both lines are bold and then applying a color to both the lines would no longer merge. **Task:** 3269922 Forward-Port-Of: odoo/odoo#118698
Original PR description
**Current behavior before PR:** When using shift+enter to move to a new line, now applying bold, italics, underline, etc and then trying to add a color to both lines would result in lines merging. **Desired behavior after PR is merged:** Now when the both lines are bold and then applying a color to both the lines would no longer merge. **Task:** 3269922 Forward-Port-Of: odoo/odoo#118698
Before this commit, on a blog page with the "regular cover" and "read next article" options enabled, the image in the "read next article" block would shrink when the text was too long. Steps to reproduce the bug: - Go to a blog page (e.g. "Sierra Tarahumara"). - Enable the "regular cover" and "read next article" options. - Enter edit mode. - Scroll down the page. - Enter a lot of text as the title of the "read next article" block. - Bug: As the text increases, the width of the image d
Original PR description
Before this commit, on a blog page with the "regular cover" and "read next article" options enabled, the image in the "read next article" block would shrink when the text was too long. Steps to reproduce the bug: - Go to a blog page (e.g. "Sierra Tarahumara"). - Enable the "regular cover" and "read next article" options. - Enter edit mode. - Scroll down the page. - Enter a lot of text as the title of the "read next article" block. - Bug: As the text increases, the width of the image decreases. opw-3267842 Forward-Port-Of: odoo/odoo#119852
Steps to reproduce the bug: - Go to Decimal accuracy: - Select the “Product Unit of Measure” - Set the Value to “4” - Create a storable product with BoM: - add any product as component - save - Click on the BoM overview widget Problem: The “Product UoM” precision is not used opw-3288403 Forward-Port-Of: odoo/odoo#120079
Original PR description
Steps to reproduce the bug:
- Go to Decimal accuracy:
- Select the “Product Unit of Measure”
- Set the Value to “4”
- Create a storable product with BoM:
- add any product as component
- save
- Click on the BoM overview widget
Problem:
The “Product UoM” precision is not used
opw-3288403
Forward-Port-Of: odoo/odoo#120079**Description of the issue/feature this PR addresses:** Parts of the test suite and the tests that test the test suite make assumptions about path separators that break on Windows. On the Debian release, Odoo is installed into the system python folder, which breaks the "exception cleaning" performed by the test suite tests. It will first replace all instances of `python3` with `python`. It will then try to replace the Odoo root path with `/root_path/odoo`. It will be looking for `/usr/lib/py
Original PR description
**Description of the issue/feature this PR addresses:** Parts of the test suite and the tests that test the test suite make assumptions about path separators that break on Windows. On the Debian…
**Description of the issue/feature this PR addresses:** Parts of the test suite and the tests that test the test suite make assumptions about path separators that break on Windows. On the Debian release, Odoo is installed into the system python folder, which breaks the "exception cleaning" performed by the test suite tests. It will first replace all instances of `python3` with `python`. It will then try to replace the Odoo root path with `/root_path/odoo`. It will be looking for `/usr/lib/python3/dist-packages`, but it will only find `/usr/lib/python/dist-packages` due to the prior replacement This PR fixes the test suite and tests for both cases, and attempts to prevent further potential issues. **Current behavior before PR:** `test_test_suite` tests fail on Windows and on the Debian release of Odoo **Desired behavior after PR is merged:** `test_test_suite` tests pass --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#120167 Forward-Port-Of: odoo/odoo#119895
This commit fixes a few things in the UI: - The format selection labels could be confusing to users, for example, the word "billing" is not necessary here. Now the labels are clearer and structured in a similar way. - `peppol_endpoint` is recomputed whenever there is a change in the vat but we do not want to make changes if there is already some value in this field. This commit adds a check for whether `peppol_endpoint`is already filled in. - Same for the `peppol_eas` field - should not be ch
Original PR description
This commit fixes a few things in the UI: - The format selection labels could be confusing to users, for example, the word "billing" is not necessary here. Now the labels are clearer and structured in a similar way. - `peppol_endpoint` is recomputed whenever there is a change in the vat but we do not want to make changes if there is already some value in this field. This commit adds a check for whether `peppol_endpoint`is already filled in. - Same for the `peppol_eas` field - should not be changed if it's already there. - Both of these fields should be logged in the chatter when changed --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#118883
Description of the issue/feature this PR addresses: Stock valuation layers are generated for storable and consumable products. However, given that we don't keep track of its quants, we hide those layers by default (by adding a domain [('product_id.type', '=', 'product')]). Current behavior before PR: On the dashboard, such domain is currently not present. As a result, our inventory valuation value is not the same when we look at it through the dashboard or through the inventory app. Desi
Original PR description
Description of the issue/feature this PR addresses:
Stock valuation layers are generated for storable and consumable products. However, given that we don't keep track of its quants, we hide those layers by default (by adding a domain [('product_id.type', '=', 'product')]).
Current behavior before PR:
On the dashboard, such domain is currently not present. As a result, our inventory valuation value is not the same when we look at it through the dashboard or through the inventory app.
Desired behavior after PR is merged:
This commit adds the same domain so that the value of the inventory shown is always the same (which means not including consumable products).
OPW-3275521
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#120118In case you write user_id = False on the sale order, It will match the first sale team without sale team manager. It is because False != None. After this fix, we check if user_id is Falsy instead of not provided to the function. 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#120307
Original PR description
In case you write user_id = False on the sale order, It will match the first sale team without sale team manager. It is because False != None. After this fix, we check if user_id is Falsy instead of not provided to the function. 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#120307
Current link in settings leads to 404 error page, changing the path to the right one opw-3279614 Description of the issue/feature this PR addresses: correcting the plausible link in the website settings Current behavior before PR: link in the settings leads to 404 Desired behavior after PR is merged: links opens properly --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#120185 Forward-Port-Of: odoo/odoo#11899
Original PR description
Current link in settings leads to 404 error page, changing the path to the right one opw-3279614 Description of the issue/feature this PR addresses: correcting the plausible link in the website settings Current behavior before PR: link in the settings leads to 404 Desired behavior after PR is merged: links opens properly --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#120185 Forward-Port-Of: odoo/odoo#118997
Steps to reproduce: - Go to a website page > Add a 'Form' block > Add a new 'Selection' field. - Go to the page (in 'edit_translations' mode) > The selection field options are not translatable. The goal of this commit is to make the select options translatable by adding an intermediate o_translation_select element. This element should will handle option's text translations from the linked `<select/>`. The final values are copied to the original element right before save. opw-323336
Original PR description
Steps to reproduce: - Go to a website page > Add a 'Form' block > Add a new 'Selection' field. - Go to the page (in 'edit_translations' mode) > The selection field options are not translatable. The goal of this commit is to make the select options translatable by adding an intermediate o_translation_select element. This element should will handle option's text translations from the linked `<select/>`. The final values are copied to the original element right before save. opw-3233360 Forward-Port-Of: odoo/odoo#120320 Forward-Port-Of: odoo/odoo#117519
Issue ------ A business code error was detected by the internal team on our production. The cache and assets where invalidated !WAY! too often for the past months. It was hard to figure but finally the error was tracked down to be located in the assets retrieval stack of our code when a database is accessed through multiple different domains. In our production use case, whenever one was accessing `odoo.com/web` after someone accessed `accounts.odoo.com/web`, the assets would be i
Original PR description
Issue ------ A business code error was detected by the internal team on our production. The cache and assets where invalidated !WAY! too often for the past months. It was hard to figure but finally…
Issue
------
A business code error was detected by the internal team on our
production. The cache and assets where invalidated !WAY! too often for
the past months.
It was hard to figure but finally the error was tracked down to be
located in the assets retrieval stack of our code when a database is
accessed through multiple different domains.
In our production use case, whenever one was accessing `odoo.com/web`
after someone accessed `accounts.odoo.com/web`, the assets would be
invalidated and recomputed, again and again, whenever someone accessed
the backend on a domain after someone else did with another domain.
Obviously, on our production, this could be occuring multiple time per
minute.
Technically, this is because the "assets retrieval stack" had a mismatch
in multiple endpoint when trying to find if a current website was
involved (serving for the frontend).
Some business method were using `env.context.get('website_id')` while
others were using `env['website'].get_current_website(fallback=False)`.
From there, when the code was called without a `website_id` in the
context, `get_current_website()` would still return a `website_id` when
called from `http://odoo.com` as there is a website having its domain
set to it. `get_current_website()` is then finding it and returning it.
But it would not when the user is on `http://accounts.odoo.com`.
Since we have a custom scss override (done through our website builder,
basically an ir.asset linked to a "url type" attachment:
`/website/static/src/scss/options/colors/user_color_palette.scss`) for
our website to define the website colors which is shadowing the scss
file from disk.
So, depending of the host/domain, either the real file disk for this URL
or the ir.asset linked to our website for this URL would be fetched to
generate the bundle hash (which is basically the last modification date
of the files/attachments).
Obviously, the file on disk and the ir.assets have a different last
modification date.
The system would then consider the assets as outdated and would
regenerate it.
You can see it in the logs where the attachment id of the assets URL
would get higher and higher everytime you access the DB through another
domain.
Using `get_current_website(fallback=False)`:
- `_get_related_assets()` See [here](https://github.com/odoo/odoo/blame/30d3b97b5ece379d9ddcbceda9d12c03dc7f4a48/addons/website/models/ir_asset.py#L14)
- `filter_duplicate()` See [here](https://github.com/odoo/odoo/blame/30d3b97b5ece379d9ddcbceda9d12c03dc7f4a48/addons/website/models/ir_asset.py#L41)
- ..
Using `get_current_website()`:
- `_get_custom_attachment()` See [here](https://github.com/odoo/odoo/blame/30d3b97b5ece379d9ddcbceda9d12c03dc7f4a48/addons/website/models/assets.py#L162)
- ..
Using `context.get('website_id')`:
- `_get_asset_url_values()` See [here](https://github.com/odoo/odoo/blame/30d3b97b5ece379d9ddcbceda9d12c03dc7f4a48/addons/website/models/ir_qweb.py#L23)
- ..
Fix
------
A fix could have been to aligned those to use the same way of retrieving
the website but it would be too fragile (definitely some other places
where the same bug is involved but not yet found).
What is done in this commit is something we wanted to do for a long time
(see [1]) but was based purely on guess and feeling rather than concrete
bug / use case, but now that we found a real use case, we will do it:
- It doesn't seems to make sense to consider the request host/domain
when we are in the backend
- Same for the forced session, those should only impact the frontend
calls.
But this seems to have too much impact in stable to be changed, as it
would require to check every caller to also check for the session if
it makes sense. This will be done in master as not really needed to
prevent the critical bug fixed here.
- When something wants to alter the backend with a website, it should
explicitely be passed in the context, which is still considered
regardless if it's a backend/frontend call.
- If something needs to consider the forced website in session in the
backend, it should explicitely check it, not relying on
`get_current_website()`.
Step to reproduce
------
- Start a db with website installed
- Enter the website builder in edit mode and change the "Theme Colors"'s
first "Color Presets"'s background color (it is white by default).
- Set the website domain to `http://127.0.0.1:8069/`
- Go to `http://127.0.0.1:8069/web` and login
- Go to `http://127.0.0.2:8069/web` and login
- Now start refreshing those 2 pages one after each other.
Everytime you will refresh the page, it will take a very long time
(~5-10 seconds) before loading the page, and monitoring the logs will
show something about invalidating the cache and huge query count.
Benchmark
------
For the explained "multiple domain access" case, the backend /web will
now be loaded in less than 10ms and with ~10 SQL Queries when website is
installed, while it was taking ~4 seconds and ~200 Sql Queries before
the fix.
Before the fix:
```
odoo.modules.registry: At least one model cache has been invalidated, signaling through the database
GET host1.com/web HTTP/1.1 200 - 222 0.135 3.840 <-- 222 Queries, ~4s
odoo.modules.registry: At least one model cache has been invalidated, signaling through the database
GET host2.com/web HTTP/1.1 200 - 181 0.101 3.692 <-- 181 Queries, ~4s
odoo.modules.registry: At least one model cache has been invalidated, signaling through the database
GET host1.com/web HTTP/1.1 200 - 215 0.121 3.704 <-- 215 Queries, ~4s
odoo.modules.registry: At least one model cache has been invalidated, signaling through the database
GET host2.com/web HTTP/1.1 200 - 181 0.100 3.616 <-- 181 Queries, ~4s
```
After the fix:
```
odoo.modules.registry: At least one model cache has been invalidated, signaling through the database
GET host1.com/web HTTP/1.1 200 - 101 0.043 0.353 <-- 101 Queries, ~0.3s
GET host2.com/web HTTP/1.1 200 - 11 0.004 0.007 <-- 11 Queries, ~10ms
GET host1.com/web HTTP/1.1 200 - 11 0.003 0.005 <-- 11 Queries, ~10ms
GET host2.com/web HTTP/1.1 200 - 11 0.003 0.008 <-- 11 Queries, ~10ms
```
[1]: https://github.com/odoo/odoo/pull/94161#discussion_r904780031 (Also other PR/task but couldn't find those.)
Forward-Port-Of: odoo/odoo#118526QR codes had different translations than the official ones. That prevented the QR-bill to be submitted through Snailmail. Reference of translations (p.58): https://www.six-group.com/dam/download/banking-services/standardization/qr-bill/ig-qr-bill-v2.2-en.pdf opw: 3223714 Forward-Port-Of: odoo/odoo#120026
Original PR description
QR codes had different translations than the official ones. That prevented the QR-bill to be submitted through Snailmail. Reference of translations (p.58): https://www.six-group.com/dam/download/banking-services/standardization/qr-bill/ig-qr-bill-v2.2-en.pdf opw: 3223714 Forward-Port-Of: odoo/odoo#120026
Description of the issue/feature this PR addresses: Files that should be ignored in the manifest but aren't (js library for example) it can happen that files have huge lines, the regex to substract the comments will overuse memory. For example, a file of 13M with a line of more that 8M characters, the memory consumptions peak at 1.7G The results might be different, but it's an acceptable compromise --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-p
Original PR description
Description of the issue/feature this PR addresses: Files that should be ignored in the manifest but aren't (js library for example) it can happen that files have huge lines, the regex to substract the comments will overuse memory. For example, a file of 13M with a line of more that 8M characters, the memory consumptions peak at 1.7G The results might be different, but it's an acceptable compromise --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#120139 Forward-Port-Of: odoo/odoo#119977
The first two arguments of the call() function of the orm service have been inverted. This is fixed. Forward-Port-Of: odoo/odoo#120252
Original PR description
The first two arguments of the call() function of the orm service have been inverted. This is fixed. Forward-Port-Of: odoo/odoo#120252
Fix the rank image display which has currently disappear by making it appear again in the xp circle. Also making sure the xp circle tooltip is correctly showing on hover. Task-3285548 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#119783
Original PR description
Fix the rank image display which has currently disappear by making it appear again in the xp circle. Also making sure the xp circle tooltip is correctly showing on hover. Task-3285548 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#119783
--- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#118159
Original PR description
--- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#118159
Modify user error message when answering an unpublished quiz. Task-3255897 Forward-Port-Of: odoo/odoo#118495
Original PR description
Modify user error message when answering an unpublished quiz. Task-3255897 Forward-Port-Of: odoo/odoo#118495
**Current behavior before PR:** When the Mobile Preview is clicked in the mailing template of the marketing automation, the preview is empty. The preview is seen after closing all the dialog boxes, but it is still not obtained as expected. **Desired behavior after PR is merged:** The mobile preview is working properly while clicking on the preview button. **Task**-3272504 Forward-Port-Of: odoo/odoo#119062
Original PR description
**Current behavior before PR:** When the Mobile Preview is clicked in the mailing template of the marketing automation, the preview is empty. The preview is seen after closing all the dialog boxes, but it is still not obtained as expected. **Desired behavior after PR is merged:** The mobile preview is working properly while clicking on the preview button. **Task**-3272504 Forward-Port-Of: odoo/odoo#119062
All figures coming from the accounting dashboard should be, by default, excluding the unposted entries since this is the default filter when opening the reports. opw - 3268676 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#119693 Forward-Port-Of: odoo/odoo#119513
Original PR description
All figures coming from the accounting dashboard should be, by default, excluding the unposted entries since this is the default filter when opening the reports. opw - 3268676 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#119693 Forward-Port-Of: odoo/odoo#119513
The fix introduced in odoo/odoo#119017 was no longer taking into account the refused/archived applications, showing a negative number in some cases. task-3293460 Forward-Port-Of: odoo/odoo#120096
Original PR description
The fix introduced in odoo/odoo#119017 was no longer taking into account the refused/archived applications, showing a negative number in some cases. task-3293460 Forward-Port-Of: odoo/odoo#120096
**Purpose:** The purpose of this commit is to change the current behavior of days to close graph generating from customizable desk demo data. **Specification:** For the opportunities, the day_close field is a compute field depending upon the date_closed field. For the customizable desk demo data, the date_closed field pre-existed, due to that customizable desk opportunity was not won or lost but the graph report was generated. so, this commit fixes the current behavior for customizable des
Original PR description
**Purpose:** The purpose of this commit is to change the current behavior of days to close graph generating from customizable desk demo data. **Specification:** For the opportunities, the day_close field is a compute field depending upon the date_closed field. For the customizable desk demo data, the date_closed field pre-existed, due to that customizable desk opportunity was not won or lost but the graph report was generated. so, this commit fixes the current behavior for customizable desk opportunity. **Task**-3278039 Forward-Port-Of: odoo/odoo#119292
Steps to reproduce: - Install crm - Go to settings and activate leads in crm. - Go to leads list and select any lead, now mark it as lost. Issue: It will ask for lost reason. But if we do it from the Leads form view, we don't get to set any reason. I discussed with the PO and we don't want to add the lost reason in the leads. Solution: Modified action of lost so it takes leads into account. Forward bot up to master. opw-3119748 Forward-Port-Of: odoo/odoo#119546 Forwar
Original PR description
Steps to reproduce: - Install crm - Go to settings and activate leads in crm. - Go to leads list and select any lead, now mark it as lost. Issue: It will ask for lost reason. But if we do it from the Leads form view, we don't get to set any reason. I discussed with the PO and we don't want to add the lost reason in the leads. Solution: Modified action of lost so it takes leads into account. Forward bot up to master. opw-3119748 Forward-Port-Of: odoo/odoo#119546 Forward-Port-Of: odoo/odoo#111226
Task-3290752 https://github.com/odoo/enterprise/pull/40395 <img width="740" alt="Screenshot 2023-04-27 at 17 14 36" src="https://user-images.githubusercontent.com/6569390/234918058-d0629bad-3007-46e4-9c59-f9ea7f0527b6.png"> Forward-Port-Of: odoo/odoo#119878
Original PR description
Task-3290752 https://github.com/odoo/enterprise/pull/40395 <img width="740" alt="Screenshot 2023-04-27 at 17 14 36" src="https://user-images.githubusercontent.com/6569390/234918058-d0629bad-3007-46e4-9c59-f9ea7f0527b6.png"> Forward-Port-Of: odoo/odoo#119878
Steps to reproduce the issue: 1. Project> select Project > Task> List view 2. Studio list view > Add existing properties field 3. Go back to list view > Favorites > add to spreadsheet 4. New Spreadsheet > Will receive error opw-3284273 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#1200
Original PR description
Steps to reproduce the issue: 1. Project> select Project > Task> List view 2. Studio list view > Add existing properties field 3. Go back to list view > Favorites > add to spreadsheet 4. New Spreadsheet > Will receive error opw-3284273 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#120055
This commit addresses an issue with the checkout form displayed on the portal page of the Subscriptions app: when only one payment provider was available for checkout, and it required an inline form to be displayed, the latter would not be shown, and customers were able to hit the "Pay" button, resulting in a client error. The problem was that Subscriptions now simultaneously displays two payment forms on the same page, one for checkout and one for managing payment methods, which was not support
Original PR description
This commit addresses an issue with the checkout form displayed on the portal page of the Subscriptions app: when only one payment provider was available for checkout, and it required an inline form to be displayed, the latter would not be shown, and customers were able to hit the "Pay" button, resulting in a client error. The problem was that Subscriptions now simultaneously displays two payment forms on the same page, one for checkout and one for managing payment methods, which was not supported by the payment engine. Forward-Port-Of: odoo/odoo#120417
How to reproduce: - Activate l10n_be and go on a Belgian Company - Activate Quick Encoding on Bills - Setup account 600000 with taxes 12% (Sales) and 12% M (Purchase) - Create a Bill - Put 112 as the amount Tax Incl. => Both taxes are put on the line, which makes no sense, resulting a sale tax on a purchase document. It was forgotten in https://github.com/odoo/odoo/commit/85d89a986b6adcf9d0ac0ce57599d4b2678b59a3 Description of the issue/feature this PR addresses: Current behavior b
Original PR description
How to reproduce: - Activate l10n_be and go on a Belgian Company - Activate Quick Encoding on Bills - Setup account 600000 with taxes 12% (Sales) and 12% M (Purchase) - Create a Bill - Put 112 as the amount Tax Incl. => Both taxes are put on the line, which makes no sense, resulting a sale tax on a purchase document. It was forgotten in https://github.com/odoo/odoo/commit/85d89a986b6adcf9d0ac0ce57599d4b2678b59a3 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#120318
Because we are flushing, and because the business code might be flushing elsewhere (i.e. to validate constraints), the fields depending on the sequence field might be protected by the ORM. This is not desired, so we already reset them here. The symptoms were that sometimes the related field `move_name` on `account.move.line` would stay at `/` even after the new `name` was given. Forward-Port-Of: odoo/odoo#120468 Forward-Port-Of: odoo/odoo#120076
Original PR description
Because we are flushing, and because the business code might be flushing elsewhere (i.e. to validate constraints), the fields depending on the sequence field might be protected by the ORM. This is not desired, so we already reset them here. The symptoms were that sometimes the related field `move_name` on `account.move.line` would stay at `/` even after the new `name` was given. Forward-Port-Of: odoo/odoo#120468 Forward-Port-Of: odoo/odoo#120076
Until 15.0, to show the behaviour of the QR billing in Switzerland, you had to manually configure a bank account for CH company and create a QR Bill compliant customer before creating an invoice, which was time consuming in the context of a demo. Updated the demo company's bank account and added an adequate customer to ease the process. task-3264826 Forward-Port-Of: odoo/odoo#118923
Original PR description
Until 15.0, to show the behaviour of the QR billing in Switzerland, you had to manually configure a bank account for CH company and create a QR Bill compliant customer before creating an invoice, which was time consuming in the context of a demo. Updated the demo company's bank account and added an adequate customer to ease the process. task-3264826 Forward-Port-Of: odoo/odoo#118923
Before this commit: If a public users create two helpdesk ticket from the website form the ticket id mentioned on the website form will always be the same. As the page is cached, the function `_website_form_last_record` is not called again when the page is opened which result on the same page being render. So any public users (even on different browser/sessions) will have the same ticket ID mentioned which is wrong (as long as the page is cached). After this commit: The ticket given on
Original PR description
Before this commit: If a public users create two helpdesk ticket from the website form the ticket id mentioned on the website form will always be the same. As the page is cached, the function `_website_form_last_record` is not called again when the page is opened which result on the same page being render. So any public users (even on different browser/sessions) will have the same ticket ID mentioned which is wrong (as long as the page is cached). After this commit: The ticket given on the submitted page would correspond to the created ticket Note: the issue does not happen on version 16 (and >), probably as the field `cached_time` have been removed, see: https://github.com/odoo/odoo/commit/0452d0701fcb8f4588b9b05dad9bbdd507539265 It does not reproduce on version 15 neither as this issue is already fixed in the same way, see: https://github.com/odoo/enterprise/pull/29778 opw-3141250 Forward-Port-Of: odoo/enterprise#40474 Forward-Port-Of: odoo/enterprise#40380
Task-3290752 https://github.com/odoo/odoo/pull/119878 Forward-Port-Of: odoo/enterprise#40395
Original PR description
Task-3290752 https://github.com/odoo/odoo/pull/119878 Forward-Port-Of: odoo/enterprise#40395
…rrect imports have been done Currently, when importing multiple bank statements, if one of them has an error, we block the importation of the others. With this commit, we will process all the statements and, if applicable, show an error message at the end. This allows correct statements to be imported even if one in the batch is failing. Therefore, we now have three flows: - Everything went smoothly, we can redirect the user to correct view - All the imports failed, we show an error
Original PR description
…rrect imports have been done Currently, when importing multiple bank statements, if one of them has an error, we block the importation of the others. With this commit, we will process all the statements and, if applicable, show an error message at the end. This allows correct statements to be imported even if one in the batch is failing. Therefore, we now have three flows: - Everything went smoothly, we can redirect the user to correct view - All the imports failed, we show an error - At least one import succeeded and at least one failed, we display a warning message containing the names of the attachments that were not imported and show an option to view the ones that were correctly imported task id 2747359 Forward-Port-Of: odoo/enterprise#40606 Forward-Port-Of: odoo/enterprise#38402
Before pr: Traceback while opening the url preview from list view. Because currently url is not viewable. After pr: No tracebcak when we click on the url preview. Task-3234811 Forward-Port-Of: odoo/enterprise#39727
Original PR description
Before pr: Traceback while opening the url preview from list view. Because currently url is not viewable. After pr: No tracebcak when we click on the url preview. Task-3234811 Forward-Port-Of: odoo/enterprise#39727
**Prior to this commit:** When the Mail body is opened from marketing automation, the template is loaded without the correct padding and hence it appears to be shifted to the right side of the body. **Post this commit:** The template is loaded in the correct place. **Task**-3217807 Forward-Port-Of: odoo/enterprise#39723
Original PR description
**Prior to this commit:** When the Mail body is opened from marketing automation, the template is loaded without the correct padding and hence it appears to be shifted to the right side of the body. **Post this commit:** The template is loaded in the correct place. **Task**-3217807 Forward-Port-Of: odoo/enterprise#39723
If an appointment type was chosen in the snippet options, the button would still redirect to all appointments due to a mix-up when parsing the list of selected appointment types. Task-3276820 Forward-Port-Of: odoo/enterprise#39857
Original PR description
If an appointment type was chosen in the snippet options, the button would still redirect to all appointments due to a mix-up when parsing the list of selected appointment types. Task-3276820 Forward-Port-Of: odoo/enterprise#39857
task - 3236161 Forward-Port-Of: odoo/enterprise#38637
Original PR description
task - 3236161 Forward-Port-Of: odoo/enterprise#38637
Propagate debug param from host to iframe to allow in browser iframe js debug. Forward-Port-Of: odoo/enterprise#40592
Original PR description
Propagate debug param from host to iframe to allow in browser iframe js debug. Forward-Port-Of: odoo/enterprise#40592
Since the commit ac7236167a71954210b75f88b958c812e7399e80, the menu action "Edit Payslip Lines" doesn't update all the payslip lines when one of them is modified. Why not ? To perform an update in a Field, you must no longer use props.update which only takes a value but props.record.update which takes a dictionary containing the fields to be modified (key = fieldname). Solution: We must therefore adapt the overwrite in PayslipLineField and WorkedDaysField. They should no longer look
Original PR description
Since the commit ac7236167a71954210b75f88b958c812e7399e80, the menu action "Edit Payslip Lines" doesn't update all the payslip lines when one of them is modified. Why not ? To perform an update in a…
Since the commit ac7236167a71954210b75f88b958c812e7399e80, the menu
action "Edit Payslip Lines" doesn't update all the payslip lines when one
of them is modified.
Why not ?
To perform an update in a Field, you must no longer use props.update
which only takes a value but props.record.update which takes a dictionary
containing the fields to be modified (key = fieldname).
Solution:
We must therefore adapt the overwrite in PayslipLineField and WorkedDaysField.
They should no longer look in the props to see which field is being edited,
but if the amount or quantity field is present in the changes pass it to update.
How to reproduce ?
- Go to the form view of a Payslip
- Click on the action menu "Edit Payslip Lines
- Edit the amount of a line
Before this commit:
Only the edited line has changed. No save takes place.
After this commit:
The edit line has been changed. The record is saved and the dependent
lines have been modified.
Forward-Port-Of: odoo/enterprise#40588Commit 34ee001ea7a change the form view top classes. This break the scss of the workorder tablet view. Forward-Port-Of: odoo/enterprise#40494
Original PR description
Commit 34ee001ea7a change the form view top classes. This break the scss of the workorder tablet view. Forward-Port-Of: odoo/enterprise#40494
Since odoo/enterprise@9d0c352804 we protect against the removal of utm campaign and source but not against removal of medium (which are explicitly permitted) In such case, when computing hr.job clicks we may ends up crashing with: ``` Traceback (most recent call last): ... File "/home/odoo/src/enterprise/saas-16.2/hr_referral/models/hr_job.py", line 37, in _compute_clicks mapped_data[elem['campaign_id'][0]][elem['medium_id'][0]] = elem['count'] TypeError: 'bool' object is not
Original PR description
Since odoo/enterprise@9d0c352804 we protect against the removal of utm campaign and source but not against removal of medium (which are explicitly permitted)
In such case, when computing hr.job clicks we may ends up crashing with:
```
Traceback (most recent call last):
...
File "/home/odoo/src/enterprise/saas-16.2/hr_referral/models/hr_job.py", line 37, in _compute_clicks
mapped_data[elem['campaign_id'][0]][elem['medium_id'][0]] = elem['count']
TypeError: 'bool' object is not subscriptable
```
To reproduce:
- Open Referral app, click on "Jobs" and create a "Direct" share link
- Open that link
- Now remove the "Direct" medium
- Open Referral app, click on "Jobs" => it crash with the above traceback.
This commit ensure we only fetch link.tracker with a `medium_id` set
Forward-Port-Of: odoo/enterprise#40231The Create Invoice button is now visible on paused subscriptions. A filter for subscriptions with next invoice date in the past is now available. Sale reports can now be customized using recurrence filters. Product templates now stay recurring if they have confirmed sale order lines. task-3242175 Forward-Port-Of: odoo/enterprise#40386 Forward-Port-Of: odoo/enterprise#38613
Original PR description
The Create Invoice button is now visible on paused subscriptions. A filter for subscriptions with next invoice date in the past is now available. Sale reports can now be customized using recurrence filters. Product templates now stay recurring if they have confirmed sale order lines. task-3242175 Forward-Port-Of: odoo/enterprise#40386 Forward-Port-Of: odoo/enterprise#38613
This commit updates the documentation URLs to the current URLs, although there are already redirect rules in place as fallback. task-3284514 Forward-Port-Of: odoo/enterprise#40600 Forward-Port-Of: odoo/enterprise#40372
Original PR description
This commit updates the documentation URLs to the current URLs, although there are already redirect rules in place as fallback. task-3284514 Forward-Port-Of: odoo/enterprise#40600 Forward-Port-Of: odoo/enterprise#40372