Wednesday, September 29, 2021
30 changes · master
Enhancements to existing features
Users can now see the full workspace name by hovering over it in Documents. This helps people identify workspaces with long or shortened names without needing to open or rename them.
Original PR description
PURPOSE: Currently, we don't have any option to see the full name of the workspace. SPECIFICATIONS: Show the name of the workspace when you hover it with the cursor. LINKS: Task-2641699 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The Time Off smart button now includes unpaid leave allocations when showing how many days an employee has available. This gives employees and managers a more complete and reliable view of remaining time off directly from the employee profile.
Original PR description
The smartbutton needs to display the total of days available to the user to take holidays. It should include unpaid allocations as well in the count of remaining days available. Before this commit, the unpaid allocations were not included in the calculation of the remaining days available. task - 2634892
Resolved issues and error corrections
Installing the Austrian localization now creates a demo company automatically. This makes it easier for users to explore or test the Austrian setup with realistic company data available right away.
Original PR description
Problem: When installing the Austrian localisation no demo company is created. Solution: Create demo_company.xml and add it to the manifest task: 2631136
Miscellaneous changes
This fix prevents an error from appearing when a user uses Sign Now on a signing template that includes multiple signers. It ensures location information is checked properly when creating the signing log, making the signing flow more reliable.
Original PR description
Check geo location for "create" sign log Before this commit: a trackback will be shown if a user Sign Now a template with multiple signers task-2652261
RATIONALE Jinja is used a templating engine in various places, notably in mail templates and digest content. It is known to have some limitations * its syntax is specific and is concurrent with Odoo QWeb template language. Additional knowledge is required just for that purpose; * it is not XML compliant, meaning we quickly run into issues when editing its content as HTML. Notably rendering engine (browsers) may reorder jinja content arbitrary when its syntax is not val
Original PR description
RATIONALE Jinja is used a templating engine in various places, notably in mail templates and digest content. It is known to have some limitations * its syntax is specific and is concurrent with Odoo…
RATIONALE
Jinja is used a templating engine in various places, notably in mail templates
and digest content. It is known to have some limitations
* its syntax is specific and is concurrent with Odoo QWeb template language.
Additional knowledge is required just for that purpose;
* it is not XML compliant, meaning we quickly run into issues when editing
its content as HTML. Notably rendering engine (browsers) may reorder
jinja content arbitrary when its syntax is not valid, which is often
the case with advanced constructs involving nested for and if;
* jinja template do not benefit from improvements done in QWeb and its
integration in our HTML editor;
* it is an outside templating engine that we do not control;
* it adds an external dependency;
PURPOSE
Replace Jinja with Qweb so that we can now build tools to edit a Qweb
template, mainly for ``mail.template`` records. In this merge we now
support QWeb as rendering engine for mail templates. All templates are
updated accordingly. Some other records using jinja are also updated like
``digest`` content (tips).
To be able to edit template content from the backend interface a plugin to
the Odoo editor has been made to seamlessly edit documents. It includes :
* allow to make dynamic variables (eg. `<t t-out="variable"/>`) not
editable when required;
* group and hide related logical branching (ie. t-if, t-elif and t-else)
in order to see only one at once;
* a floating select input to switch visibility of a particular logical
branching;
TEXT RENDERING
Not all content previously rendered using jinja holds HTML content. For
example some email fields (e.g. ``email_from`` or ``subject``) used Jinja
syntax for rendering (e.g. ``Email for ${object.name}`` or
``${object.email_formatted | safe}``).
We want to keep dynamic rendering for those char fields. However as it is
not XML we use a new rendering engine called "inline_template". It is
based on QWeb rendering used to evaluate expression and attributes like
``t-att-href="{{object.link}}"``. Expressions should be enclosed by `{{` and
`}}` to highlight they are dynamic. For most expressions this is equivalent
to jinja expressions with a simple marker change.
LINKS
Task-2497930 (Main editor task)
Task-27033 (Main functional task)
Forward-Port-Of: odoo/odoo#77074Forward-Port-Of: odoo/odoo#77379
Original PR description
Forward-Port-Of: odoo/odoo#77379
Explicit flushing of the cursor had been implemented in the "legacy" `url_open` helper in 1595c0ee27c7a261f8903dccb9dc550224c2aa05, but it was missing when going through `requests` directly (via the `opener`), or when performing XML-RPC calls. Fix that: * extend `requests.Session` and `xmlrpc.client.Transport` so they take a cursor * move the setup of the XML-RPC clients to `setUp` so they can *get* the cursor * move the rest of `HttpCase.__init__` to `setUpClass` and drop the override e
Original PR description
Explicit flushing of the cursor had been implemented in the "legacy" `url_open` helper in 1595c0ee27c7a261f8903dccb9dc550224c2aa05, but it was missing when going through `requests` directly (via the `opener`), or when performing XML-RPC calls. Fix that: * extend `requests.Session` and `xmlrpc.client.Transport` so they take a cursor * move the setup of the XML-RPC clients to `setUp` so they can *get* the cursor * move the rest of `HttpCase.__init__` to `setUpClass` and drop the override entirely * remove the now-redundant flush in `url_open` (as it's done by the `opener`) Forward-Port-Of: odoo/odoo#77313
Before this commit, the clickbot test failed when switching from a dashboard view to a pivot, graph or cohort view, because the condition to wait before toggling the filters in the next view was wrong. As a consequence, we started to toggle the filters for the next view on the dashboard view, so when we actually switched to that view, the filter menu was closed and the tour was blocked. The previous condition used the `.o_{view_type}_view` classname, targetting the root node of the view
Original PR description
Before this commit, the clickbot test failed when switching from a dashboard view to a pivot, graph or cohort view, because the condition to wait before toggling the filters in the next view was…
Before this commit, the clickbot test failed when switching from
a dashboard view to a pivot, graph or cohort view, because the
condition to wait before toggling the filters in the next view was
wrong. As a consequence, we started to toggle the filters for the
next view on the dashboard view, so when we actually switched to
that view, the filter menu was closed and the tour was blocked.
The previous condition used the `.o_{view_type}_view` classname,
targetting the root node of the view (which appears in the DOM when
the view is loaded). Unfortunately, since [1] and the new
implementation of the graph and pivot views, we added root
classnames to graph and pivot (o_graph_view and o_pivot_view),
whereas it wasn't the case before. So when leaving a dashboard
view to a graph or pivot view, the former condition was directly
true (if the dashboard contained those views), and we didn't wait
for the next graph or pivot view to be loaded.
Note that the former implementatin of the cohort view already added
the "o_cohort_view" classname on its root node, but it didn't make
the clickbot test fail because we don't have cohort views next to
dashboard views in standard actions.
This commit changes the condition to use the view switcher icons
instead.
[1] 0134495ba55bea16c2d11d5eb5d832edad575694
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#77302Forward-Port-Of: odoo/odoo#77268
Original PR description
Forward-Port-Of: odoo/odoo#77268
Steps to follow - Add an HTML field in the sales order line view - Create a sales order - Add a product - Add a table with multiple rows in the HTML widget - Add a new product -> The new product isn't selected Cause of the issue The CSS selector used for finding the record to edit was taking all tr element into account Solution Add the o_data_row to the selector opw-2632817 Forward-Port-Of: odoo/odoo#77355 Forward-Port-Of: odoo/odoo#76808
Original PR description
Steps to follow - Add an HTML field in the sales order line view - Create a sales order - Add a product - Add a table with multiple rows in the HTML widget - Add a new product -> The new product isn't selected Cause of the issue The CSS selector used for finding the record to edit was taking all tr element into account Solution Add the o_data_row to the selector opw-2632817 Forward-Port-Of: odoo/odoo#77355 Forward-Port-Of: odoo/odoo#76808
When the current app doesn't provide menu-items (or the user doesn't have the rights to access them), the mobile burger menu should fallback to the user menu instead of an empty one (like on the App Switcher). task-2345001 Forward-Port-Of: odoo/odoo#77189 Forward-Port-Of: odoo/odoo#77161
Original PR description
When the current app doesn't provide menu-items (or the user doesn't have the rights to access them), the mobile burger menu should fallback to the user menu instead of an empty one (like on the App Switcher). task-2345001 Forward-Port-Of: odoo/odoo#77189 Forward-Port-Of: odoo/odoo#77161
The pivot and graph views have been rewrote in owl in [1]. However, the former implemention has been kept as it is still used in some cases (e.g. board application, studio, PieChart widget), but they are lazy loaded [2]. Before this commit, both the new and former implementations mostly shared the same DOM (in particular, their root element had the same classnames). It means that the scss rules of an implementation might interfer with the other, and vice versa. This commit adds the "
Original PR description
The pivot and graph views have been rewrote in owl in [1]. However, the former implemention has been kept as it is still used in some cases (e.g. board application, studio, PieChart widget), but they…
The pivot and graph views have been rewrote in owl in [1]. However, the former implemention has been kept as it is still used in some cases (e.g. board application, studio, PieChart widget), but they are lazy loaded [2]. Before this commit, both the new and former implementations mostly shared the same DOM (in particular, their root element had the same classnames). It means that the scss rules of an implementation might interfer with the other, and vice versa. This commit adds the "legacy" keyword in the root classnames of those views, and properly namespaces the scss rules of legacy views to properly dissociate the style of new and legacy views. For the pivot view, we re-used the same scss file, so in this commit, we duplicate it (one for the new view, the other, lazy loaded, for the legacy view). [1] 0134495ba55bea16c2d11d5eb5d832edad575694 [2] bd3cf85c841168dfd87f7166b545dd00d9b38bf4 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#77294
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#77311
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#77311
The detail move button (`action_show_details`) should also return record component wizard in case of tracked component for a strict BoM. task-2637543 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#76057
Original PR description
The detail move button (`action_show_details`) should also return record component wizard in case of tracked component for a strict BoM. task-2637543 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#76057
Description of the issue/feature this PR addresses:`tz` field is technical field related to `resource_id`, which is required field on that model. However, it is possible to try to write a void value, which leads to an issue as it is technically required. Current behavior before PR:  Desired behavior after PR is merged: With this commit, we make the tz field required at w
Original PR description
Description of the issue/feature this PR addresses:`tz` field is technical field related to `resource_id`, which is required field on that model. However, it is possible to try to write a void value, which leads to an issue as it is technically required. Current behavior before PR:  Desired behavior after PR is merged: With this commit, we make the tz field required at write. Similar to the https://github.com/odoo/odoo/pull/42368 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#45557
Description of the issue/feature this PR addresses: General improvements to usability Time off type configuration visual : https://tinyurl.com/yj2z6okp When you create an allocation, the end date should have a place holder "no limit". If there is no end date recorded, that value should be displayed on loading. With previous point, when you create an allocation, add the validaty to the name of the allocation like "Allocation X (validity Date --> Date)" and hide the validity field in "My All
Original PR description
Description of the issue/feature this PR addresses: General improvements to usability Time off type configuration visual : https://tinyurl.com/yj2z6okp When you create an allocation, the end date…
Description of the issue/feature this PR addresses: General improvements to usability Time off type configuration visual : https://tinyurl.com/yj2z6okp When you create an allocation, the end date should have a place holder "no limit". If there is no end date recorded, that value should be displayed on loading. With previous point, when you create an allocation, add the validaty to the name of the allocation like "Allocation X (validity Date --> Date)" and hide the validity field in "My Allocations". User will have the information of the validity from the name of the allocation. In Overview, remove filter "people i manage" In Approvals / time off : change filters : https://i.imgur.com/uDNjZv8.png In Approvals / approvals : change filters like in point 5 (remove people I manage replace with my team) In Reporting / By Employee : filters : https://tinyurl.com/yg3u3rkf In Reporting / By Type : filters : https://tinyurl.com/yhbpgz5m Remove Allocations smartbutton from Employee App When you click on TimeOff Smartbutton from Employee App, you should be redirect to this screen : https://tinyurl.com/ygwxzx5b task-2643692 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#76851
Fix two issues found out based on task id #2655365 Fix a space in factur_x which would fail to find the name of the partner, thus never finding it even where it should have been able to. Raise a user error when trying to send&print an invoice that has no partner_id assigned. Forward-Port-Of: odoo/odoo#77365 Forward-Port-Of: odoo/odoo#77320
Original PR description
Fix two issues found out based on task id #2655365 Fix a space in factur_x which would fail to find the name of the partner, thus never finding it even where it should have been able to. Raise a user error when trying to send&print an invoice that has no partner_id assigned. Forward-Port-Of: odoo/odoo#77365 Forward-Port-Of: odoo/odoo#77320
Description of the issue/feature this PR addresses: If an invoice is posted, sended back to draft and the rate was change on res.currency, we preserve the value already existing on l10n_ar_currency_rate Current behavior before PR: l10n_ar_currency_rate is changed on an already posted invoie Desired behavior after PR is merged: l10n_ar_currency_rate should not be changed Video showing before: https://drive.google.com/file/d/1IPk8XrB_DJUJHRmPZg2RrsqOFImBJsQw/view Video showing aft
Original PR description
Description of the issue/feature this PR addresses: If an invoice is posted, sended back to draft and the rate was change on res.currency, we preserve the value already existing on l10n_ar_currency_rate Current behavior before PR: l10n_ar_currency_rate is changed on an already posted invoie Desired behavior after PR is merged: l10n_ar_currency_rate should not be changed Video showing before: https://drive.google.com/file/d/1IPk8XrB_DJUJHRmPZg2RrsqOFImBJsQw/view Video showing after: https://drive.google.com/file/d/1WP2f3xXMqtXYjkKLUwWWBHxURKYMR7bA/view -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#76715
Forward-Port-Of: odoo/odoo#77279
Original PR description
Forward-Port-Of: odoo/odoo#77279
Before this commit, a traceback was raise: Cannot read properties of undefined (reading 'displayNotification') Now, we correctly use self instead of this. task-2657621 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#77329
Original PR description
Before this commit, a traceback was raise: Cannot read properties of undefined (reading 'displayNotification') Now, we correctly use self instead of this. task-2657621 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#77329
Before this commit, the text color preview of the ribbons in the ribbon selector was wrong. But also, if we selected another ribbon just after changing the text color of a ribbon. This color was applied to the selected ribbon. task-2501515 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#76
Original PR description
Before this commit, the text color preview of the ribbons in the ribbon selector was wrong. But also, if we selected another ribbon just after changing the text color of a ribbon. This color was applied to the selected ribbon. task-2501515 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#76025
PURPOSE To fix the timer in survey. It should not be affected if user's system clock is behind or ahead of real time. SPECIFICATION Current: Let's consider the following two scenarios while answering time limited survey: 1) attendee's system clock is de-synchronized compared to the real time 2) Odoo server clock is de-synchronized compared to the real time In any/both of the above cases, it will lead to a wrong timer display, and will confuse the user and/or make him fail the t
Original PR description
PURPOSE To fix the timer in survey. It should not be affected if user's system clock is behind or ahead of real time. SPECIFICATION Current: Let's consider the following two scenarios while answering time limited survey: 1) attendee's system clock is de-synchronized compared to the real time 2) Odoo server clock is de-synchronized compared to the real time In any/both of the above cases, it will lead to a wrong timer display, and will confuse the user and/or make him fail the test because he will think he still has more time to submit when he does not. TO BE: To fix the timer in survey. It should not be affected in user's system clock is behind or ahead of real time. Task Id: 2612972 I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#75814
## Issue adressed: This commit aims to display in the analytic report the analytic accounts that are archived but used on the date range selected for the report. Archiving an account means we shouldn't be able to use this account anymore on new account_move. Not that it shouldn't be displayed in the analytical report. Because an example is worth a thousands explanation: let's say we have this: | account | balance | active | group | | :-------- | -------: | :------ | :------
Original PR description
## Issue adressed: This commit aims to display in the analytic report the analytic accounts that are archived but used on the date range selected for the report. Archiving an account means we…
## Issue adressed: This commit aims to display in the analytic report the analytic accounts that are archived but used on the date range selected for the report. Archiving an account means we shouldn't be able to use this account anymore on new account_move. Not that it shouldn't be displayed in the analytical report. Because an example is worth a thousands explanation: let's say we have this: | account | balance | active | group | | :-------- | -------: | :------ | :------ | | account_a | amount_a | False | group_x | | account_b | amount_b | True | group_x | ## Before this commit: display on the analytical report: | name | balance | | :-------- | ------------------: | | group_x | amount_a + amount_b | | account_b | amount_b | In this situation, first we can't see the account_b even if it was used in the current date range. Second, group_a displays an inconsistant amount considering the displayed information about the accounts. ## After this commit: display on the analytical report: | name | balance | | :-------- | ------------------: | | group_x | amount_a + amount_b | | account_a | amount_a | | account_b | amount_b | account_b is displayed if it has been used at least once in the report date range. closes opw-2585495 Forward-Port-Of: odoo/enterprise#21248 Forward-Port-Of: odoo/enterprise#20999
[FIX] account_bank_statement_import_camt: statement date formats When retrieving statement date, it can have two formats: date and datetime. Before this commit, we were only checking date format and returning a KeyError while both formats should be accepted. opw-2588209 ------------------------------------------------------- [FIX] account_bank_statement_import_camt/wizard: manage ITBD balance In case we have a statement having only an ITBD balance, before this commit, we were n
Original PR description
[FIX] account_bank_statement_import_camt: statement date formats When retrieving statement date, it can have two formats: date and datetime. Before this commit, we were only checking date format and…
[FIX] account_bank_statement_import_camt: statement date formats
When retrieving statement date, it can have two formats: date and datetime.
Before this commit, we were only checking date format and returning a KeyError
while both formats should be accepted.
opw-2588209
-------------------------------------------------------
[FIX] account_bank_statement_import_camt/wizard: manage ITBD balance
In case we have a statement having only an ITBD balance, before this commit, we were
not able to properly retrieve the date and the closing amount.
opw-2610371
-------------------------------------------------------
[FIX] account_bank_statement_import_camt: correct IBAN filtering
In case a statements file is targetting multiple journals, we extract only those
related to the current journal bank account. However we should sanitize the account
number to properly filter them and allow a correct import.
The corresponding test was also amended as the IBAN account number data should be
expected in a sanitized format : [a-zA-Z]{2,2}[0-9]{2,2}[a-zA-Z0-9]{1,30}.
To manage both cases, we should sanitize the account number from the XML anyway.
opw-2610371
-------------------------------------------------------
[FIX] account_bank_statement_import_camt: instructed amount in tx details
Before this commit, we were only looking for amount in tx details in
TransactionAmount or in CounterValueAmount elements. This can cause issue
if the amount in transaction details is only expressed in InstructedAmount
and if we have a batch containing several transactions, as we will retrieve
the total entry amount for each transaction instead. This commit adds the
management of instructed amount in transaction details to avoid this.
opw-2607742
-------------------------------------------------------
[FIX] account_bank_statement_import_camt: incorrect currency rate
In case the currency rate is provided in the counter value element, as CntrValAmt
is the countervalue in the account currency, we need to search the rate in the
target currency instead of the source currency. Otherwise, this will lead to an
incorrect conversion (division instead of multiplication). Some simplifications
were also made to remove unecessary rate_getters.
The existing multi currency test XML file was not correct and we need to fix the
rate to make it consistent with the actual related amounts in currencies.
opw-2620623
opw-2616481
opw-2641954
-------------------------------------------------------
Forward-Port-Of: odoo/enterprise#20419The field `entire_package_detail_ids` has been removed between 11.0 and 12.0, see: - https://github.com/odoo/odoo/commit/76662a0a667fa0188468e40bdb74836bf7d35268#diff-79cbc763115661182c02285c07320098510f5686700359ddee67443b4893dc30L281 - https://github.com/odoo/upgrade/blob/master/migrations/stock/saas%7E11.4.1.1/pre-migrate.py#L9 OPW-2586113 Forward-Port-Of: odoo/enterprise#21224 Forward-Port-Of: odoo/enterprise#21195
Original PR description
The field `entire_package_detail_ids` has been removed between 11.0 and 12.0, see: - https://github.com/odoo/odoo/commit/76662a0a667fa0188468e40bdb74836bf7d35268#diff-79cbc763115661182c02285c07320098510f5686700359ddee67443b4893dc30L281 - https://github.com/odoo/upgrade/blob/master/migrations/stock/saas%7E11.4.1.1/pre-migrate.py#L9 OPW-2586113 Forward-Port-Of: odoo/enterprise#21224 Forward-Port-Of: odoo/enterprise#21195
This commit fixes the issue where the assignees are badly (only the id is displayed) or not shown in gantt/map popover's. This commit improves the way the rpc calls are done in project gantt view, regarding the milestones. task-2650136 Forward-Port-Of: odoo/enterprise#21027
Original PR description
This commit fixes the issue where the assignees are badly (only the id is displayed) or not shown in gantt/map popover's. This commit improves the way the rpc calls are done in project gantt view, regarding the milestones. task-2650136 Forward-Port-Of: odoo/enterprise#21027
The button "Record Component" was always present. Due to ff4d25a427c33ac001de285dadc511049cf29158, the `display_action_record_components` wasn't correctly use. Use the new selection definition. task-2637543 Forward-Port-Of: odoo/enterprise#20608
Original PR description
The button "Record Component" was always present. Due to ff4d25a427c33ac001de285dadc511049cf29158, the `display_action_record_components` wasn't correctly use. Use the new selection definition. task-2637543 Forward-Port-Of: odoo/enterprise#20608
Task-2637489 Forward-Port-Of: odoo/enterprise#21214
Original PR description
Task-2637489 Forward-Port-Of: odoo/enterprise#21214
*web_cohort,web_dashboard,web_studio This commit is the counterpart of odoo/odoo#77294. We namespace the classname of the root element of legacy views that have been converted to owl, as both impementations are still kept (even though, the legacy one is lazy-loaded). That way, we prevent the scss rules of an implementation from interfering with the other, and vice versa. Forward-Port-Of: odoo/enterprise#21209
Original PR description
*web_cohort,web_dashboard,web_studio This commit is the counterpart of odoo/odoo#77294. We namespace the classname of the root element of legacy views that have been converted to owl, as both impementations are still kept (even though, the legacy one is lazy-loaded). That way, we prevent the scss rules of an implementation from interfering with the other, and vice versa. Forward-Port-Of: odoo/enterprise#21209
Update the fields that used jinja rendering enjine to qweb or inline_template. Nothing has changed functionnaly. Task ID: 27033 Related: odoo/odoo#70045 Related: odoo/enterprise#18576 Related: odoo/upgrade#2568 Forward-Port-Of: odoo/enterprise#21127
Original PR description
Update the fields that used jinja rendering enjine to qweb or inline_template. Nothing has changed functionnaly. Task ID: 27033 Related: odoo/odoo#70045 Related: odoo/enterprise#18576 Related: odoo/upgrade#2568 Forward-Port-Of: odoo/enterprise#21127