Fix the accounting date in a few scenarios, such as exchange difference
or CABA moves reversal.
Also avoid updating the currency rate when reversing exchange difference
moves.
closesodoo/odoo#98543
X-original-commit: 2b8df0c111a785a9e51dc2f528ac5b00cb0eadb9
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: Nicolas Viseur <vin@odoo.com>
This commit changes layout of call settings menu.
Before this commit, it was available in call action list
while in a call, as a dialog, in More > Settings.
With this commit, it's now available as an button in
thread topbar and chat window header, next to member
list button (`fa-cog`). It can be accessed even while
not in a call.
Task-2929713
closesodoo/odoo#96954
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
There is a gradual table already defined for this tax till year 2028
l10n_cl: add withholding second category taxes until 2026 and disabled previous years' withholding taxes
closesodoo/odoo#96075
Signed-off-by: Josse Colpaert <jco@odoo.com>
This commit greys out the add to cart button on the wishlist page when a product of type product is out of stock
task-id 2907659
closesodoo/odoo#97914
Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>
See previous commit(s) for more details about the new sanitize feature.
This commit implement a solution in the website builder to warn
restricted users when they can't edit a field due to the sanitizer
restriction.
Long story short: a HTML field can be flag as `sanitize_overridable`
which will allow users with the `base.group_sanitize_override` group to
not go through the sanitize process.
It means that such users can write some content which is not sanitize
friendly. A restricted user trying to add content in such fields would
then break the original content as the sanitizer would remove part of
the DOM.
In such cases, the field in the website builder is not detected as an
editable part and clicking on it will warn the user about it.
closesodoo/odoo#97398
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
The previous commit allows the sanitizer to be bypassed by some users if
those users are part of one of the `base.group_sanitize_override` group
and if the HTML field is declared as `sanitize_overridable`.
This commit flag frontend HTML fields as `sanitize_overridable`.
See the main commit of this PR for more details.
It also gives the `base.group_sanitize_override` group to the "Editor &
Designer" group.
Part-of: odoo/odoo#97398
Add the possibility to flag a HTML field as `sanitize_overridable`.
The sanitizer will then be bypassed if the user doing the operation is
part of the new group `base.group_sanitize_override`.
The "Settings" users are part of that new group.
If such a user wrote some HTML that would have normally been removed by
the sanitizer, then users without the right to bypass the sanitizer
won't be able to write on that field anymore.
Otherwise, it would sanitize the previously written data.
Such cases are detected, and the modification prevented by the system,
which will warn the user about it.
For instance, with a `field.html(sanitize_overridable=True)`: one being
part of `group_sanitize_override` could write `<script></script>`.
Then, someone not part of the group trying to add an element inside that
field like appending a `<p/>` -> `<script></script><p>New Content</p>`
would not be able to because it would go through the sanitizer and
ultimately, removing part of the original value:
`<p>New Content</p>` (`<script></script>` would be removed).
== Real use case ==
In the website builder, there is 2 editor rights:
- group_website_publisher: restricted editor
- group_website_designer: editor & designer
The designer editor can edit pages and views, while the restricted
editor can't do anything unless he is part of other groups.
In edit mode, the restricted editor will only be able to edit fields of
record he has access to.
For instance, being a sales manager allows you to edit a product
description on the website.
Being an event manager -> edit event. Slide manager -> Slides etc.
As those restricted editor are able to edit those fields, they are
(almost) always sanitized to prevent them to introduce malicious code.
Since those fields are sanitized, even admins / designer editor are not
able to fully use the website builder in such fields.
Some clients don't really care about that sanitation, they'd prefer to
avoid it as they trust their manager and would prefer to have the full
builder capability instead.
This is typically the case in small project (butcher, hairdresser,
reseller etc) and in SMEs.
With the new `sanitize_overridable` feature, they will be able to do
that, as the "Designer & Editor" group now also receive the group
`base.group_sanitize_override` (done in next commit).
Part-of: odoo/odoo#97398
Before this commit, when we open activity view and click on schedule
activity >> select a record there is a trackback due to the
invalid default_res_id passed in context.
So in this commit, fixes the issue by passing the valid res_id in
instead of object with id and display_name.
task-2927335
closesodoo/odoo#96999
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Steps to reproduce:
1.) Create a custom email domain and incoming email server on a database, set the
Actions to Perform on Incoming Mails to Create a new record: Helpdesk Ticket.
2.) Set an email alias for a Helpdesk team, set the assignment method to
balanced/random, assign some users to the team.
3.) Set another email address to forward emails to the alias for the Helpdesk team.
4.) Emails received directly by the email alias will create tickets and assign
properly, emails that are forwarded to the email alias will fall back on assignment
defaults.
Explanation:
When we get the "Delivered-To" field for the message dictionnary we use
decode_message_header and the message.get_all() function, this function
returns a list with two addresses but it is transformed back into a string
in decode_message_header with a space as separator. This create an issue
when we use email_split_and_format on this string as it uses
email.utils.getaddresses that expects a list of headers field or a text
where addresses are separated with a comma instead of a string with the
header fields separated by " ". Because of that getaddresses fails to get
the right addresses and the recipients field of the message dictionnary is
missing the right address. Hence when we check if the alias is in this
values it does not find it and use the default fall back.
Solution:
To solve the issue we set the separator as a comma in decode_message_header.
opw-2917543
closesodoo/odoo#98761
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
This commit fixes the style of the lightbulb icon
present in the settings of a project.
After this commit, the icon is now displayed
inline with the text.
closesodoo/odoo#98755
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
This commit fixes the style of the color selectors
in a livechat view. New classnames have been added
to revert to the intended appearance of the field
in the view.
Part-of: odoo/odoo#98755
Using local ids in test is cumbersome: we need to retrieve the mail
record associated with the server record to get it while the message
id is more than enough and available. This PR replaces message local id
data attribute by message id.
task-2959366
closesodoo/odoo#98728
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
This commit is to remove the "Create" button in a grouped kanban view
with create="0".
Problem:
In a kanban view with create="0", the "Create" button should never be
displayed.
How to reproduce :
- go to a kanban view with create="0"
- group the view
Result before:
The "Create" button is displayed
Result after:
The "Create" button is not displayed
closesodoo/odoo#98691
Signed-off-by: Julien Mougenot (jum) <jum@odoo.com>
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>
Nicolas (vin)