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>
The message returned by `_get_sent_message` for validation transaction
was wrong, refering to a token, but there is no token on validation transactions.
This doesn't have to be fixed in stable since validation transactions are not linked to
any specific document, so the wrong message was never posted anywhere.
Now that we improve the display logic of payment tokens and noticed the problem,
this commit fixes it (for code consistency, and if any custom code/... uses this
message as well.
Part-of: odoo/odoo#94978
Previously, the autocomplete's width was set manually to that of the
parent. This is useless because the width is already set by the left: 0
and right: 0 rules in css. These rules are also incorrect, as we don't
want the width of the autocomplete to depend on the size of the input,
it should be able to overflow past the end of the input if necessary to
show the full width of the autocomplete items.
This commit fixes that, and relies on the usePosition hook for position
instead (as the position used to be left: 0 and right: 0)
closesodoo/odoo#98443
Signed-off-by: Michaël Mattiello <mcm@odoo.com>
* = calendar, im_livechat, rating, snailmail, test_discuss_full, test_mail,
website_livechat
Distinction between "replace" and "insert-and-replace" can be guessed based on
the type of the provided data.
task-2957295
closesodoo/odoo#98404
Related: odoo/enterprise#30580
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
*: point_of_sale, website
This commit fixes the style of the settings affected
by changes during the conversion to Owl.
Because of the new DOM of fields, some elements displayed
using the 'row' class were not horizontally aligned
because of the changes made to the DOM of the field that
were used. As the layout have changed, it was needed to
adapt and add new styling class in the template.
closesodoo/odoo#98387
Signed-off-by: Samuel Degueldre <sad@odoo.com>
This commit adds some spacing between the text and the
button in the DomainField. Since the rewrite of the
field, the button was too close to the text that
preceded it. A minor margin have been added to the
button to avoid that.
Part-of: odoo/odoo#98387
When a record is created through xml data, its HTML fields should
receive a `type="html"` attribute, not a `type="xml"` attribute.
When important XML data with XML type instead of HTML type will have 2
differences:
- The field value will be prefixed by `<?xml version="1.0"/>`
- If the HTML contains multiple root nodes, the value will be wrapped in
a `<data/>` tag.
See `_fix_multiple_roots()` and the `xml_import` class for more details.
closesodoo/odoo#98239
Related: odoo/enterprise#30491
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
This rule has no effect for a while!
In settings, we had to delete it because converting it would add
space in the first column.
In payment, it seems that this offset was used to center the content.
We prefer to convert it.
closesodoo/odoo#98438
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
Steps to reproduce the issue:
- Notes app > Kanban view > Create a bunch of notes using
the + icon in the kanban view
- (optional) Modify the default order of the notes
- Add a new note using the quick add feature
- Don't modify the order of the notes and refresh the page
- The new note will be sent to the bottom of the note list
(off-screen if the list is long enough)
This happens because new notes have their sequence set to NULL, which
places them at the end of the list after ordering by sequence.
This commit sets the default sequence of a new note to 0, so that it
is placed at the top of the list and adds an additional sort on
'id desc' to consider the case where all notes have the same sequence.
opw-2924615
closesodoo/odoo#98427
X-original-commit: ec719b166635df9ed31c9c2b47fedadd2311765c
Signed-off-by: stcc-odoo <stcc@odoo.com>
Purpose
======
When creating a specific Operation Type of type 'Manufacture' the default
operation type is not the correct one on object creation.
So in this commit, we set default `Operation Type` in picking when Type of
Operation is `Manufacture`.
taskID - 2939078
closesodoo/odoo#98145
X-original-commit: b28c44a38698018ebbbc420f6567c17b2b97c279
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Creditor Reference is one of the 3 allowed references type in swiss QR-Bills (with None and QR-Reference)
It is used with normal IBAN (QR-Reference must be used only with special QR-IBAN)
Fixes#71578Closes#81269closesodoo/odoo#95518
X-original-commit: 8e1d86dcb10aebc1be1a318126492573a4b74331
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
# Issue
A Dropdown is not closed when a child ViewButton is clicked.
# Solution
Make the ViewButton close the Dropdown.
# Note
Usually, a dropdown is closed by a DropdownItem component.
This is not the case here, because the clicks on view buttons are stopped
(see the view button template). Letting them bubble would close their
eventual parent dropdown, but it brings other issues (e.g. for a view button
in a list renderer's group row, or view buttons that could get interpreted
as action links under some conditions <a type="action" .../>).
Instead of looking in the env to close the parent dropdown if any,
an alternative solution would be to extend the ViewButton component,
wrap it in a DropdownItem component, and reroute its `onClick` handler
to the DropdownItem's `onSelected` prop.
But this requires some preparation at the form compiler level
(when compiling the status bar buttons), which we thought was overengineering
at the time of writing.
closesodoo/odoo#98399
Signed-off-by: Samuel Degueldre <sad@odoo.com>
dbkosky