Before this commit, late close events were not handled properly. This
could have led to non-reconnecting websockets. The problematic scheme
is the following:
- Close the socket (eg. upon the reception of an `offline` event), let's assume that
the other end will not perform the closing handshake, the connection will be
closed once the browser presumes it is dead.
- Create a new socket (eg. upon the reception of an `online` event)
- The browser assumes the connection is dead and dispatches a `close` event,
the worker switches to the `reconnecting` state and expects an `open` event to
update its state to connected. Since there is already a running socket, the worker
won't open a new one and will never receive the `open` event.
- Server closes the connection (eg. `KEEP_ALIVE_TIMEOUT`)
- The close handler is called but since it is in the `reconnecting` state, it assumes
it shouldn't do anything thus, no reconnect attempt is made.
This PR fixed this issue by ignoring events linked to outdated sockets.
closesodoo/odoo#112456
X-original-commit: a2454739156d8742f7606f090126f32735fb15df
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
The goal of this commit is to convert the last legacy client actions from
/hr_attendance to owl.
Client actions:
hr_attendance_greeting_message
hr_attendance_kiosk_confirm
hr_attendance_kiosk_mode
hr_attendance_my_attendances
closesodoo/odoo#110095
Taskid: 3138068
Related: odoo/enterprise#35884
Related: odoo/upgrade#4296
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
Tansifex is deprecating it's client and switches to a go-based
solution in its API v3
The new client is still backward compatible with the old format but
the v2 API is going to be phased out.
See https://github.com/transifex/cli to install the deplyments using
the tx client
This PR is the result of the "tx migrate" command
closesodoo/odoo#112402
Transifex: adapt to new URL format
X-original-commit: 7ca55aec4f1faa8bc2ad80d730a7f0771df3998e
Related: odoo/documentation#3534
Related: odoo/enterprise#36950
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
1/ The mexican DIOT report is now a tax report.
This in order to enjoy more Reportalypse' features (less menuitems,
tax_tags engine). The export functinality will remain in enterprise
version.
2/ Add missing tax "RET IVA RESICO 1.25%" tax.
3/ Add migration script for taxes.
As a new tax (RET 1.25%) has been added and the DIOT refactoring updated
many invoice_repartition_line_ids and refund_repartition_line_ids with
tags, the migration script will be run on module update.
task-id: 2925736
[community](https://github.com/odoo/odoo/pull/109300)
[enterprise](https://github.com/odoo/enterprise/pull/35515)
closesodoo/odoo#109300
Related: odoo/upgrade#4224
Related: odoo/enterprise#35515
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
after #111448, the structure of text field is changed. The Translate Button css
hack for ir.ui.view's form view doesn't work.
1. enable the multiple languages
2. go to the form view of a ir.ui.view record
3. the EN button for the view disappears
This commit fixes the bug by adapting the css to the new structure
closesodoo/odoo#112420
X-original-commit: 4dc94998f295b32567472d87bcf7e44af621e4c2
Signed-off-by: Luca Vitali <luvi@odoo.com>
Signed-off-by: Wang Chong (cwg) <cwg@odoo.com>
Steps to reproduce:
- Create a parent analytic plan with no analytic account
- Create a subplan for this analytic plan with no analytic account.
- Create a subplan for the above subplan and create an analytic account for this subplan.
- create an invoice and try to put the created analytic account
Issue:
The analytic account is not availble (nor the subplan, nor the root
plan are displayed)
Cause:
We only fetch root plans (plans without parent_id) that have an
analytic account set. In this cas, the root plan is not retrieved
since the account_id is defined on the sub-sub-sub plan and not on the subplan nor the direct child of the root plan.
Solution:
Fetch all plans that have account_ids set and append the root plan to the relevant plans
opw-3107652
closesodoo/odoo#112419
X-original-commit: d725c74336feb27bd02e0f05491b24cb51627374
Signed-off-by: William André (wan) <wan@odoo.com>
This commit changes the event snippet tag option which was
misconfigured. Using the option fakem2m is indeed the way
to go to filter the events based on the given tags.
This commit also changes the way the domain works with tags:
tags from the same category will apply an OR condition
between them and tags from a different category will apply
an AND condition.
Task-3105126
closesodoo/odoo#109538
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
In werkzeug 2.2.2, the following characters "$!'()*+,;" are now
considered as safe by url_quote. This makes the filename_secure test
fail with the hard coded expected string containing a single quote as
'%27'.
This commit adapt the filename_secure test in order to work with all
versions of werkzeug.
closesodoo/odoo#112298
Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
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>
tsm-odoo