Thursday, February 9, 2023
36 changes · master
Enhancements to existing features
This update makes form button definitions easier and more consistent for Odoo developers, reducing confusion when configuring actions in forms. It keeps existing behavior working while introducing clearer button options, which should lower maintenance effort and reduce future mistakes.
Original PR description
The current form buttons are pretty wonky with @type/@name (the latter changing semantics based on type) versus @special, which makes them unnecessarily challenging to learn. Since there are 14 competing standards, develop a universal standard that covers all use cases! Lift `@type` to its own attributes matching `special`, and move `@name` to its value. Also remove support for action ids and thus (eventually) the need for interpolation altogether. Currently this is implemented as sugar over the existing model as the client does not support the new protocol. Possible alternative: move `special` over to `type="special"` and `name="$special-action`. Advantage is that reduces the number of attributes, drawback is that keeps the oddity of two linked attributes.
Live Chat channel setup text can now be translated, including the button label, default greeting, and input placeholder. This helps businesses provide a more localized chat experience for customers in different languages.
Original PR description
Description of the issue/feature this PR addresses: The following fields are used in the channel setting: 1. button_text 2. default_message 3. input_placeholder  but cannot translate them because fields are not translatable. PR makes those fields translatable. Current behavior before PR: We are not able to make translations to the above fields. Desired behavior after PR is merged: We are able to make translations to the above fields. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Resolved issues and error corrections
Subscription setup now hides billing periods that are not supported, such as hourly or daily recurrence options. This helps users choose valid subscription periods and prevents configuration mistakes.
Original PR description
Hide recurrence periode that are not compatible with subscriptions (hour & day units). task-id : 3101590
Code cleanup and technical improvements
This update simplifies the internal structure of Odoo's Point of Sale apps by removing an outdated shared component and moving responsibilities to clearer places. It should make future maintenance and improvements easier, with little to no direct change for daily users.
Original PR description
Miscellaneous changes
The problem happens when the company is Anglo Saxon, and `l10n_eg_edi_eta` is installed. Also, the product should have a cost and automatic inventory valuation. https://github.com/odoo/odoo/commit/4b430f8e30efb15f06982e4673cd73531a2119b3 The problem is that with this commit, after calling the `_set_next_sequence` function, it calls `flush_recordset`. It would cause a write to be triggered and add an Automatic Balancing Line. While in `_create_account_move` of PoS the stock output line will add
Original PR description
The problem happens when the company is Anglo Saxon, and `l10n_eg_edi_eta` is installed. Also, the product should have a cost and automatic inventory valuation.…
The problem happens when the company is Anglo Saxon, and `l10n_eg_edi_eta` is installed. Also, the product should have a cost and automatic inventory valuation. https://github.com/odoo/odoo/commit/4b430f8e30efb15f06982e4673cd73531a2119b3 The problem is that with this commit, after calling the `_set_next_sequence` function, it calls `flush_recordset`. It would cause a write to be triggered and add an Automatic Balancing Line. While in `_create_account_move` of PoS the stock output line will add later to it, and make it unbalanced. The first Automatic Balancing Line is incorrect as it will call `_create_stock_output_lines` later and it adds a line which makes it balance. But with that Automatic Balancing Line as it's unbalanced at the end it will call `_close_session_action` in PoS and shows a pop-up to add another line to make it balance. The solution is skip synchronize of journal entries. opw-3137723 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#110956
This update fixes form buttons that had conflicting behavior settings, making them easier to read and less prone to unexpected actions. It improves consistency across several business workflows, including helpdesk, field service, payroll, manufacturing, rentals, and timesheets.
*: pos_discount, pos_hr, pos_loyalty, pos_restaurant, pos_sale, pos_six Previously, all components in the pos and related apps would inherit from the PosComponent base component, this component…
*: pos_discount, pos_hr, pos_loyalty, pos_restaurant, pos_sale, pos_six Previously, all components in the pos and related apps would inherit from the PosComponent base component, this component contained a bunch of methods that were as such available on every component in the pos passively. In previous commits, a bunch of these methods have been moved either to the pos store or to their own services, so that component dependencies are explicit instead of every component having a clobbered namespace and having access to everything implictly. This commit factors out the last method of the PosComponent, `setSyncStatus` and as such the PosComponent is now empty and can be removed completely, as can the Gui singleton utility which was used to access these methods from outside of components. Components in the pos modules now inherit from LegacyComponent which PosComponent extended. The end goal is to remove the use of LegacyComponent as well, but currently it is still needed as components in the pos modules make extensive use of `useListener` which requires the shim for `this.el` provided by LegacyComponent. This is nonetheless a first step in that direction. This commit also removes some components that were used in the navbar as they were very small and it made more sense to just have the behaviour they implement directly in the navbar component or elsewhere. Most of the CashMoveButton was moved to the CashMovePopup, the TicketButton has so little behaviour that moving that behaviour to the navbar itself makes sense.
This update aligns the IoT and Point of Sale IoT components with recent platform changes so they continue to work with the latest shared code. It also corrects a naming typo to keep the enterprise and community versions consistent.
Original PR description
The corresponding community commit removes PosComponent completely, this commit adapts the code to use LegacyComponent instead. It also fixes a typo: `servicesDependencies` => `serviceDependencies` to use the same spelling as in community.
The fix that introduced `this._shouldDelayBlur = true` in `openMediaDialog` was wrong as it was fixing a symptom rather than the source of the problem. Later fix probably fixed the source of the problem as the problem is not reproducible at the time of this commit. If the symptom comes back, it ought to be fixed at it's source. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#112216
Original PR description
The fix that introduced `this._shouldDelayBlur = true` in `openMediaDialog` was wrong as it was fixing a symptom rather than the source of the problem. Later fix probably fixed the source of the problem as the problem is not reproducible at the time of this commit. If the symptom comes back, it ought to be fixed at it's source. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#112216
This commit add a mechanism to ensure that someone could never save changes from an history that diverge (in case there is a partition in the RTC network or a person A was disconnected while another person B saved changes that were not transmitted to person A). task-3002163 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#110241 Forward-Port-Of: odoo/odoo#106844
Original PR description
This commit add a mechanism to ensure that someone could never save changes from an history that diverge (in case there is a partition in the RTC network or a person A was disconnected while another person B saved changes that were not transmitted to person A). task-3002163 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#110241 Forward-Port-Of: odoo/odoo#106844
In 15.0 this was supported. It may be also handy when editing views to momentarily set the groups to `""`. Steps to reproduce: 1. Install Odoo 15 locally 2. Edit or create a view with `groups=""` for some component 3. Upgrade to 16. It fails. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#112062
Original PR description
In 15.0 this was supported. It may be also handy when editing views to momentarily set the groups to `""`. Steps to reproduce: 1. Install Odoo 15 locally 2. Edit or create a view with `groups=""` for some component 3. Upgrade to 16. It fails. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#112062
[FIX] website, *: fix some components in case of contrasted boxed layout *: website_slides In some cases, components had dark text over dark background (or light text over light background) by mistake. Example: - Enter edit mode. - In the theme tab, choose "boxed" as page layout. - A color picker appears below to control the color behind the box. - Set it to a dark color (if your box main color is light) - Go to a course page (install website_slides) - Check the mobile version =
Original PR description
[FIX] website, *: fix some components in case of contrasted boxed layout *: website_slides In some cases, components had dark text over dark background (or light text over light background) by…
[FIX] website, *: fix some components in case of contrasted boxed layout
*: website_slides
In some cases, components had dark text over dark background (or light
text over light background) by mistake.
Example:
- Enter edit mode.
- In the theme tab, choose "boxed" as page layout.
- A color picker appears below to control the color behind the box.
- Set it to a dark color (if your box main color is light)
- Go to a course page (install website_slides)
- Check the mobile version
=> The bootstrap tab and its section uses the dark color you set up as
body color instead of the expected boxed layout color.
Another example:
- Do the same thing (set up a dark color behind a boxed layout).
- Go to a shop / product page.
=> The inputs are dark with dark text.
This is because of bootstrap which uses `$body-bg` as default value for
other variables, such as `$nav-tabs-link-active-bg` in the first case
described above. It also uses the variable in the creation of CSS rules
not controlled by explicit variables.
In 16.0, bootstrap was updated to 5.1.3 with [1] and this actually
increased the problem: input backgrounds now default to `$body-bg`,
amongst other things. Since [2], `$body-bg` is also used as the default
color for range thumbs.
In previous versions, this fix focused on fixing a critical component:
nav-tabs, for which the fix was straightforward.
Starting from 16.0, this commit will fix everything at the small risk of
changing the `$body-bg` variable meaning in the case of boxed layouts.
Before this commit, its meaning was "the color used for the background
behind the boxed layout (the <body> background color)", so equal to the
Odoo value `o-color('body')`. After this commit, its meaning will be
"the color used for the background of the box itself", so equal to
`o-color('o-cc1-bg')`. The `<body>` background color will be forced by
using `o-color('body')` as the value for the related *CSS* variable
defined by bootstrap. This allows to have a correct CSS generation for
all components in case of boxed layouts: indeed, the components mix
their own color with `$body-bg` (or use it as it is) relying on the fact
this is the color which appears behind them... which was not right in
case of boxed layouts.
This commit actually fixes another bug that was found during adaptation.
It is 2-fold, and unfortunately, it does not make sense to fix one part
without the other as it would increase the problem without the other
part. The website_slides pages customize their default background color
to not be the one chosen by the user, but a mix of it with some
lightgray. Odoo default for the body being white, this makes it a
lightgray for website_slides pages. This is totally ok... but only in
"full" layout. In boxed layout, we have the 2-fold problem:
A. The mixed color is not applied to the boxed layout but on the
background behind the box. So if you have a white box above a black
background, in website_slides pages you won't have the black
background you expected to keep but a lighter version of it and the
website_slides box will not use the lightgray but stay white
(creating other inconsistencies as the lightgray would also be used
by other components like tabs, for that app only).
B. The mixed color is actually not mixing the right colors: it mixes
the hardcoded lightgray with the color of the background behind the
box, while it was intended to be the one of the content (the one of
the box), like in "full" layout.
The changes explained above about `$body-bg` naturally fixes (B). Not
fixing (A) at the same time would result in a big change for the color
which is behind the box. This commit fixes it at the same time by now
applying the color to the right element. In previous version, this could
be fixed as well but would require a different fix (not relying on
`$body-bg`). So it makes sense to merge this first and backport+adapt.
[1]: https://github.com/odoo/odoo/commit/971e5a91aab96d36129a823e03f1f9f1b1293968
[2]: https://github.com/odoo/odoo/commit/46e53879749be7ba3d30338d0f25c0a68a88eb3c
opw-3151962
| Before | After |
|-----------|---------|
|  |  |
| Before | After |
|-----------|---------|
|  |  |
| Before | After |
|-----------|---------|
|  |  |
| Before | After |
|-----------|---------|
|  |  |
Forward-Port-Of: odoo/odoo#112136
Forward-Port-Of: odoo/odoo#111780Follow-up reports were not going through due to the background clipping into the address area. Forward-Port-Of: odoo/odoo#109615
Original PR description
Follow-up reports were not going through due to the background clipping into the address area. Forward-Port-Of: odoo/odoo#109615
Starting the Odoo server with more than one worker results in repeated "Bus unavailable" exceptions in the server log. This seems related to the change made at https://github.com/odoo/odoo/commit/a2ed3d3d5bdb6025a1ba14ad557a115a86413e65. Investigation shows the the bus model file is loaded before gevented mode is started, and thus the wroker won't have the ImDispach available. Port of https://github.com/odoo/odoo/pull/90030. --- I confirm I have signed the CLA and read the PR guidel
Original PR description
Starting the Odoo server with more than one worker results in repeated "Bus unavailable" exceptions in the server log. This seems related to the change made at https://github.com/odoo/odoo/commit/a2ed3d3d5bdb6025a1ba14ad557a115a86413e65. Investigation shows the the bus model file is loaded before gevented mode is started, and thus the wroker won't have the ImDispach available. Port of https://github.com/odoo/odoo/pull/90030. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#112068 Forward-Port-Of: odoo/odoo#111352
Description of the issue/feature this PR addresses: signed odoo agreement --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#112259
Original PR description
Description of the issue/feature this PR addresses: signed odoo agreement --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#112259
Current behavior: When paying with a worldline terminal, the receipt is printed with <br/> tags at the end of the receipt. Steps to reproduce: - Setup the worldline terminal and the IoT Box - Open a POS session - Pay with the worldline terminal - The receipt contains the `<br/>` tags opw-3051722 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#111495 Forward-Port-Of: odoo/odoo#110845
Original PR description
Current behavior: When paying with a worldline terminal, the receipt is printed with <br/> tags at the end of the receipt. Steps to reproduce: - Setup the worldline terminal and the IoT Box - Open a POS session - Pay with the worldline terminal - The receipt contains the `<br/>` tags opw-3051722 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#111495 Forward-Port-Of: odoo/odoo#110845
Steps to reproduce the bug: - Drop a block steps on a page - Change one of the icons - Change the color of the icon => The connectors are not correct anymore. This is due to [this commit] changing the tag `<i class="fa...` to a `<span class="fa...` when the user replaces an icon. The steps options assume that `<i/>` tags will remain `<i/>` tags (as it was before [this commit]). We should not change the tagName when changing the icon of an `<i/>` tag. This is likely to break (s)css,
Original PR description
Steps to reproduce the bug:
- Drop a block steps on a page
- Change one of the icons
- Change the color of the icon
=> The connectors are not correct anymore.
This is due to [this commit] changing the tag `<i class="fa...` to a
`<span class="fa...` when the user replaces an icon. The steps options
assume that `<i/>` tags will remain `<i/>` tags (as it was before
[this commit]). We should not change the tagName when changing the icon
of an `<i/>` tag. This is likely to break (s)css, options, public
widgets, ... This commit fixes this bug by ensuring that `<i/>` tags do
not become `<span>` tags when replacing the icon. Moreover it allows not
to recreate an editor when you change the icon.
[this commit]: https://github.com/odoo/odoo/commit/7fd0698cf765a79959566b51e33cb76bff83d344
task-3068834
opw-3123850
Additional info:
To have a look to how it was working before, grep `if (!this.$media.is('span, i')) {` before 16.0
Forward-Port-Of: odoo/odoo#106316Prior to these changes the shadow wasn't rendered on Safari. This commit introduces a pseudo-element that mimics the shadow effect. Since browsers behave differently when it comes about sticky table's elements, it's unfortunately not possible to use a simpler approach (eg. applying a shadow to the `<thead>` directly). The commit will also replace raw-CSS with the o-position-sticky() mixin and provides the CSS hook to handle dark-mode correctly. related: - https://github.com/odoo/enterp
Original PR description
Prior to these changes the shadow wasn't rendered on Safari. This commit introduces a pseudo-element that mimics the shadow effect. Since browsers behave differently when it comes about sticky table's elements, it's unfortunately not possible to use a simpler approach (eg. applying a shadow to the `<thead>` directly). The commit will also replace raw-CSS with the o-position-sticky() mixin and provides the CSS hook to handle dark-mode correctly. related: - https://github.com/odoo/enterprise/pull/35981 original task: task-3126127 task-3141304 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#110304
Before this commit, if a many2x fall the quickcreate, it will fall back correctly to the slow create, but it will also raise an error. Now, the error is not raised anymore. Forward-Port-Of: odoo/odoo#112201
Original PR description
Before this commit, if a many2x fall the quickcreate, it will fall back correctly to the slow create, but it will also raise an error. Now, the error is not raised anymore. Forward-Port-Of: odoo/odoo#112201
The access rights tests would fail on databases created on day 0 and test executed on day 1 because of the stress day demo data, they would overlap. Testing for stress days' access rights are done in dedicated tests, thus it's ok to delete all the existing ones here. Forward-Port-Of: odoo/odoo#112266
Original PR description
The access rights tests would fail on databases created on day 0 and test executed on day 1 because of the stress day demo data, they would overlap. Testing for stress days' access rights are done in dedicated tests, thus it's ok to delete all the existing ones here. Forward-Port-Of: odoo/odoo#112266
To reproduce the issue: (Use demo data) 1. In Settings, enable "Multi Locations" 2. Create a storable and tracked-by-lot product P 3. Create an immediate receipt R 4. Add a line for 1 x P and save 5. Open the wizard 'Detailed Operations' and add a line: - 1 x P, lot 123, to WH/Stock/Shelf 1 6. Save 7. Open the wizard again Error: The destination location of the line is now WH/Stock When creating the SML, because we write on its done quantity, we will automatically write the sa
Original PR description
To reproduce the issue: (Use demo data) 1. In Settings, enable "Multi Locations" 2. Create a storable and tracked-by-lot product P 3. Create an immediate receipt R 4. Add a line for 1 x P and save 5.…
To reproduce the issue: (Use demo data) 1. In Settings, enable "Multi Locations" 2. Create a storable and tracked-by-lot product P 3. Create an immediate receipt R 4. Add a line for 1 x P and save 5. Open the wizard 'Detailed Operations' and add a line: - 1 x P, lot 123, to WH/Stock/Shelf 1 6. Save 7. Open the wizard again Error: The destination location of the line is now WH/Stock When creating the SML, because we write on its done quantity, we will automatically write the same on the new done quantity of the SM on the demand of that SM. Doing so, it will trigger the assign process: https://github.com/odoo/odoo/blob/57ac92fc4c14bf305ffd9ef98212cc80013345f5/addons/stock/models/stock_move.py#L599-L602 (And it will therefore lead to the putaway rules feature) Once the above issue is fixed, there will be another one. When marking the SML as done, if it's needed, we assign it a lot. However, writing on such a field will trigger the reservation process: https://github.com/odoo/odoo/blob/c9fdd4f2ac2d8afb18cb0dd126bb0b88c54f374e/addons/stock/models/stock_move_line.py#L330-L333 And it will lead, again, to the putaway rules feature OPW-3086704 Forward-Port-Of: odoo/odoo#112267 Forward-Port-Of: odoo/odoo#111993
## Current behaviour If you export a view with a (some) filters and you set a custom layout in the dashboard, you will get a traceback, preventing you for accessing your newly exported dashboard. ## Expected behaviour Should not crash when trying to view your exported view, even with a custom domain. ## Steps to reproduce - Install Dashboard, Sales - Export from Sales > List View with a filter Creation Date before XX:XX (date is irrelevant) - Go to Dashboard > My Dashboard > Change La
Original PR description
## Current behaviour If you export a view with a (some) filters and you set a custom layout in the dashboard, you will get a traceback, preventing you for accessing your newly exported dashboard. ##…
## Current behaviour If you export a view with a (some) filters and you set a custom layout in the dashboard, you will get a traceback, preventing you for accessing your newly exported dashboard. ## Expected behaviour Should not crash when trying to view your exported view, even with a custom domain. ## Steps to reproduce - Install Dashboard, Sales - Export from Sales > List View with a filter Creation Date before XX:XX (date is irrelevant) - Go to Dashboard > My Dashboard > Change Layout to something else - Exit the page and retry to reopen it, a stacktrace is shown. ## Reason for the problem When preprocessing the arch of the view in the dashboard, which is an xml string, there is the domain included, which contains symbols that are unparsable by `etree` unless escaped (like `<`). ## Fix Escape the domain client side before being sent and saved in the database, so when requesting it we don't have a parsing error. Then we unescape it when the clients reads the domain from the server. The unescaping before escaping is to avoid problem of double escaping when changing subsequently the layout of the board view. ## Affected versions - 16.0 - saas-16.1 - master --- opw-3130117 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#110662
Usecase to reproduce: - Set the warehouse as 3 steps receipt - Put a security delay of 3 days for purchase - Set a product with a vendor and 1 days as LT - Replenish with the order-point You expect to have a schedule date for tomorrow that contains all the product needed in the incoming 4 days. Currently the internal transfer from QC -> Stock is for tomorrow (ok). The transfer from Input -> QC is plan for 2 days in the past. (not ok) The PO date is plan for 5 days in the past. (not
Original PR description
Usecase to reproduce: - Set the warehouse as 3 steps receipt - Put a security delay of 3 days for purchase - Set a product with a vendor and 1 days as LT - Replenish with the order-point You expect…
Usecase to reproduce: - Set the warehouse as 3 steps receipt - Put a security delay of 3 days for purchase - Set a product with a vendor and 1 days as LT - Replenish with the order-point You expect to have a schedule date for tomorrow that contains all the product needed in the incoming 4 days. Currently the internal transfer from QC -> Stock is for tomorrow (ok). The transfer from Input -> QC is plan for 2 days in the past. (not ok) The PO date is plan for 5 days in the past. (not ok) It happens because the system check at each `stock.rule` application if purchase is part of the route. If it's then it applies the security lead time. It's a mistake because we should apply it only the first time. To fix it we directly set it when the orderpoint run and not during `stock.move` creation. However for MTO it's not that easy. We don't want to deliver too early the customer. So we keep applying the delay during the `stock.move` creation but only when it goes under the warehouse stock location. Forward-Port-Of: odoo/odoo#109640
Steps: - Create new rate in random currency (for example USD) - Try to put 0 in USD per Unit - Try to put 0 in Unit per USD Two errors are raised: ZeroDivisionError and Expected singleton sentry-3916858495 sentry-3767286632 Forward-Port-Of: odoo/odoo#112277
Original PR description
Steps: - Create new rate in random currency (for example USD) - Try to put 0 in USD per Unit - Try to put 0 in Unit per USD Two errors are raised: ZeroDivisionError and Expected singleton sentry-3916858495 sentry-3767286632 Forward-Port-Of: odoo/odoo#112277
### Steps to reproduce * Have Arabic language installed * Create an invoice * Register a partial payment (keep invoice open) * Switch to Arabic language * Click the register payment again => You should be met with a traceback ### Cause Currently, the `parseDate` function relies on `parseDateTime`. If no format is passed to `parseDateTime` (like in our case), the user's `localization.dateTimeFormat` is used. `parseDateTime` implements workarounds to allow parsing of dates (without a t
Original PR description
### Steps to reproduce * Have Arabic language installed * Create an invoice * Register a partial payment (keep invoice open) * Switch to Arabic language * Click the register payment again => You should be met with a traceback ### Cause Currently, the `parseDate` function relies on `parseDateTime`. If no format is passed to `parseDateTime` (like in our case), the user's `localization.dateTimeFormat` is used. `parseDateTime` implements workarounds to allow parsing of dates (without a time). However, those workarounds do not work with languages such as Arabic. opw-3133992 Forward-Port-Of: odoo/odoo#111735
Setup MX Company with external trade partner Create an invoice for the external trade partner Add an invoice line with "Customs number" Confirm Invoice will be rejected by SAT with error: """ Code : CFDI40195 Message : El NumeroPedimento no debe existir si se incluye el complemento de comercio exterior. """ Customs numbers shall not be reported with comercio exterior opw-3070322 Forward-Port-Of: odoo/enterprise#35942
Original PR description
Setup MX Company with external trade partner Create an invoice for the external trade partner Add an invoice line with "Customs number" Confirm Invoice will be rejected by SAT with error: """ Code : CFDI40195 Message : El NumeroPedimento no debe existir si se incluye el complemento de comercio exterior. """ Customs numbers shall not be reported with comercio exterior opw-3070322 Forward-Port-Of: odoo/enterprise#35942
On a MO, if a WO consumes several times the same tracked-by-sn component, and if the user consumes the SN in a different order than the default one, it will create an inconsistency on the SNs' reservation To reproduce the issue: 1. Create two storable products P_compo, P_finished - P_compo: - Tracking: Serial 2. Update on-hand qty of P_compo: - 1 x SN01 - 1 x SN02 3. Create a BoM: - Product: P_finished - Operations: - A new operation OP - Components:
Original PR description
On a MO, if a WO consumes several times the same tracked-by-sn component, and if the user consumes the SN in a different order than the default one, it will create an inconsistency on the SNs'…
On a MO, if a WO consumes several times the same tracked-by-sn
component, and if the user consumes the SN in a different order than
the default one, it will create an inconsistency on the SNs' reservation
To reproduce the issue:
1. Create two storable products P_compo, P_finished
- P_compo:
- Tracking: Serial
2. Update on-hand qty of P_compo:
- 1 x SN01
- 1 x SN02
3. Create a BoM:
- Product: P_finished
- Operations:
- A new operation OP
- Components:
- 2 x P_compo, consumed in OP
4. Confirm a MO for 1 x P_finished
5. Open the tablet view of OP
- SN01 should be the suggested
6. Set SN02
7. Continue consumption
- Error01: SN02 is suggested but it has been used in the step
before. Also, if the user opens the detailed operations of the
raw move, he will see that the reservation of SN01 does not
exist anymore
8. Set SN01
9. Validate
10. Check the detailed operations of the raw move
Error: The situation is not that consistent because there is now a
reservation for SN01 but not for SN02
Once the MO is confirmed, both SN are reserved. Step 6, we assign
SN02 on the first SML (i.e. the one that reserves SN01). As a result,
we unreserve SN01 and try to reserve SN02 (this reservation will not
work since SN02 is already reserved by the second SML)
Then, step 8: we change the lot of the second SML so we first
unreserve it (-> we unreserve SN02) then we try to reserve the new
SN (-> it reserves SN01)
When we assign a lot on a SML, we should check if there already
exists another SML that reserves the lot.
OPW-3104930
Forward-Port-Of: odoo/enterprise#36856
Forward-Port-Of: odoo/enterprise#36806when inserting an appointment link. This commit fixes an issue introduced by [1]: in a form view with chatter (e.g. crm.lead), click on Send message, open the full composer, in the dialog, type / in the message body and select Appointment in the dropdown (it should open a dialog), set a value in the record and click on Insert Link. Before this commit, the two dialogs was closed, so basically, it wasn't possible to add an appointment link in a message from the full composer. The reason it c
Original PR description
when inserting an appointment link. This commit fixes an issue introduced by [1]: in a form view with chatter (e.g. crm.lead), click on Send message, open the full composer, in the dialog, type / in…
when inserting an appointment link. This commit fixes an issue introduced by [1]: in a form view with chatter (e.g. crm.lead), click on Send message, open the full composer, in the dialog, type / in the message body and select Appointment in the dropdown (it should open a dialog), set a value in the record and click on Insert Link. Before this commit, the two dialogs was closed, so basically, it wasn't possible to add an appointment link in a message from the full composer. The reason it closes the full composer dialog is because the clicked button is 'special="save"', which means that the record will be saved, and an "ir.actions.act_window_close" will be executed, which closes the dialog. This commit fixes the issue by bypassing the normal framework behavior for the two footer buttons of the appointment dialog, s.t. the record is saved and the link is added (if necessary), and the appointment dialog (and only that one) is closed. [1] 121a7717e3e0b104ac6726681f1f009774e4f8c9 Forward-Port-Of: odoo/enterprise#36813
Selecting a number of kilometers for Private Bike had no impact on the simulation, the NET amount was not updated. Now we consider cycling 4 days a month to work for the simulation. Forward-Port-Of: odoo/enterprise#36803
Original PR description
Selecting a number of kilometers for Private Bike had no impact on the simulation, the NET amount was not updated. Now we consider cycling 4 days a month to work for the simulation. Forward-Port-Of: odoo/enterprise#36803
Accounting tests may not work during installation if some configuration hasn't been done yet. ERRORS ``` TestCommissions.test_refund: odoo.exceptions.UserError: You can't create a new payment without an outstanding payments/receipts account set either on the company or the Manual payment method in the ... journal. TestSaleOrder.test_so_referrer_id_to_invoice: psycopg2.errors.CheckViolation: new row for relation "account_move_line" violates check constraint "account_move_line_c
Original PR description
Accounting tests may not work during installation if some configuration hasn't been done yet. ERRORS ``` TestCommissions.test_refund: odoo.exceptions.UserError: You can't create a new payment without an outstanding payments/receipts account set either on the company or the Manual payment method in the ... journal. TestSaleOrder.test_so_referrer_id_to_invoice: psycopg2.errors.CheckViolation: new row for relation "account_move_line" violates check constraint "account_move_line_check_accountable_required_fields" ``` STEPS: Create a dev build at odoo.sh that installs only `partner_commission` opw-3119579 Forward-Port-Of: odoo/enterprise#36852
Steps to reproduce: - Create an account group: Sales from 40 to 49 - In Account Reports/Profit and Loss, in options set it as optionnal - In Reporting/Profit and Loss, in options set "Hierarchy and Subtotals" Issue: Traceback Cause: Indent error opw-3165628 Forward-Port-Of: odoo/enterprise#36748
Original PR description
Steps to reproduce: - Create an account group: Sales from 40 to 49 - In Account Reports/Profit and Loss, in options set it as optionnal - In Reporting/Profit and Loss, in options set "Hierarchy and Subtotals" Issue: Traceback Cause: Indent error opw-3165628 Forward-Port-Of: odoo/enterprise#36748
depends on: - https://github.com/odoo/odoo/pull/110304 task-3141304 Forward-Port-Of: odoo/enterprise#35981
Original PR description
depends on: - https://github.com/odoo/odoo/pull/110304 task-3141304 Forward-Port-Of: odoo/enterprise#35981
Current behavior: When paying with a worldline terminal, the receipt is printed with tags at the end of the receipt. Steps to reproduce: -Setup the worldline terminal and the IoT Box -Open a POS session -Pay with the worldline terminal -The receipt contains the `<br/>` tags opw-3051722 Forward-Port-Of: odoo/enterprise#36546 Forward-Port-Of: odoo/enterprise#36455
Original PR description
Current behavior: When paying with a worldline terminal, the receipt is printed with tags at the end of the receipt. Steps to reproduce: -Setup the worldline terminal and the IoT Box -Open a POS session -Pay with the worldline terminal -The receipt contains the `<br/>` tags opw-3051722 Forward-Port-Of: odoo/enterprise#36546 Forward-Port-Of: odoo/enterprise#36455
Steps to reproduce: - open IoT app - click on Devices (i.e. open any iot.device view) - open a iot.device record (i.e. try to open form view) Expected result: record opens without issue Actual result: OWL-related stacktrace Issue was due to various js refactorings resulting in a missing required setup.super(), which caused the component extension to fail. Forward-Port-Of: odoo/enterprise#36800
Original PR description
Steps to reproduce: - open IoT app - click on Devices (i.e. open any iot.device view) - open a iot.device record (i.e. try to open form view) Expected result: record opens without issue Actual result: OWL-related stacktrace Issue was due to various js refactorings resulting in a missing required setup.super(), which caused the component extension to fail. Forward-Port-Of: odoo/enterprise#36800
Before this PR, a published shared article was placed into "Public Articles". This is not correct as they are not public. If the article was not shared with you specifically, the article was still available in the public article section. In this case, articles should behave like published prvate article: They are available if you have the direct link but they are not displayed in the side panel. If the article is shared with you specifically, the article should be in "Shared with you"
Original PR description
Before this PR, a published shared article was placed into "Public Articles". This is not correct as they are not public. If the article was not shared with you specifically, the article was still…
Before this PR, a published shared article was placed into "Public Articles". This is not correct as they are not public. If the article was not shared with you specifically, the article was still available in the public article section. In this case, articles should behave like published prvate article: They are available if you have the direct link but they are not displayed in the side panel. If the article is shared with you specifically, the article should be in "Shared with you" section, instead of "Public Articles" section. After this PR, the articles are listed as the following: 'Public Article': Published workspace articles 'Shared with you': - non-Published Workspace article you are member of (r/w) - Shared article you are member of (r/w) Thus, published shared articles (not shared with you) are not listed, the same way published private articles are still not listed. This PR also fixes the fact the show_sidebar was not properly evaluated under default condition. Task-3140578 Forward-Port-Of: odoo/enterprise#35967
[IMP] account_reports: allow rounding aggregation expressions with new subformula Ona aggrations, it is now possible to use a subformula in the form 'round(x)', where x is a number of decimal places to keep. This is required by current work on l10n_fr's tax report, where the carryover amount needs to be an integer. [FIX] account_reports: correct computation of cross_report expressions referring to the same line with different date_scope When using two cross_report expressions calling
Original PR description
[IMP] account_reports: allow rounding aggregation expressions with new subformula Ona aggrations, it is now possible to use a subformula in the form 'round(x)', where x is a number of decimal places…
[IMP] account_reports: allow rounding aggregation expressions with new subformula Ona aggrations, it is now possible to use a subformula in the form 'round(x)', where x is a number of decimal places to keep. This is required by current work on l10n_fr's tax report, where the carryover amount needs to be an integer. [FIX] account_reports: correct computation of cross_report expressions referring to the same line with different date_scope When using two cross_report expressions calling the same expression from another report with different date_scope values (typically, a Balance Sheet calling the Profit and Loss from this year and the previous year), the computed amount was wrong: both lines always were evaluated to the same value. This was because the grouping made on aggregations to get their result was totally disregarding the date_scope, and stored the result of both expressions under the same key. [IMP] account_reports: introduce if_other_expr_above/if_other_expr_above subformulas on aggregations Some reports expression need conditional values depending on another expression. For example, report line A could be defined as the value of report line B if B > 0 else something else. Currently, there is not clean we of supporting this case. Therefore, we introduce two new subformulas on aggregation expressions: if_other_expr_above and if_other_expr_below. Here is an example of how to use this new feature: * label : result * engine : aggregation * formula : a_line.balance + another_line.balance * subformula : if_other_expr_above(criterium_line.balance, EUR(25)) => If criterium_line.balance > 25€, result will be evaluated as the sum of a_line.balance and another_line.balance => If criterium_line.balance <= 25€, result will be evaluated as 0 Doing and if/else condition with this can hence be done with two opposite if_other_expr_* expressions, and one more aggregation summing them both. Example: - expr 1: if_other_expr_above(EUR(25)) (IF part) - expr 2: if_other_expr_below(EUR(25.01)) (ELSE part) - expr 3: expr 1 + expr 2 Forward-Port-Of: odoo/enterprise#36670
…ence_uniq Before this commit, when multiple transaction were done at the same time, inside the same freeze_time block, the transactions would get the same reference and trigger the constraint payment_transaction_reference_uniq. Forward-Port-Of: odoo/enterprise#36795
Original PR description
…ence_uniq Before this commit, when multiple transaction were done at the same time, inside the same freeze_time block, the transactions would get the same reference and trigger the constraint payment_transaction_reference_uniq. Forward-Port-Of: odoo/enterprise#36795