Usecase to reproduce:
Create a replenishment of warehouses sheme. E.g:
Production WH -> Distribution WH -> Shops
Set all the rules from SHOP to PRODUCTION as replenish on order.
Go to the replenishment report. Usererror due to a loop in the
rules.
It's wrong because he found twice the same rule that pull from
interwarehouse transit. Fix the code to handle intertransit rules
closesodoo/odoo#112325
X-original-commit: ca8e7aedcb466a301f721579ece85749ce4b060b
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
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 orderpoint
You expect to have a schedule date for tomorrow that contains all the
product needed in the incoming 4 days.
Currenly the internal transfer from QC -> Stock is for tomorrow (ok).
The transfer from Inpur -> 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.
X-original-commit: 97f52bd40d97109a7983549d252476959ddceada
Part-of: odoo/odoo#112325
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
closesodoo/odoo#112334
X-original-commit: bfadb8e491fe2acda63a79f9577eaaec8a1c8d9c
Signed-off-by: Géry Debongnie <ged@odoo.com>
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
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
closesodoo/odoo#112322
X-original-commit: a3f6cefbbe81bafc0780a95729b8f9150afef817
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
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.
closesodoo/odoo#112312
X-original-commit: 3a2fd05026c0b0ae7fb852f59d1a74f0fc3db3b2
Signed-off-by: Kevin Baptiste <kba@odoo.com>
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.
closesodoo/odoo#112311
X-original-commit: 800e7ab6658b013930e6691cf778bb425da3e723
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
Prior to these changes the shadow wasn't rendered on Firefox and 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.
original task: task-3126127
task-3141304
closesodoo/odoo#112304
X-original-commit: 108792e29846a6ba944581728702868675208e23
Related: odoo/enterprise#36865
Signed-off-by: Romeo Fragomeli (rfr) <rfr@odoo.com>
*: 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.
closesodoo/odoo#112295
Related: odoo/enterprise#36860
Signed-off-by: Heinz Robin (rhe) <rhe@odoo.com>
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
closesodoo/odoo#112252
X-original-commit: 93eeaf538c24e7b7ee304c4323cc27bf786f261b
Signed-off-by: Outagant Mehdi (mou) <mou@odoo.com>
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
closesodoo/odoo#111956
X-original-commit: 10eea9aeeb2ffe2bb55adf70632e9467272b00a2
Related: odoo/enterprise#36711
Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>
Signed-off-by: Engels Robin (roen) <roen@odoo.com>
In French accounting, they need to provide a FEC file to the auditors/tax authority to control their accounting. So far it's fine in Odoo.
While a company is managing IFRS accounting, the usual way to do it in Odoo is to use a specific journal "IFRS adjustments" for example. This way of working allows you to have a balance in local GAAP (excluding IFRS entries) and in IFRS GAAP (including the IFRS entries). So far it's fine in Odoo.
The issue that we met is once a customer need to send his FEC file to the auditors/tax authority, he needs to send only local entries (then excluding IFRS entries). Therefore, it would be great to have an option to exclude some journals from the FEC export.
closesodoo/odoo#110655
Task: 3133678
Signed-off-by: Florian Gilbert (flg) <flg@odoo.com>
Currently there is no distinction between saved tokens and providers
and there is no info on tokens under what provider they were created.
When client has more than one token it looks messy and counters the
point of token existance. Now tokens have their creation date,provider
and are no longer in the same card as providers.
task-2510973
closesodoo/odoo#108260
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Follow-up reports were not going through due to the background clipping
into the address area.
closesodoo/odoo#112297
X-original-commit: aa13f9c60140387079b183869ca0c0ce99afec56
Signed-off-by: Florian Daloze (fda) <fda@odoo.com>
Signed-off-by: Solan Delvenne (sode) <sode@odoo.com>
*: 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
closesodoo/odoo#112254
X-original-commit: 14c985af526602a88666714e716283650521e537
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
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.
Empty groups was allowed in 15.0 we want to ensure this is not broken
unintentionally anymore, such a new test was added.
Muted logged to hide the warning (also present in 15.0):
```
2023-02-08 11:09:18,697 506777 WARNING test_16_gr odoo.addons.base.models.ir_ui_view: The group '' defined in view does not exist!
View error context:
{'file': None,
'line': 3,
'name': 'foo',
'view': ir.ui.view(242,),
'view.model': 'res.partner',
'view.parent': ir.ui.view(),
'xmlid': ''}
```
closesodoo/odoo#112246
X-original-commit: 4379dce95edcc34a8e97e73a3bdaa2e20fdc79a8
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
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
closesodoo/odoo#112099
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
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.
closesodoo/odoo#112245
X-original-commit: 0dd9da029d58652123ea71085dbb3a1a1e93e77d
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Be able to add multipe checks payment method on journal
accountamatata task 3130305
closesodoo/odoo#109774
Signed-off-by: Nicolas Viseur (vin) <vin@odoo.com>
Before this change the manual payment method was the only one
that can be use more than once on a journal configuration.
With this change we add a new method in order to be more heritable
and be able to add other reusable payment methods
accountamatata task 3130305
Part-of: odoo/odoo#109774
The problem happens when the company is Angelo 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
closesodoo/odoo#112238
X-original-commit: 890b685e94383491579258093f934b7143612b80
Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>
Signed-off-by: Pedram Bi Ria (pebr) <pebr@odoo.com>
As it is now possible to activate the total amount of an invoice in letters, these localizations (dz,in,ua,ma) need by default the feature to be activated. In addition, some of them had aleady such feature which has therefore been removed to accommodate the new generic feature.
The indian localization also has a different message on the right side of QR code on invoices
closesodoo/odoo#107714
Task: 3097097
Pr: 107714
Related: odoo/enterprise#35959
Signed-off-by: Florian Gilbert (flg) <flg@odoo.com>
Modifies the invoice layout according to the mockup provided in the task. This enables to remove the blank space that occured in the middle of the invoices
Add the possibility to add the total amount of an invoice in words. This feature can be enabled by activating a boolean setting in Accounting settings.
Task: 3097097
Pr: 107714
Part-of: odoo/odoo#107714
This commit fixes a change in behavior between 15.2 and 15.3.
Previously, if an unidentified user tried to reach a route that had auth='user', it would simply redirect to the login page.
Currently, it redirects and invalidates the session_id.
This is an issue in the latest version of master after this PR https://github.com/odoo/enterprise/pull/36521
This commit changes the route of service-worker.js to auth='user'.
This route is called on the login page, which rotates the sid and therefore invalidates the csrf token. Making it impossible for a user to log in.
This is a race condition, meaning it would only appear if the user stayed on the login page for a few seconds, hence why the automated testing did not block the commit.
closesodoo/odoo#112239
X-original-commit: d5d80d172616afe02bd41934930ea18dc273c739
Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>
Co-authored-by: Julien Castiaux <juc@odoo.com>
The reconciliation fields of account.move.line should be independent of the move's state.
closesodoo/odoo#112251
Co-author: Habib (ayh) <ayh@odoo.com>
X-original-commit: 00aadcb65ab1b05b390840acc02d5012a0fed893
Related: odoo/enterprise#36843
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
This case of amls having a zero balance but an amount in foreign currency left is already managed by the new reconciliation in 16.0.
Furthermore:
-the test in POS is passing even with the revert
-the reverted commit introduces a performance issue on amount_residual by forcing the orm to fetch the whole m2m debit/credit_matched_ids.
-there is no test accounting-side depicting the issue (if there is really an issue fixed by the commit).
X-original-commit: 63c9e9cfff8451af153cbf2f369021a3e6b20599
Part-of: odoo/odoo#112251
before this commit, in active currency warning is shown in the account move form when the currency_field is empty.
after this commit, the inactive currency warning will be shown only if the currency is set and it is inactive.
forwardported manually
closesodoo/odoo#112240
X-original-commit: 1937e4954c6603b36c968fcdb2c08e7d40d21b0a
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
Consider field F in module X with parameter translate=False, and F is
overridden in module Y with parameter translate=True. During the
upgrade of module X, module Y hasn't been loaded yet, and the ORM
considers the field to be `translate=False`. Therefore it converts its
database column from type jsonb to varchar, and accidentally drops
non-en_US values:
{"en_US": "English value", "fr_FR": "French value"} (jsonb)
-> 'English value' (varchar)
As a result, translations are lost after upgrade.
This commit fixes the bug by checking whether the field is translated in
database and patches the field accordingly when loading the registry.
This avoids the ORM considering the field as non-translated while
upgrading modules.
In order to "force" translated fields to become non-translated ones, at
the end of the loading process the patch above is discarded, and fields
are checked again. We then adapt the schema of models that have such
fields. This extra step handles the uninstallation of modules like
module Y in the example above.
The patching of the fields has one potential issue. While upgrading
module X, field F is patched with translate=True. If module Y actually
overrides F with translate=xml_translate or so, this may cause the
behavior of the upgrade to be slightly incorrect. Because of the
complexity, we have chosen to not support this case.
closesodoo/odoo#112223
X-original-commit: 1e6e482a9763baa5fae70d9b6676d16a46458f4a
Signed-off-by: Raphael Collet <rco@odoo.com>
Signed-off-by: Wang Chong (cwg) <cwg@odoo.com>
Co-authored-by: Raphael Collet <rco@odoo.com>
Date fields are changing format if you type it in instead of using the
date selector calendar popup
Steps to reproduce:
1. Install Time Off
2. Open the current language and change the date format to `%d.%m.%Y`
3. Go to Time Off > Approvals > Allocations
4. Create a new allocation
5. Change the validity period to 10.03.2023 (by typing it in, not using
the datepicker) and click out of the field
6. The date displayed is changed to 2010/03/20 or 20.03.2010 (if the
datepicker was opened)
Solution:
Add dot and comma as a possible character for static format
Also deduplicated function isValidStaticFormat so we have a single
definition
Problem:
Formats using dots were not considered as valid static format so the
value entered was parsed with the format `yyyy/MM/dd` instead
opw-3081268
closesodoo/odoo#112218
X-original-commit: 18d6944510b55a4de21be050b8fef327f00e71d5
Signed-off-by: Rémi Rahir (rar) <rar@odoo.com>
Signed-off-by: Guillaume Merlin (megu) <megu@odoo.com>
Before this commit, when an event containing only the creator was created in Google Calendar, the creator's attendee status in Odoo was marked as 'needsAction'. Now, when an event like this is created (in Google Calendar), the event is automatically accepted in Odoo.
A test was added to make sure that new events with only the creator are automatically accepted.
closes odoo/odoo#112195
Task: 2782961
Related-to: #68700
X-original-commit: 6d0ead3d73477614dc1bd97a95b695f80925fdd3
Signed-off-by: Arnaud Joset <arj@odoo.com>
The module was partially coded in Chinese while we want
the code to be written in English.
This PR translates the module to English.
closesodoo/odoo#111987
Task: 3119641
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
This follows the merge of [1].
Model implementing the `_compute_website_url` method sometimes adds the
"base url" part which is probably not necessary and sometimes forgot to
add the "slug" part. This commit only fixes the website_hr_recruitment
job's one to add the slub. The others will be fixed later, this should
probably be part of a deeper refactoring to use routes with Model
validation rather than accepting any int and reviewing when the base
URL is actually necessary.
Notice that the main point of this change is that the `website_url`
field as some models now shown in the "Site" menu of the website app.
In that case, when clicking on a record, the user is redirected to the
iframe preview, with the right website and domain without the need for
it to be part of the object's URL.
[1]: https://github.com/odoo/odoo/commit/da3f4c2aff92cca23ca2d7a87fa0eb5b1d7ce5feclosesodoo/odoo#112211
X-original-commit: 0c6cf40bacf2d206e9a8b09bb2073252f5919dd0
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
This commit fixes a broken selector when an avatar image (`.oe_avatar`)
is used next to a title element (`.oe_title`) to put them side-by-side.
Also it goes beyond that by ensuring the `.oe_title` element doesn't
take the whole width (cf. max 75%) to make a visual distinction between
it and the other form's fields, both in editable and non-editable form.
In small screen, as space is limited, the whole width is kept to make it
more userfriendly, only allowing a thin gap between the `.oe_title` and
the `.oe_avatar`.
Steps to reproduce:
- Open Apps
- Choose an App and, in the dropdown, click on Module Info
=> there is a huge gap at the top of the title
closesodoo/odoo#112205
X-original-commit: 45ebcbf320eaeedf0a4c6c068ea727cf18bedd4b
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
Usecase to reproduce:
- Set product as FIFO and a cost of 10$
- Sell 5 units
- Modify the cost method to average
We expect the value of the stock to remain -50$.
However it went to -150$
It happens because the change of cost method is not supported
with negative quantity of stock. It's not really a huge bug because
it will be reconcile to the real value in the next in and when the
stock will be positive again but at least it gives a proper valuation
of the inventory.
opw-3100717
closesodoo/odoo#112133
X-original-commit: 3993cbeb00f0a61c76151e116a4c90dae112c067
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Steps to reproduce the bug:
- Create a repair:
- Add any product to repair
- Add any other product as part of the repair
- Confirm the repair
- Start the repair
- End repair
Problem:
The cancel button becomes visible and clicking on it won't cancel the
moves, so it doesn't make sense to cancel a finished repair.
opw-3146606
closesodoo/odoo#112191
X-original-commit: f8c489b7484c054a7b870b22cf610b615bab2cc8
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Steps to reproduce:
- Install eCommerce, delivery
- Shpping methods > Create > Name = TEST, Product = Acoustic Bloc Screen,
Provider = Based on rules, Add a line > Condition = "Weight <= 0",
Delivery Cost = "50 + 0 * Weight" > Publish shipping method
- Go to the website > Add acoustic Bloc Screen to cart > Proceed to checkout
In the delivery section, the TEST shipping method will display the
warning message `No price rule matching this order; delivery cost
cannot be computed.` This message can be confusing to the customer.
opw-3110715
closesodoo/odoo#112002
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Settings > General Settings > Section Users:
Button Invite behaves in a weird way.
In dutch, e.g., "Nodig uit" splits into 2 lines,
whereas it could expand, eating out a little bit of the
input's space.
closesodoo/odoo#112192
X-original-commit: fa258ab9e4a608aaeced774bfa32eea1894e324b
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
When trying to recover peer to peer connection, the timeout of 500ms or
1000ms might be too short and 15000ms in unnecessary too long.
If the timeout is too short, it could remove the connection before the
peer to peer had the time to reconnect to it. When we call
`_recoverConnection` on `disconnect` in `oniceconnectionstatechange`
or `onconnectionstatechange`, the signal `disconnect` does not
necessarily mean that it will remain disconnected. Doing nothing could
be enough to reconnect.
(see: https://w3c.github.io/webrtc-pc/#dom-rtcicetransportstate-disconnected)
closesodoo/odoo#112182
X-original-commit: 3647374c63fcd4bccf501e49a2af6a707fedd737
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Before this commit, the iceCandidateBuffer was emptied before finishing
the loop. This is wrong as we must add all candidates from the buffer.
X-original-commit: 520a880574d908a8e28fa258a1e006d1b8504221
Part-of: odoo/odoo#112182
Since the merge of #101247 in master, opening the forecast report
from the SO line was broken. This was due to old action being called.
closesodoo/odoo#112180
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Before this commit, the reserve/unreserve buttons did not work / were
hidden with multi-step delivery settings. The report now works with the
entire linked chain of moves, it displays which step is reserved,
if more than one is reserved in the chain the later move is shown.
Because reservation works differently on chained moves (they reserve
quantities brought by previous move in the chain) any extra unreservable
quantities are shown as on stock in transit.
closesodoo/odoo#112162
Taskid: 2858139
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
This reverts commit [1] so as to avoid updating the DOM in two separate
places of the code for link edition. Said commit intended to prevent the
removal of custom styles on a button on which styles were applied
(erroneously) without applying a custom button class. This fixes that
issue by adapting the UI to show the button is custom if there are
custom styles applied. This way, if any change is applied, when
modifying the DOM, the custom class will be applied as well. This is the
order in which such corrections are usually applied with the snippets
bar.
[1]: https://github.com/odoo/odoo/commit/eb4edac560227b46efdcfe958e3b93e0b88def64closesodoo/odoo#112152
X-original-commit: 1b65244a1ae7ed37d7bc1faef2225ed982c94320
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
This PR removes the legacy implementation of the form, kanban and
list views and view dialogs. It also removes the legacy view widget
registry, and all legacy widgets it contained. The legacy field registry
couldn't be removed yet as some fields are still used (e.g. in client
actions: FieldMany2One, FieldMany2ManyTags...), and sometimes
accessed from that registry (e.g. uom service). More clean up will
come later. Note that all tests using legacy views have thus been
removed, even though the tested feature might still remain (e.g.
FieldMany2One tests have been removed, but that field is still there).
However, those features are deprecated and unlikely to evolve. They
should be removed in the next saas, or the one after.
This PR also removes the legacy data export dialog (and the data.js
file which was deprecated since v11).
Finally, this PR removes the basic views benchmark page, alongside
the benchmark library which was no longer used.
Task 3168640
closesodoo/odoo#111809
Related: odoo/upgrade#4304
Related: odoo/enterprise#36696
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
This commit remove the legacy implementation of the data export
dialog, which wasn't used since the removal of the legacy list
view. This also allowed us to finally remove the data.js file,
which contained the "legacy legacy" implementation of the model
(DataSetStatic, DataSetSearch...). This was deprecated since v11.
Part of task 3168640
Part-of: odoo/odoo#111809
This commit removes the legacy implementation of the form, kanban
and list views. It also removes the legacy view widget registry,
and all legacy widgets it contained. The legacy field registry
couldn't be removed yet as some fields are still used (e.g. in
client actions: FieldMany2One, FieldMany2ManyTags...), and
sometimes accessed from that registry (e.g. uom service). More
clean up will come later. Note that all tests using legacy views
have thus been removed, even though the tested feature might still
remain (e.g. FieldMany2One tests have been removed, but that field
is still there). However, those features are deprecated and
unlikely to evolve. They should be removed in the next saas, or the
one after.
Finally, this commit also removes the legacy view dialogs.
Task 3168640
Part-of: odoo/odoo#111809
This commit aims at removing the last usecases of the legacy view
dialogs, which will then allow us to remove legacy basic views.
The last usecases were in legacy code, in FieldMany2Many and
FieldMany2ManyTags. As those fields are still used in client
actions, we adapted them to use the wowl view dialogs instead.
Part of task 3168640
Part-of: odoo/odoo#111809
Those views are no longer used and about to be removed. This
commit also removes the benchmark lib as it is no longer used.
Part of task 3168640
Part-of: odoo/odoo#111809
Arnold Moyaux