This commit removes vertical padding of the dropdown
toggler used in the StateSelection field widget converted
to Owl recently. In a list, it was causing an unexpected
higher row.
closesodoo/odoo#98718
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Searching by attributes works via a separate form. It has a copy of other search
parameters (`category`, `search`), but not `order`.
STEPS
1) enable View "Products Attribute's Filters" in eCommerce
2) enable View "Show Sort by" in eCommerce
3) Set sorting to specific value
4) Change Product Filters Attribute values
5) as you can see, the sorting set in Pt3 is lost....
opw-2956280
closesodoo/odoo#98716
X-original-commit: 7e9afa3f167bd3251984c2027fb50f127bc002c2
Signed-off-by: Ivan Elizaryev (iel) <iel@odoo.com>
Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>
Since odoo/odoo#97347 we support default values for `t-field`
directives.
However this causes some issues in the case where we have: no value, no
default value AND force_display is true.
This is because the indentation for one of the lines in the compiled
code was not correct. (full explanation here: https://github.com/odoo/odoo/pull/97347#issuecomment-1222430659)
closesodoo/odoo#98714
X-original-commit: 2b605d3ccd55dc4f5b1ad44439411542e5b04b31
Signed-off-by: Rémy Voet <ryv@odoo.com>
Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>
Since be0fc43bbd0664340d555f2156630870e3548466, a reference to the model
is passed to ModelField constructor. This commit replaces all occurrences of
record.constructor with this.model (shorter and more straightforward).
closesodoo/odoo#98687
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Before this commit, if we have a reference field with a "model_field" in
X2many in list mode and we modify this record, then the value of the
reference field is set to false.
Cause of the problem:
The reference field assumes that the preloadedData are always available.
How to reproduce :
- Go to an x2many in list mode containing a reference field with a
"model_field" already containing a value
- edit another field than the reference
- click outside the record
Result before :
The record switches to readonly mode and its reference field contains
the value false
Result after:
The record switches to readonly mode and its reference field has not
changed value.
closesodoo/odoo#98630
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Automatically add readonly on computed and related fields. This commit
required to rewrite some preexisting fields to make them readonly.
Task-2955927.
closesodoo/odoo#98541
Related: odoo/enterprise#30625
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Purpose:
Improve performance/reduce server load for the status bar widget when
the underlying field is a m2o.
Before this commit:
The status bar widget does two calls:
- a search_read request to retrieve ids and folds
- a name_get to retrieve names
With this commit:
The name_get can be avoided to save a call by fetching display_name in
the search_read.
This commit removes the name_get call to retrieve the name directly
from search_read.
task-2919535
closesodoo/odoo#98164
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
This commit is part of the websocket integration in Odoo.
The longpolling port does not make sense anymore: longpolling has been dropped.
This commit deprecate the `--longpolling-port` option and replace it by the
`--gevent-port` option.
closesodoo/odoo#75510
Related: odoo/enterprise#23184
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
*: bus, calendar, hr_attendance, iap_mail, im_livechat, project, snailmail,
snailmail_account, survey, web, web_editor, website_livechat.
This commit is part of the websocket integration in Odoo.
This bus service now communicates with a shared worker in order to provide
a single websocket connection for multiple tabs. It is designed to
be used as a websocket except that events are slightly different,
re-connection is handled automatically. If the browser does not support shared
worker (Safari), the service fallback on a simple web worker.
Available events are:
- connect : fired upon a successful connection.
- disconnect : fired upon reception of the websocket close event.
The close code and reason are given to the listeners callback.
- reconnect : fired upon a successful re-connection.
- reconnecting : triggered when the worker starts to try reconnecting.
- notification : fired upon the reception of notifications.
Since multiple tabs are now handled by a worker, the cross_tab bus is no longer
required and has been removed.
Part-of: odoo/odoo#75510
*: hr_presence, web_editor.
This commit is part of the websocket integration in Odoo.
It focuses on adapting the bus to support websockets:
- last notification id is now kept on the server
- channel list is built by overriding the `_build_bus_channel_list`
method of the `ir_websocket` model instead of overriding the `_poll`
method of the bus controller.
- The bus presence was updated during polls, since there is no more poll,
bus presence update will be the responsability of the client.
- The `/websocket/peek_notifications`, `/websocket/update_bus_presence`
routes will be available so that odoo sh can access notifications/update presence
from http requests.
- /longpolling routes are now prefixed with /bus thus won't be redirected to the
gevent worker anymore except for `/longpolling/health` which is the
health check route of the gevent server.
Since websocket now handle incoming messages, a way to manage authentication
have been introduced :
- The session is retrieved from the HTTP handshake.
- When a websocket message comes/leaves the session is retrieved
on the file system so that we're sure it still exists and that
it is up to date.
- The session is checked
- If no session is found on the file system or `check_session`
fails, the websocket connection is closed with the `SESSION_EXPIRED`
close code (which is a custom close code: 4001).
- Note that websocket connections are closed every `KEEP_ALIVE_TIMEOUT`
seconds to ensure no websocket connection will stay open if the user
clears its cookies.
- Note that a wsrequest object is available when processing incoming
messages. It is similar to the http request and contains various
useful informations (session, env, ...).
Part-of: odoo/odoo#75510
This commit is part of the websocket integration in Odoo.
It focuses on implementing websocket lifecycle events.
Two lifecycle hooks are currently available:
- onopen: called after the websocket opening
- onclose: called after the websocket closure.
Those callbacks will be passed an environment and the websocket
related to the lifecycle event.
In order to subscribe to websocket lifecycle events, one must decorate
a free functions with either `@Websocket.onopen` or `@Websocket.onclose`.
Part-of: odoo/odoo#75510
This commit is part of the websocket integration in Odoo.
It focuses on implementing rate limiting to the incoming
websocket messages. When opening a connection, a burst of messages
is allowed. When requests are received too fast, an exception is
raised and the websocket is closed.
Two config parameters are added to customize the rate limtier
behavior:
- websocket_rate_limit_delay: Integer specifying the seconds that
should space out two requests.
- websocket_rate_limit_burst: Integer specifying how many websocket
frames can be accepted in excess of the specified rate.
Part-of: odoo/odoo#75510
This commit is the first commit of the websocket integration in Odoo.
It focuses on the implementation of the websocket protocol as per RFC6455.
The implementation is tested thanks to the autobahn test suite.
A config parameter is available to customize the websocket connection:
- websocket_keep_alive_timeout (default 600): Integer specifying how
many seconds a websocket connection should be kept alive
Part-of: odoo/odoo#75510
Some audit companies require this display.
closesodoo/odoo#98702
X-original-commit: 093d0e9b743d9aaa7e2a8f94278242524f975500
Signed-off-by: Masereel Pierre <pim@odoo.com>
Steps to reproduce:
1. create additional pricelist `p1`
2. add `p1` to available pricelists in PoS, remove default pricelist
3. open the session, create a new contact, don't change the pricelist
4. the created contact will have default pricelist and there is no
way to use `p1` as its pricelist
The problem is that when creating contacts, if the pricelist had not
been changed, it is not passed to be processed and so the contact is
created with the default pricelist, even though the default pricelist
is not available in the PoS.
To fix the problem, we can use the default pricelist of the PoS as the
default when creating new contacts and pass it as well.
opw-2930778
closesodoo/odoo#98685
X-original-commit: 9151edc3083775a0459a3af332114a572795cd20
Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Signed-off-by: Khanalizadeh Ahmad (khah) <khah@odoo.com>
This is an oversight of odoo/odoo#95729
In a database with multi-uom disabled,
when attempting to create an expense choosing a product
with a different unit of measure than the Unit(s)
a ValidationError was raised to the user
regarding an UOM incompatibility
e.g.
- Create an expense
- Set the product "[MIL] Mileage", using the uom "km"
- Save
-> ValidationError about UOMs
This is because the above mentioned PR makes the
`product_uom_id` completely removed from the view,
and the onchange no longer set the uom correctly within the form.
Solve this by setting `precompute=True` on the UOM field,
and the other fields using the same compute method.
In addition to solve the issue, it also allows to create
more easily expenses from the XMLRPC API:
Before, when creating an expense for the product "Mileage",
it was required you set yourself the uom correctly
in your API call,
even if multi UOMs was disabled in your database.
After, it's no longer mandatory to pass the UOM to use,
it is correctly computed from the product directly,
by default.
closesodoo/odoo#98662
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
Scenario:
hr_contract is installed and employee/officer without rights on contract
tries to archive an employee.
Before the fix:
An employee/officer without rights on contract gets the following access error:
Due to security restrictions, you are not allowed to access 'Employee Contract' (hr.contract) records.
THis is because the action tries to access employee's contract and set
date_end on it.
After the fix an employee/officer without rights on contract can archive
an employee without access error.
task - 2811165
closesodoo/odoo#98648
X-original-commit: c7ff577053a120f8f961642891d3a0ec0c960ae8
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Before this commit, in a formView, if you modify an input and use
the keynav (alt+n or alt+p) to change the record, then the modification
is not saved.
How to reproduce?
- go to a form view with a pager containing more than one record
- edit an input
- press alt+n to move to the next record
- press alt+p to go back to the previous record
Result before:
The record has not changed
Result after:
The record has saved the change.
closesodoo/odoo#98602
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
- First issue
The format passed to the daterangepicker locale options could have been
wrong as the daterangepicker lib uses moment and we would pass to it
the date(time) format expressed with luxon's format tokens.
Furthermore, there was no need to pass the format to the daterangepicker
library as the DateRangeField component already handles this.
- Second issue
There was also another issue with the DateRangeField component:
When applying the daterangepicker values, the conversion between a
moment object to a luxon DateTime object was wrong because of the format
used to convert the moment object to a string.
- Explanation
The format tokens are different between luxon and moment.
- After this commit
An helper function has been introduced in order to transform a luxon format into a moment format.
The DateRangeField component now properly converts a moment object to
a luxon's DateTime object when applying the daterangepicker selection.
- Additional note
Also, the DatePicker component was locally converting the luxon's
datetime format and thus has been adapted to use the new helper.
closesodoo/odoo#98578
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
- Before this commit
Using a daterange field with an empty start/end date(time) will result in an unusable field.
The datepickers shown are set with invalid moment.js objects.
- Explanation
A formatted empty value yields an empty string.
Calling `moment("")` results in an invalid moment objet.
- After this commit
When the formatted empty value yields to a falsy value (i.e. an empty string), we call the global moment function without arguments.
Calling `moment()` results in a valid moment object representing the current date and time.
This is what we are looking for, and thus our issue is resolved.
Part-of: odoo/odoo#98578
This method name, while being not specific enough to ease grepping,
leads to have `data-slide` in the option XML declaration. This was
actually confusing with the BS4 data-slide of carousel elements. Here,
in master, this leads to even more confusion as BS5 uses data-bs-slide
thus making it unsure if the option's `data-slide` has to be converted
or not during the current BS5 bug fixing.
Indeed, it was converted by mistake with the original BS5 merge at [1]
and later fixed with [2] but it could be matched by regexes again and
be re-broken by mistake.
[1]: https://github.com/odoo/odoo/commit/971e5a91aab96d36129a823e03f1f9f1b1293968
[2]: https://github.com/odoo/odoo/commit/c6524ee9d60888bb147b77db5e394af8beda05abclosesodoo/odoo#98362
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
The purpose of this commit is to enable the "group by" functionality of
many2many in graph views.
Some other views also implement it (e.g. Gannt odoo/enterprise#20192,
List and Kanban odoo/odoo#74985), it is therefore a logical step to also support group
by many2many in graph views.
Previous behavior:
It is possible to select a many2many in the group by but it has no effect in the graph.
Expected behavior with this commit:
It is possible to select a many2many in the group by and it has an impact in the graph.
task-2721035
closesodoo/odoo#98009
Related: odoo/enterprise#30272
Signed-off-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Before this commit, pick did not work on non-enumerable properties.
For example, getters in a class are non-enumerable properties. It was not
possible to pick the value of a getter in a Class with the pick function.
closesodoo/odoo#97558
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit, when you want to modify or add a record in a
non-editable x2many, the call to get_views to receive the arch for the
FormViewDialog did not contain a context.
Problem:
The arch of the form view that is received for adding or editing a
record in a non-editable x2many is not evaluated correctly.
Cause:
An empty context is passed to the "get_views" to receive the arch
for the FormViewDialog.
Solution:
We use the context of the StaticList that represents the x2many for
the "get_views".
Part-of: odoo/odoo#97558
The legacy field MrpFieldOne2ManyWithCopy added a control create
that performed an action when clicked.
In the new listRenderer we have added the possibility to define control
action buttons. So it is no longer necessary to create a custom field
for this use case.
Part-of: odoo/odoo#97558
This commit adds the possibility to define control action buttons in the
arch of a list view for a x2many. These buttons are action buttons that
will be placed in the same place as the control create ("Add a line").
The goal of this new feature is to offer the possibility to define
buttons that execute actions linked to an x2many.
Here is an example where we define a control create and a control action
button:
<tree>
<control>
<create string="Create" context="{}" />
<button string="Action Button" name="do_something"
class="btn-link" type="object" context="{'parent_id': parent.id}"/>
</control>
<field name="display_name"/>
</tree>
Part-of: odoo/odoo#97558
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
luvi