The path matching logic got reimplemented in werkzeug 2.2[^1] and the
new router is no more compatible with regexp groups[^2]. Our custom
converter for slugged-records in urls (`'/partner/agrolait-5'` => `5`)
has been adapted to match the route using non-capturing groups. It still
extracts the slug/id pair using the groups-capturing regexp.
[^1]: https://github.com/pallets/werkzeug/pull/2433
[^2]: https://github.com/pallets/werkzeug/pull/2519
Part-of: odoo/odoo#112298
Since Werkzeug 2.1.0, the Response.autocorrect_location_header is
disabled by default.
As it's RFC compliant and supported by browsers, the base_url is simply
removed from the assertions.
Part-of: odoo/odoo#112298
Archiving an allocation creates bad behaviour
in the use of the time off application.
For example, an employee who has several allocations some of which are archived
in the same period will create a problem in the counting of remaining days off.
Steps to reproduce:
- for an employee;
- create a 5 days type A allocation with a validity from 01/01/2023 to 31/01/2023;
- create a 5 days type A allocation with validity from 01/01/2023;
- archive the first allowance;
- set time off for this employee in this period.
Issue:
The employee's days off are not deducted until he has taken at least 5 days off.
Cause:
The process of deciding which allocation to use first will depend
on whether it has an end date or not.
It will therefore use the allocation with an end date first
(in our case the archived one).
Solution:
Archived allocations cannot be ignored by removing them
from the calculation process, as they have a use.
The solution that respects the business flow is to prevent archiving
for allocations that are not in a draft or refuse state.
opw-2991368
closesodoo/odoo#112401
X-original-commit: 199bd4acebfc905595ddf0525b4f69e38c336853
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Signed-off-by: Lefebvre Thomas (thle) <thle@odoo.com>
Following up on the gst increment from 1 January 2023, some more changes:
- Change the default taxes on to Sales Tax 8% SR for sales and Purchase Tax 8% TX8 for Purchase
- Changing tax grid for Purchase Tax 8% TXCA
2963811
closesodoo/odoo#110611
X-original-commit: e6bab21dcf2e467fe8a79d1ef82e2cab87d4790c
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
After this commit, the user will be able to clone a question
inside a survey, the cloned question will have the same sequence
as the original and thus will be displayed just below it.
This commit also remove the is_conditional icon on the overall
questions tree view and the misplaced warning which was
previously introduced in commit [1].
[1] : b1d1856245
Task-3088848
closesodoo/odoo#112385
X-original-commit: bdcc2e6c4bec23c200a3fa2a2b4dd1bb06943f39
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
If the business is incorporated, both these fields must be present.
We don't have a field to know whether the business is incorporated,
but in any case the fields must be both present or not present.
opw-3127832
closesodoo/odoo#112366
X-original-commit: b3de98d4dd248f56461f735a6cae143296a96a0a
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Paolo Gatti (pgi) <pgi@odoo.com>
Clicking on the kanban state / attachments / avatar on the kanban card
of a hired applicant would just open the record instead of doing the
intended action as the click was intercepted by the ribbon.
closesodoo/odoo#112349
X-original-commit: 6af260c9a14e639aa9e082dbc117899fe5833c96
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Adds basic support to filter possible m2x values based on another
record. This is necessary for the website_appointment snippet
introduced within this bundle (see related ENT PR).
An important need implemented here is to not store a list of valid IDs
in the DOM but fetch them based on data stored by a different widget.
Use case covered:
Model A has a Many2Many relationship with Model B via a `model_b_ids`
field.
A first widget (Wa) on a snippet's options allows to select a record of
Model A. A second widget (Wb) allows to select records of Model B.
```xml
<!--Widget A-->
<we-many2many data-model="model.a" data-m2o-field="name"
data-fakem2m="true".../>
<!--Widget B-->
<we-many2many data-model="model.a" data-m2o-field="model_b_ids"
data-filter-in="true" .../>
```
Before this commit, the second widget would only be able to show
all records of Model B linked to any Model A record and matching a
static domain provided as attribute, which is still supported.
This commit allows, after having selected `record_a` in the first
widget, to only populate the second widget with the records of
Model B that are in `record_a.model_b_ids`.
Implementing this is done by
* Adding `data-filter-in` to Wb's xml attributes (as above)
* Calling `Wb.setFilterInDomainIds()` when another record is selected
in Wa.
Task-2574175
odoo/odoo#90748
See odoo/enterprise#23750
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
When having long questions or sections to display, prevent the questions table from overflowing
the form box.
Fixed globally with a css rule on the x2many list fields.
Task-3151054
closesodoo/odoo#112372
Forward-port-of: odoo/odoo#112168
Related: odoo/enterprise#36926
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Remove an unnecessary css rule, it was made
global for all x2many list fields.
Task-3151054
X-original-commit: 81cf885a9d102c86782f6742bbc98bccb1ee8344
Part-of: odoo/odoo#112372
Purpose
=======
Prevent the x2many list tables in notebook
pages to overflow when having long chars in
the cells or sections.
Specifications
==============
Because of the display inline-block css rule
applied to the x2many field widgets, the table
of the x2many list (in the notebook pages) are
overflowing from the box when having long char
in the cells or sections.
Setting width 100% to the x2many field fixes
the overflow behavior. Long chars are hidden
with ellipsis or wrapped and displayed to a
new line depending on the display.
Task-3151054
X-original-commit: 2cd0106e63785dd34553c2b4747d72b93b9a7afd
Part-of: odoo/odoo#112372
Before this commit, the bottom row of control panel in
list view could change height when reducing window size
and give an ugly layout.
This commit gives more flex to this row to keep a correct
layout when reducing window size.
task 3095775
closesodoo/odoo#110277
Related: odoo/enterprise#36895
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
currently on confirming a blanket order will generate a reference for the record using the sequence and once the record is moved to cancel state and clicking the reset to draft button is clearing the already assigned reference number.
and on clicking confirm again will generate a new reference number for the same record.
this pr will stop clearing the sequence number on reset to draft button.
closesodoo/odoo#108574
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
It's rarely possible to have a statement that its `balance_start` is
empty. So it's safe to use 0.0 when it's None.
opw-3162432
closesodoo/odoo#112374
X-original-commit: 957517c45822771ee2a6e6b6b921b1e53381fb1b
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
Signed-off-by: Pedram Bi Ria (pebr) <pebr@odoo.com>
See previous commit, it fixes a bug introduced by a recent change in the
javascript framework that broke the website kanban override.
This commit is ensuring that the kanban can be accessed and used.
Ideally, it should have been a QUnit test but since this has to be
merged ASAP (critical bug) and a test is more than welcome as it's not
the first time our custom kanban is broken, a hook in an existing tourµ
is used to easily and quickly test it in the meantime.
closesodoo/odoo#112369
X-original-commit: aca72bcdae98e1304c934f67efa65273d636863a
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
Since [1], an error was raise because the xpath to add an if attribute
: "//div/t/t[2]/KanbanRecord" wasn't precise anymore and was applied to
the wrong KanbanRecord, removing the correct attribute.
Now a more precise xpath is used.
[1]: https://github.com/odoo/odoo/commit/fa20b8de642fc57e5c6a49ca77c28d4aab150df9
X-original-commit: bc4776d8f532f2c5882bdac1c72ac95c5ade6be9
Part-of: odoo/odoo#112369
Before this commit, when creating a new record using the quick create on
a kanban view, a flickering was visible. We can see the quick create
form disappear, the record list goes up, the quick create form re-appear
and the record list goes down again.
This occurs because, the record list contains an empty record that is
used on the quick create form. When clicking on the add button on the
quick create form, this record is directly saved, and as is already on
the list (the quick create form disappear and the record list goes up),
only after this action, a new empty record is created and added to the
list (the quick create form re-appear and the record list goes down
again).
Now, an empty record is created independently of the list, so when we
click on the add button on the quick create form, the record is saved,
a new empty record is created (the quick create form is emptied), and
the saved record is added to the list (the record list got the new saved
record), avoiding the flickering.
task-id=3085247
closesodoo/odoo#112367
X-original-commit: 9c82f5dca00921b6911671db3845ad593d2e1191
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
Speedup writing a new inventory valuation method ('manual' or 'real_time')
on a product category with lots of associated products.
The first optimization is in product._compute_value_svl. By
browsing the read_group result's product_ids and computing
the products quantities in batch, getting a product's
qty_available in the for loop becomes much faster as the value
is already in the cache.
The second optimization is in
account_move._compute_invoice_payment_term_id. Currently there
is no explicit value set to move.invoice_payment_term_id if both
if conditions fail. This produces a side-effect
when precomputing the field's value to be used in a create call.
Since there is no value in cache for some, possibly all records being
created, the compute method will be called multiple times, once
for each record whose invoice_payment_term_id = False. This is because
in models._add_precomputed_values, the precomputed values are retrieved
one record at a time in the for record, vals in zip(records, vals_list_todo)
loop. This is fine because upon CacheMiss the record_ids will be expanded
by the _prefetch_ids. But since in the case of both if conditions failure
no value is actually set in the field_cache for the invoice_payment_term_id
field, the compute method will need to be called once by record,
even if self has been expanded. Setting an explicit default value to
invoice_payment_term_id in the compute method fixes this issue.
opw-3146826
closesodoo/odoo#112360
X-original-commit: d67d86d00d5dbf5fc75420ff6df67495b35e0eb0
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
Signed-off-by: Van Delft Aurélien (avd) <avd@odoo.com>
# 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
closesodoo/odoo#112354
X-original-commit: 869b01da4948775d9a3009426a74cc9207e81374
Signed-off-by: Bruno Boi (boi) <boi@odoo.com>
Co-authored-by: huvw <huvw@odoo.com>
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
closesodoo/odoo#112348
X-original-commit: 3a320f5ec2c772a33dc905ed5b717adb9f134800
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
Signed-off-by: Achraf <abz@odoo.com>
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
Julien Castiaux