Before this commit, when a ListViewHeaderButton was clicked, the view
context wasn't sent to the server.
As ListViewHeaderButton shows, the onClickViewButton API is not correct.
It expects a record in params but this is not correct in the case of
ListViewHeaderButton. So we decided not to pass a record but a getParams
callback that allows us to calculate the params when we need them.
Part-of: odoo/odoo#97558
expiration
Previously, we do
{expiration,use,removal,alert}_date = receipt_date + {expiration,use,removal,alert}_time
After this commit, expiration date remains unchange, for the other 3
dates, we calculate them by
{use,removal,alert}_date = expiration_date - {use,removal,alert}_time
Task-2657043
closesodoo/odoo#86760
Related: odoo/enterprise#25419
Signed-off-by: Steve Van Essche <svs@odoo.com>
ac08da0a834631b2a7c39c40b1f36f01a85e8617 moved channel_type from Thread
to Channel, but data returned by get_mention_suggestions have not been
updated accordingly. This commit adapts it.
Follow-up of task-2948676.
closesodoo/odoo#98677
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Purpose
=======
The logic has been moved from the pos.config to the res.config.settings
model/views, and therefore this js_class is not used anymore.
closesodoo/odoo#98641
Taskid: 2958057
Related: odoo/enterprise#30658
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
The "Process now" button throws a UserError if doc is already processing
=> but only thrown if parameter with_commit=False
PR odoo#87266 changed with_commit default value for test purposes
=> accidentally prevented the UserError from popping up
This PR restores with_commit default value for button action
=> User now gets the expected UserError pop up
closesodoo/odoo#98618
X-original-commit: 451fbfb356e9f7941180d14796afeb161fa09660
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Stanislas Gueniffey (stgu) <stgu@odoo.com>
Using local ids in test is cumbersome: we need to retrieve the mail
record associated with the server record to get it while the thread
model/id are more than enough and available. This PR replaces thread
local id data attribute by thread model/id.
task-2959366
closesodoo/odoo#98588
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
The attribute aria-labelledby was used erroneously and was misspelled.
This commit corrects that by replacing it with the aria-label attribute.
task-2937538
closesodoo/odoo#98401
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Fixing the display of long track names by taking all the
width for the title in edit mode and forcing line breaks in
read mode.
Task-2941724
closesodoo/odoo#98396
X-original-commit: 4e2484e84bfaf8c4d21b0ac887c7c80594142792
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: Dieudonné Amélie (amdi) <admi@odoo.com>
When using the keyboard to switch records (e.g.: Leads records), we can use
keyboard shortcuts (ALT + N / P) to travel from records to records. However,
when using these shortcuts, the changes on the current record are not applied
when switch.
Step to reproduce the issue:
1. Install CRM module and activate Lead
2. Ensure that there are multiple Lead already created
3. Go on one Lead and edit its title WITHOUT clicking outside the box
4. Press ALT+N on your keyboard to switch to the next record
5. Press ALT+P to come back to the initial record
You will see that the initial record's changes have not been saved.
Solution: The issue is a racing condition. Somehow, when we use the keyboard
shortcuts, the `mutex.exec` from the `applyChanges` function (cfr. Line [1]) is
not prioritized and the `isDirty` check from `saveChanges` is executed first (
cfr. [2]). We can check this with the debugger, we stop on the `mutex.exec`
then we execute the `isDirty` then we execute the callback of the initial
mutex. The issue is that, it is the callback of the mutex that allows to set
the `_isDirty` flag to True which in return allows the `saveChanges` to
save the record as he spot some changes.
[1]: https://github.com/odoo/odoo/blob/ef789170ce2f1553b325b379aac4452e473de1e9/addons/web/static/src/legacy/js/views/basic/basic_controller.js#L281
[2]: https://github.com/odoo/odoo/blob/ef789170ce2f1553b325b379aac4452e473de1e9/addons/web/static/src/legacy/js/views/basic/basic_controller.js#L180
opw-2824986
closesodoo/odoo#96696
X-original-commit: d9ec7b4b4a9f3cc8caa4c7f5fade8ce1fb8baaea
Signed-off-by: Desausoi Laurent (lade) <lade@odoo.com>
Signed-off-by: Simon Genin (ges@odoo) <ges@odoo.com>
Current behavior:
If you have atleast 2 delivery methods available on the website,
and try to pay with a giftcard the selected delivery method will
always switch to the partner preferred delivery method.
Steps to reproduce:
- Activate giftcards for website
- Set a preferred shipping method for partner A
- Make sure the preferred shipping method is website published
- Publish atleast one other shipping method for the website
- Go on the website shop, and add product to the cart
- Process checkout and select any shipping method that is not
the preferred shipping method of partner A
- Pay with giftcard
- The selected delivery method switch back to the preferred method
of partner A
opw-2883592
closesodoo/odoo#98619
X-original-commit: b356091d579bf4a29c9c8ad84915139984cf16e9
Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>
Since ChatWindow messages can be aligned in both directions, the
MessageActionList must adapt its padding and the order of its items when
the menu is expanded according to the message.
This commit adapts the padding and the order of the items.
closesodoo/odoo#98607
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
The widget `account-tax-totals-field` needs the value of the
`currency_id` field, even when not in multi-currency mode.
The widget is used in `sale.order`, `account.move` and
`purchase.order`. The only place where the field
was not included when not in multi-currency mode
was the purchase.order.
A traceback was raised when attempting
to open the purchase order form when
not in multi-currency.
This is an oversight of odoo/odoo#95729closesodoo/odoo#98597
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
Currently, the EDI attachments *content* is passed to the Send & Print wizard.
Then, the wizard re-creates these attachments and link them to itself. At the
end of the flow, when clicking 'Send & Print' button on the 'Send & Print' wizard,
the attachments of the wizard are copied on the move.
Thus, the EDI attachments are duplicated.
Passing the ids of the EDI attachments rather than the content solved the issue,
since they are simply linked to the wizard, without being re-created.
task-2957823
closesodoo/odoo#98447
Related: odoo/enterprise#30596
Signed-off-by: Laurent Smet <las@odoo.com>
Steps to reproduce:
- Install Netherlands localization module
- In the `Customer Invoice` journal, activate `NLCIUS (Netherlands)`
as Electronic Invoicing
- Create a new invoice and confirm
Issue:
XML generated and available as attachment and if we click on
`Send & print`, a second one is added to attachments.
Cause:
If it's not a factur-x or e-fff edi documents, we will generate the
XML file add it as attachment on confirm.
Solution:
Don't add as attachment of the invoice when confirming invoice if
code is `nlcius_1` (like for factur-x and e-fff edi documents),
only when generating invoice PDF (`Sent & Print`).
opw-2751148
closesodoo/odoo#98594
X-original-commit: 6c090dae0a051ac4e89310387c7777ef2d0d60d9
Signed-off-by: Florian Gilbert (flg) <flg@odoo.com>
Signed-off-by: Nasreddin Boulif (bon) <bon@odoo.com>
The clickbot click default timeout was increased in #98495, but missed
the fact that the default was overridden for the "Settings" menu to a
lower value.
With this commit, the "Settings" exception is completely removed as the
default timeout is higher. Also, checking that the text contains
"Settings" was a bit weak.
While at it, the timeout for the global testing of an app is also
increased to 10 minutes instead of 5 as this limit is reached by the
Field Service app.
closesodoo/odoo#98617
X-original-commit: 0247e6f4abef4121b451c1373ae3c1ce184451c0
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
Improvement of https://github.com/odoo/odoo/commit/e66663b52920ad5a647b03a8fd9ade4070f09158
The commit mentioned above introduced a bug, which
prevent the user to select payment method when register
a payment for multiple partners, even if the payments
were from the same type.
The solution here is to allow the selection of payment method
in any case, the _create_payment_vals_from_batch method will
change the payment method if it is not available on the journal.
Note: for the forward port from 15.0, only test is adapted, as the bug
does not happen.
opw-2954325
closesodoo/odoo#98574
X-original-commit: d16946b450356922b69e6152bd343229ed4d2bb3
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: Guillaume Vanleynseele (guva) <guva@odoo.com>
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>
FrancoisGe