This commit fixes a visual issue with the input element of field widgets
in editable lists: the inputs were too narrow and offset to the left.
These inputs should now take the whole width of their containing cells.
> Example view: CRM / Configuration / Tags
closesodoo/odoo#98288
Signed-off-by: Bruno Boi (boi) <boi@odoo.com>
To compute the correct size of the text field, the vertical
borders are removed and reset after the computation.
The second part was not done correctly and so the
textarea didn't have any border.
closesodoo/odoo#98284
Signed-off-by: Simon Genin (ges@odoo) <ges@odoo.com>
Commit c06cee44fe corrected a nasty concurrency error in crons but the
serialization error was still logged.
closesodoo/odoo#98741
X-original-commit: 81c70a594a785fc0e32c9ff47c28c92b0f837923
Signed-off-by: Julien Castiaux <juc@odoo.com>
Before this commit, when we create an export Invoice ( foreign customer )
without shipping details and processing the invoice, the system asks for
mandatory to provide details of shipping, which are not compulsory to
generate an E-Invoice in India.
After this commit, the system will proceed with E-Invoicing in case of
export without shipping details on the invoice form.
closesodoo/odoo#98737
Task-id: 2948375
X-original-commit: d2d68fcc6c019847b552f3a61b6fabebeb13a354
Signed-off-by: Josse Colpaert <jco@odoo.com>
Before this commit, not able to submit overseas invoices to the portal if the
delivery and billing address are different, the same overseas invoice can be
submitted to the portal if the delivery and billing address are the same.
After this commit, we can able to submit an e-invoice even if the delivery and
billing addresses are different.
Task-id: 2871478
X-original-commit: c38395b08f08f333e8252f79588c7661dfa3b965
Part-of: odoo/odoo#98737
Commit 0edc854a84 introduces a company check on the salesperson, partner
& team on the lead model.
However 184334a97d1ccd19b9a7266a13ff51531d22cff4 was not able to find the expected company on a lead
created by email when the team did not have a company set. Which is the case by
default for the following crm.team:
- Sales (3ad1867ea4)
- Pre-Sales
- Website (3ad1867ea4)
- PoS
Having added the company check introduce an unexpected error:
"Incompatible companies on records:\n-
'[header subject of email]'
belongs to company False and 'Customer'
(partner_id: '[name in header from of email]')
belongs to another company."
Error was hard to spot as the db logs are reporting that the routing of the
email was correctly done. But script to send eml using xmlrpc showed the error.
In this commit we fix the issue by removing the custom code trying to set
a company in ``message_new`` method of crm.lead. Indeed as it is a computed
field with a complete heuristic it is easier to let the ORM do its job and
remove that wrong value. It is now correctly computed as with any other
lead.
opw-2862509
opw-2783249
opw-2832435
opw-2881841
closesodoo/odoo#98746
X-original-commit: 2fec9c53314ef3f7c7e3305a6ee2417018d70ce5
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Co-authored-by: Xavier Alt <alt@odoo.com>
Corrects misspelling of "abandonned" -> "abandoned" and incorrect word "authentified" -> "authenticated" in website+e-commerce settings.
Steps:
- Install E-commerce module
- Navigate to Website -> Configuration -> Settings
- Search for "Abandoned Cart" section
Problem was introduced in commit: 73483c8e5a
opw-2949403
closesodoo/odoo#98734
X-original-commit: 76ff0f229ee385131105c6407dcd644b7d356062
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Piryns Victor (pivi) <pivi@odoo.com>
Prior to this commit, the note had its own style. This created too much
confusion with the other message types.
This commit removes the note style to improve the readability in the
chatter.
closesodoo/odoo#98043
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
During the forward port of https://github.com/odoo/odoo/pull/96855 the
file gift_card_controller.py was reintroduced by mistake.
closesodoo/odoo#98740
X-original-commit: 0d80cf7c6999f968e9aee1d9622fdf21f3dd5806
Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>
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>
Odoo's Mergebot