It's pretty much unused and fairly complicated.
Also deprecate `listdir` entirely since `get_module_filetree` is the
only extant user of the recursive listdir.
closesodoo/odoo#98034
Related: odoo/enterprise#30403
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
In this commit:
+ Add validation for OnChange definitions 💪
+ Fix the errors found thanks to the new validation 🤩
+ Get rid of the `OnChange` class (useless boilerplate code) 😤
* = calendar
closesodoo/odoo#98549
Related: odoo/enterprise#30631
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Since the merge of Bootstrap 5 at [1], a background-color and an opacity
are added on the `<hr>` elements. That way the <hr> now follows the
color of the surrounding text but are faded a bit. The BS4 behavior was
to use a lightgray (transparent black).
With the adaptation at [1], it was chosen to be compatible by forcing
that opacity to 1 and re-forcing the previous transparent black. This
commit chooses to instead keep the nice auto behavior of BS5, at worst
this will thus change lightgray <hr> to the color of the surrounding
text (faded a bit), it should not be a breaking change. The separator
snippet however keeps its full compatibility as we want to let users
choose the exact color they want so we cannot add a default opacity (we
may want to improve the UX later on).
[1]: https://github.com/odoo/odoo/commit/971e5a91aab96d36129a823e03f1f9f1b1293968
Part-of: odoo/odoo#98028
Steps to reproduce:
- go to ecommerce try to pay with paypal and after stripe
Current behavior:
You get an error message
Expected behavior:
You have no error message
Explanation:
When /shop/update_carrier is called we check if there is a transaction
that is not error or canceled mode and raise an error if this the case
we should add the draft state to the list. We also add a condition so
that the error can be raised only if the carrier was changed.
opw-2956571
closesodoo/odoo#98584
X-original-commit: 863cc3998b0bb18a7557b312121ed8655150b1fc
Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>
This commit's purpose is to improve the user experience when using the
burdown chart as well as preventing fetching all the data in order to
prevent long loading time on big databases.
This commit adds `Allocated Hours` (`planned_hours` field) in the chart
measures as well as default filters in order to restrict the data to
the tasks which stage have been modified this year or the previous
one, or which current stage is not `closed`. This commit also hides the
`stage_id` field from the one that are available in the group by as this
report requires it to be set (and thus we need to prevent the user from
removing it).
task-2941625
closesodoo/odoo#97321
Related: odoo/documentation#2551
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
Prior to this commit, `default_period` attribute is taking a single value.
This commit adds the support for comma separated values.
task-2941625
Part-of: odoo/odoo#97321
The template `suggested_products_list` is badly named as it does
not show alternative products in the cart but accessory/suggested
products, leading to possible confusion in the customize menu when
editing the website.
This commit changes it to `Accessory Products in my cart`.
closesodoo/odoo#98575
X-original-commit: 782fbab913ff5cf662500bcead07405013d9bf68
Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>
The invoice line and tax line sections of the Italian edi should be
reported in euros. Due to this, the line.balance is used instead of the
line.price_subtotal when calculating the PrezzoTotale' (price_subtotal)
of the line. The amount is then made negative if the line is
representing a completed downpayment, or if it is a negative line on a
reverse charge refund.
The unit price is calculated mostly the same way (using the new
price_subtotal value). If the line has a discount of 100% then the unit
price of the line is computed from the line.price_unit, by converting it
to euros using the _convert method on the invoice currency.
The exchange rate and the original currency / original currency amount
are listed on the lines using he 'AltriDatiGestionali' elements in the
xml.
A mistake with the way a reverse charge invoice was calculated has been
corrected too. Before reverse charge was determined by the document type
being 'TD16', 'TD17' or 'TD18'. Where instead it should be 'TD17',
'TD18' or 'TD19'.
A typo (inovice -> invoice) has also be corrected in the tests.
closesodoo/odoo#98534
Ticket-id: 2952018
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Daniel Kosky (dako) <dako@odoo.com>
Several fields in the l10n_it_edi XML template are adapted fairly often
as work progresses on l10n_it_edi/l10n_it_edi_sdicoop. This refactor
moves the computation of these field to the python code in
_prepare_fattura_pa_export_values.
The computation is done for the:
(DettaglioLinee) Invoice Lines:
NumeroLinea (line number), Descrizione (description),
PrezzoUnitario (unit price), PrezzoTotale (line subtotal),
(DatiRiepilogo) Tax Lines:
Arrotondamento (tax rounding),
ImponibileImporto (tax base), Imposta (tax amount).
These are computed by the new functions
_l10n_it_edi_prepare_line_details and _l10n_it_edi_prepare_tax_details
and returned as lists of dictionaries, which are passed to the function
that renders the template.
The template is modified on the above fields, to reference the above
dictionaries, instead of performing the computation in situ.
Moving the computation of these fields to the python code has the
benefit of:
a) easier, more concise computation of these terms
b) not requiring users to upgrade the l10n_it_edi module in order to
benefit from future changes to these fields (they will only need to
upgrade once).
Part-of: odoo/odoo#98534
The edi system does not properly represent the type when exporting
downpayment invoices. The type (TipoDocumento) should be TD02, and
instead it is TD04.
To fix this, a new key is added to the _l10n_it_document_type_mapping
function that maps invoices for which _is_downpayment is true to the
document type 'TD02'.
The description for the line is also modified to include references to
the downpayment invoice if the line is linked to a downpayment. This is
done using the _get_downpayment_lines method introduced in 8dcc25bc776.
Ticket-id: 2924728
Part-of: odoo/odoo#98534
Currently there is no simple way of finding if an invoice is a
downpayment.
Downpayments can be created from a sale order. An invoice is generated
representing the downpayment. When the sale order is used to generate
the complete invoice, the downpayment is deducted.
There is no fast way to distinguish a downpayment invoice. The only way
of knowing is that the lines of the invoice will have sale_line_ids for
which 'is_downpayment' (a boolean field on the sale order line) is true.
(also, by default, the product 'Downpayment' is used for the invoice
line representing the downpayment)
This commit adds a helper method '_is_downpayment' to the account.move
model, which will return False if sale is not installed, and True if
sale is installed, and is_downpayment (the boolean field on
sale.order.line) is true of all the sale lines associated with all the
lines of the invoice.
Another method '_get_downpayment_lines' is added to the
account.move.line model which, for all sale lines associated with the
move line upon which it is called, returns the invoice lines of the sale
lines for which their move_id._is_downpayment() is true. This
distinguishes between the downpayment lines in the final invoice (which
aren't retrieved by this method), and the downpayment lines in the
downpayment invoice (which are retrieved by this method).
Part-of: odoo/odoo#98534
STEPS in v14:
1. Set user's timezone to Asia/Qatar
2. Inventory > Config > Setting > Enable Lots & Serial Numbers, Expiration Dates, Display Lots & Serial Numbers on Delivery Slips, Display Expiration Dates on Delivery Slips
3. Create a product (storable, tracking by lots, expiration date)
4. Manually update the on-hand quantity for the product
5. Create a lot for the product created in Step 3 > Set the expiration date to 3/30/2025 00:00:00
6. Create an SO with the product > Confirm it to Delivery
7. Validate the Delivery > Print the Delivery Slip
Before this commit the expiration date is rendered as 03/29/2025 instead of 03/30/2025
opw-2901367
closesodoo/odoo#98371
Signed-off-by: Julien Castiaux <juc@odoo.com>
Commit [1] introduced an option to enable link and button commands.
The goal was to be able to disable it in website_forum when the user
doesn't have the proper privileges. Instead, it disabled it everywhere
except in website_forum (and then indeed only enabled it when the user
had said privileges). The same is true of images and videos.
This enables these commands by default instead, and disables them only
specifically for website_forum under the appropriate circumstances.
[1] e104937118
task-2917285
closesodoo/odoo#98111
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
It's really not a general purpose utility, it's just a way of forcing
a lazy collection's evaluation.
Alternatively, add a helper for this to / alongside `lazy`? Note that
the lazy object(s) may not be the top-level.
closesodoo/odoo#98023
Related: odoo/upgrade#3776
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
They're not used much and they don't seem much of an advantage
compared to just calling `subprocess` with the discovery utility
functions.
While at it, fix `dump_db` to not unnecessarily have an open stdin to
`pg_dump`.
Part-of: odoo/odoo#98023
The sequence field is special-cased early on in read_group (_raw): if
the caller requests the aggregation of ``sequence`` that request is
ignored:
if fspec == 'sequence':
continue
This was added a long time ago, probably due to the special-ish status
of `sequence` (summing sequence number doesn't really make much
sense).
The issue is that it's also possible to request ordering by
`sequence`, which requires `sequence` to be one of the aggregated
fields. This is checked in `_read_group_prepare` and triggers a
warning.
This leads to an inconsistent behavior, where the user requests
aggregating & ordering by `sequence`, we remove it from the aggregated
fields, then warn that they didn't aggregate on the field.
Make the behavior consistent by also ignoring requests to order by
`sequence`.
closesodoo/odoo#97409
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Currently, there is no globally available way to load xsd files.
Modules that use xsd files to validate xml files all load the files with their own methods, but in the end they all do the same thing. It is redundant and hard to maintain. On top of that, new modules that need to load such xsd files need to implement it again.
This commit adds an easy way to load xsd files (either directly .xsd files or from .zip archives) and save them as ir.attachment to use with _check_with_xsd method for xml validation purposes.
It also adds a function to validate an XML file with an XSD. This function allows for a reloading method to be called if the XSD file was not found in database.
In order to avoid excessively downloading XSD files (during tests for instance), the 'skip_xsd' flag can be set to True in the context. This will skip the XSD validation (and thus download).
task id=2782053
closesodoo/odoo#89145
Related: odoo/enterprise#26393
Signed-off-by: Laurent Smet <las@odoo.com>
Previously, when evaluating a button's context from its attributes, we
would evaluate it with the record's data as context, this resulted in
x2many fields being evaluated as a datapoint (in particular, as a
StaticList). When we then went to call doAction with that context, the
action service tries to serialize that context with JSON.stringify,
which crashes as the StaticList contains circular references. This is a
mistake, as contexts and domain that are to be evaluated from a
string/attribute should be evaluated using the record's evalContext, not
its data. This commit fixes that.
closesodoo/odoo#98469
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
With the conversion of the kanban view, it was no longer possible to
validate the quick-creation of a column using enter while within the
quick-create input, this is because the hotkey service ignores hotkeys
being pressed while within an editable element by default except for the
escape key.
This commit fixes that by configuring the enter hotkey that
is registered to bypass the editable protection, and also restricts this
hotkey to only be active while focused inside the input.
closesodoo/odoo#98535
Signed-off-by: Bruno Boi (boi) <boi@odoo.com>
Previously, when registering a hotkey without an area then a hotkey with
area, there would be a crash, as that latest hotkey is the candidate
winner, and we then check that there is no other matching hotkey with an
area that's more specific. In doing this, we assume all other candidates
have an area and call it as a function, but since some hotkey
registrations don't have one, we get a crash.
This commit fixes that by filtering the candidates to only those which
have an area before trying to narrow down to the most specific one.
Part-of: odoo/odoo#98535
In some cases, when putting in pack, it will lead to a "unreserve more
than reserved" error
To reproduce the issue:
1. In Settings, enable "Packages"
2. Create a storable product P
3. Update the on-hand quantity: 0.4 x P
4. Create and mark as todo a planned delivery order DO
- Operations: 0.4 x P
5. In the detailed operations, set the done quantity to 0.3
6. Put in Pack
7. Open the detailed operations
- Error: There is a line with 0.11 x P reserved instead of 0.10. The
total reserved quantity is therefore 0.41 which is not possible.
Moreover, the available quantity of the related quant is 0.29 which does
not make sense
8. Set the done quantity to 0.1
9. Put in Pack
10. Validate
Error: a User Error is displayed "It is not possible to unreserve more
products of ... than you have in stock." The user is now stuck, he can
neither process the picking nor unreserve it.
On step 6, when putting in pack, we split the SML into two ones. To do
so, we also split the reserved quantity:
https://github.com/odoo/odoo/blob/fcc74186330c8df37cfac08455bd7bba44d4656b/addons/stock/models/stock_picking.py#L1384-L1388
However, because of a floating point issue, we have:
`0.4 - 0.3 = 0.10000000000000003`
Therefore, since we use the rounding method `UP`, we have:
```py
ml.product_uom_qty == 0.4
quantity_left_todo == 0.11
done_to_keep == 0.3
```
And we then use these values to update the reserved quantity on each
SML:
https://github.com/odoo/odoo/blob/fcc74186330c8df37cfac08455bd7bba44d4656b/addons/stock/models/stock_picking.py#L1391-L1398
When writing on that field, we also try to update the quants:
https://github.com/odoo/odoo/blob/55921e32baa1b4b226bd43edf20e93619e411905/addons/stock/models/stock_move_line.py#L378-L383
(As shown, if an error is raised, we ignore it)
After the reservation of `quantity_left_todo`, there are 0.29 x P left.
Therefore, when trying to reserve `done_to_keep`, it will raise an
error:
https://github.com/odoo/odoo/blob/b5d16141dc48d4379452ea40e167f3b00f956c20/addons/stock/models/stock_quant.py#L679-L680
But as shown above, the error will be ignored. This explains the
inconsistency between the reserved quantity on the SMLs and on the
quant.
On step 10, when validating the picking, we try to unreserve all SMLs:
https://github.com/odoo/odoo/blob/55921e32baa1b4b226bd43edf20e93619e411905/addons/stock/models/stock_move_line.py#L570-L572
So we will try to unreserve more than actually reserved on the quant.
That's the reason why an error will be displayed.
OPW-2942054
closesodoo/odoo#98521
X-original-commit: 4f593706ee6d1b3ddf0f1c9c90c86df2977459d9
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
Before this commit, when creating a record containing an invisible
x2many, the fields related to this x2many were not asked during the
creation onchange.
Problem:
Some required values were missing when igniting a new record.
Cause:
The arch related to an invisible x2many was ignored.
closesodoo/odoo#98086
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Override doesn't work with multiple records so breaks the built-in
bulk archive/unarchive action of the list view, and it's completely
unnecessary since `BaseModel` has a builtin `action_archive` which
works out of the box if the model has an `active` field (or
`x_active`, or a boolean field explicitely set as `_active_name`).
closesodoo/odoo#98515
X-original-commit: ad38943fb4e963d587ba9f292b7e277182f17a06
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Before this commit:
Replace button was adding another image without replacing the existing one.
After this commit:
Now replace button replaces the existing image with another one.
Task-2895601
closesodoo/odoo#98513
X-original-commit: 3e8db4fa7a2d8eb9eba4b184e33bb3a6f69ce687
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Improve the demo data for bank statement in account by formatting the
payment_ref amounts using the company currency, and fixing the due
amount in one payment_ref to match the statement line amount.
Task id #2855485closesodoo/odoo#98510
X-original-commit: 4b23d11184be9bac5ef9790cc7f38bc4d637b47a
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: Nicolas Viseur <vin@odoo.com>
Currently e.g. syntax errors during the import are logged as
exceptions but they don't fail the loading / testing.
Update the loading using more modern loading APIs, in order to not
catch them at all (let them bubble up normally), and instead just
find *IF* a module has a tests submodule before trying to load
in (LBYL).
Fixes#80198closesodoo/odoo#97957
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
It happens that some pages are exceeding the click timeout of ten
seconds. Notably the settings, and as the settings are linked to
different menu's, it's difficult to black-list them.
closesodoo/odoo#98525
X-original-commit: 26665a5055842a40f3beb718bd63546758f190f4
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
Steps to reproduce:
- Load odoo on a mobile view
- Go to Inventory > Products > Products Variants
- Switch to the list view
- Long press a record to enter the selection mode
-> The selected records should be highlighted in blue
closesodoo/odoo#98186
Related: odoo/enterprise#30465
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
- A user has accounting permission but no employee permission, when that user register payment in spending it gives an error that does not have access to the bank_account_id field
- This commit allows the user to read the bank_account_id field when register payment
Original PR: odoo/odoo#98432closesodoo/odoo#98485
X-original-commit: 35e07de192dfeba0979170ba8421e4a61c5a483b
Signed-off-by: Kevin Baptiste <kba@odoo.com>
The attachment button on the chatter is way too close from its icon when
it has no attachment. This PR adds spacing between those items.
closesodoo/odoo#98471
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
This revision is to make uniform the behavior of the `groups` attribute
on the Python model fields
and on the node in the view architecture.
In both cases, remove the node from the view completely.
Before this revision,
in a back-end view:
- In the Python model, if a field has the `groups` attribute set
and the user is not part of
the groups, the field is removed, completely, from the view.
- In the view architecture, if a node has the `groups` attribute set
and the user is not part of
the groups, the node is made invisible (not completely removed, just
made invisible).
in a front-end view:
- if a node has a "groups" or "t-groups" set and the user
is not part of the groups, the node is removed from the view.
So it's 2/3 cases removing nodes restricted to a group.
and 1/3 case making invisible nodes restricted to a group.
It's simpler to have a uniform behavior for the 3 cases,
simpler to understandard for developers.
In addition, this will help for the goal to cache back-end views.
It makes possible to convert views using the `groups_id` field
by moving the content of these views directly
in the view to which they add content which is suppose to be completely
removed when the user has not the according group.
By getting rid of the `groups_id` many2many field on `ir.ui.view`,
it makes possible to cache the view architecture without
requiring to use the groups in the cache key.
Currently, if we want to cache the view architecture,
it would be required to use the intersection of the user
groups with the `groups_id` groups of the view,
making it costly to compute the cache key,
therefore altering the performance point to cache the view
architectures.
closesodoo/odoo#95729
Related: odoo/enterprise#29592
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
Error introduced by [1], probably while fixing the merge conflict
[1] c9d7f8b0edclosesodoo/odoo#98468
Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>
Steps to reproduce
------------------
1. Install sale_project.
2. Create a product that creates a project on order.
3. Create a Sales Order with this project and confirm it.
4. Click on the 'Projects' stat button on the SO.
5. Try to click on one of the projects, you should get an error.
---
This commit fixes this error by properly using the id of the project
as `active_id` in the action to view its tasks.
Task-2957905
closesodoo/odoo#98464
Signed-off-by: Xavier <xbo@odoo.com>
In BS4, the classes utilities order was set from `-1` (first) to
`13` (last). This commit restores the old behaviour.
In BS5, you only have a range from `-1` to `6`.
These classes are used in Odoo to order the `oe_stat_button`
particularly for UTM campaign. The order is set using CSS as there no
simple way to do it using `XPath` as there are many module (installed or
not) targeting the `oe_stat_button`.
closesodoo/odoo#98458
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
Since 5913b7265e it was not possible
anymore to use default value with `t-field`, this commit restore the
previous behavior.
closesodoo/odoo#98453
X-original-commit: 12dc2353f572d097fc57ec723a11651a8471fdf5
Signed-off-by: Rémy Voet <ryv@odoo.com>
Steps to reproduce:
- install hr and hr_contract apps
- go to Employees app > Employees > Contracts
- switch to Kanban view
There you can see a 'Create' button. If you click it, it creates a
contract history form view for the default employee, which is 'False'.
This view is not needed, since it doesn't make sense to create a contract
history by itself, as opposed to creating a contract history when a new
employee is added to the database.
This commit removes the contract history 'Create' button.
opw-2929424
closesodoo/odoo#97780
X-original-commit: 337400b00bcaced2f27417e7a925582b80b6a514
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: stcc-odoo <stcc@odoo.com>
Before this commit, tokens were prefixed with usually 12 X’s. To improve
readability, modernity and to shorten the length, this commit changes
token prefixes to a standard of •••• 1111.
task-2832669
closesodoo/odoo#94978
Related: odoo/upgrade#3738
Related: odoo/enterprise#29190
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Xavier Morel