PURPOSE
Be defensive when dealing with email fields, notably when having multi-emails
or email field containing an already-formatted email.
SPECIFICATIONS
When possible, use 'email_formatted' field on partner, instead of calling
'format_addr'. That way management of corner case input (multi emails and
double encapsulation) is managed by the computed field itself.
When 'format_addr' has to be used, ensure email part is normalized to avoid
formatting issues.
Also use tools to extract emails instead of 'email_re' regex when possible.
That way all code extracting and managing emails go through the same stack.
Task-2612945 (Mail: Defensive email formatting)
X-original-commit: odoo/odoo@1c06014531
Part-of: odoo/odoo#134934
PURPOSE
Be defensive when dealing with email fields, notably when having multi-emails
or email field containing an already-formatted email.
SPECIFICATIONS
When building the final 'email_to' of outgoing emails using 'formataddr' we
have issues if email contains multi emails or formatted email. Main fix of
this commit is to extract emails and rebuild the 'email_to' list based on
found emails.
E.g. partner Raoul - email: "Raoul" <raoul@raoul.fr>
-> before: to: "Raoul" <"Raoul" <raoul@raoul.fr>> (double format)
-> after: to: "Raoul" <raoul@raoul.fr>
E.g. partner Raoul - email: raoul1@raoul.fr, raoul2@raoul.fr
-> before: to: "Raoul" <raoul1@raoul.fr, raoul2@raoul.fr>
single email with multiple emails, depends on server fault tolerance)
-> after: to: "Raoul" <raoul1@raoul.fr>, "Raoul" <raoul2@raoul.fr>
multi emails
Fix that computation by using all normalized emails found in 'email' fields
and rebuilding a formatted email based on name + those emails. We do not
use `email_formatted` as it is not really multi-enabled. We prefer a local
defensive approach to be as tolerant as possible with respect to user inputs.
Task-2612945 (Mail: Defensive email formatting)
X-original-commit: odoo/odoo@1c4b704149
Part-of: odoo/odoo#134934
PURPOSE
Be defensive when dealing with email fields, notably when having multi-emails
or email field containing an already-formatted email.
SPECIFICATIONS
Main fix in this commit: fix multiple nested formatting in 'email_formatted'
computation for <res.partner>. Other use cases are mainly left untouched as
we let users deal with their input. In summary :
* double format: if email already holds a formatted email, we should not use
it to compute email_formatted, like
name: Name / email: 'Format' <email@domain.com>
-> before '"Name" <"Name" <email@domain.com>>"
-> after '"Name" <email@domain.com>''
* multi emails: sometimes this field is used to hold several addresses
like email1@domain.com, email2@domain.com. We currently let this value
globally untouched by extracting emails and joining them, as we do not
expect email_formatted to be a list of emails. Extractin emails allows
to filter out extra text stored in email field, like
name: Name / email: text, email1@domain.com, email2@domain.com
-> before: "Name" <text, email1@domain.com, email2@domain.com>
-> after: "Name" <email1@domain.com,email2@domain.com>
* invalid email: if something is wrong, better keep it in email_formatted
than harcoding "False". Indeed this eases management and understanding
of failures at mail.mail, mail.notification and mailing.trace level. This
behavior does not change as it was already implemented like that even if
not sure it was intended;
Task-2612945 (Mail: Defensive email formatting)
X-original-commit: odoo/odoo@9175bbd8e2
Part-of: odoo/odoo#134934
When having several possible emails to contact the first one is saved on the
trace model. Indeed a trace is normally linked to a unique recipient but
in case of multi-emails in an email field, several emails are available.
This commit ensure computation keeps the original mail_to when making emails
adresses uniques before sending mails and creating traces.
Followup of odoo/odoo@213d5d396c
Task-2612945 (Mail: Defensive email formatting)
X-original-commit: odoo/odoo@b9b6fae9c5
Part-of: odoo/odoo#134934
This method is still not really tested, except its override of 'mail.thread.cc'.
So better have a test, especially in CRM that has some specific overrides.
Formatted email and multi-email input are tested, to check their current
support. Next commits will try to improve that, notably avoid formatting
issues.
Task-2612945 (Mail: Defensive email formatting)
X-original-commit: odoo/odoo@ce1fb51352
Part-of: odoo/odoo#134934
Move tests currently in mail about helpers defined in 'tools/mail.py' directly
into base. No need to test it in mail, there is no specific override or
behavior change compared to base.
Regroup partner related tests in base into 'test_res_partner'. This breaks
part of test history but it helps knowing which features are tested.
Task-2612945 (Mail: Defensive email formatting)
Part-of: odoo/odoo#134934
PURPOSE
Be defensive when dealing with email fields, notably when having multi-emails
or email field containing an already-formatted email.
RATIONALE
Add tests related to not standard usage of email field. Two main use cases
are tested here
* formatted emails: `"Full Name" <email@domain.com>` stored into the 'email'
field;
* multi emails: `email1@domain.com, email2@domain.com` stored into a single
'email' field;
Additional tests: tests with unicode / ascii / case / wrong formatting are also
added to check the support in normalize and format methods.
IMPLICATION
Email field is generally managed as "containing a valid email". This means
it is sometimes used as it in 'formataddr' as well as to perform searches or
identification checks. Example of issue: partner 'Raoul' has a formatted email
like "Raoul" <raoul@raoul.fr>. Using 'formataddr' in email_from leads to
from: "Raoul" <"Raoul" <raoul@raoul.fr>>
-> which is incorrect (but often dynamically corrected by email servers);
Email field holding multi-emails are not normalized, as current normalize
is done only if the field holds a single email. It means
* no easy finding based on 'email_normalized', e.g. various tools like
'_mail_find_partner_from_emails' or 'find_or_create' do not find partners
based on this email;
* no exclusion list management;
* issue with formatting, like
to: "Raoul" <raoul@raoul.fr,raoul.other@raoul.fr>
-> which is incorrect (but often dynamically corrected by email servers);
USAGE: OUTGOING EMAILS
Those use cases currently generate faulty outgoing emails. This is valid for
recipients ('email_cc', 'email_to') as well as author ('email_from').
For formatted emails: `email_to` is formatted again based on name and email
which leads to sending emails to `"Full Name" <"Other"<email@domain.com>>`.
Note that multi emails without formatting may work as it leads to email_to
`"Full name" <email1@domain.com,email2@domain.com>`. Some outgoing email
servers correctly send multiple emails. It depends on their fault
tolerance.
USAGE: FIND BASED ON EMAIL (NORMALIZED)
When searching for partners (e.g. using '_mail_find_partner_from_emails' or
'find_or_create') normalized version of input is used.
In case of multi emails sanitize is 'False', as normalization expects a single
email in the field. Therefore no partner is found. In processes that do a
"search or create" (e.g. using a template on a record) this leads to creating
a new partner (or several partners in case of multi emails) each time.
USAGE: OTHER FLOWS
Other flows are build on top of '_mail_find_partner_from_emails' / 'create'
of outgoing emails and are impacted by formatted email / multi email usage.
Those include notably
* mass_mailing: '_message_get_default_recipients' should be defensive to
give correct values when creating mailing emails;
* mass_mailing: faulty emails is based on normalize and multi-emails are
considered as faulty and ignored;
* after post hook: '_message_post_after_hook' tries to link messages without
author (but email_from) with newly-created partners, when partners are
created from chatter. It is therefore impacted by those corner cases;
* marketing_automation: built on top of mass_mailing and suffers from the
same issues;
USAGE: UNICODE
Unicode in emails should be supported. 'formataddr' and IrMailServer notably
received fixes to support unicode. Some check performed on email addresses
fail when unicode is involved, which leads to some emails not being sent
while they could.
SPECIFICATIONS
Add tests related to those corner cases. Also add tests for computation of
`email_formatted` field of Partner model. It currently generates wrong email
values for the same corner cases (multi emails, formatted emails).
Tests are also added for the computation of `email_normalized` field used
notably for blacklists. It is not computed currently when being in multi
email mode which prevents from any blacklist mechanism as well as make
email finding harder. `_mail_find_partner_from_emails` tool method is also
tested with multi email as it uses the same heuristic as normalized email
field.
Tests are also added for mass mailing, when having to mail documents that
have a partner with formatted emails / multi-emails, or that have an email
field with formatted emails / multi-emails.
Also restore a test removed at odoo/odoo@afcb734908 while it should have been
updated to state that email addresses containing non-ascii characters are
supported.
Add some tests for tools methods used in various email processing flows.
Unicode tests are also added.
In future commits we will try to make email usage a bit more defensive to
try to lessen issues with that kind of use cases.
Task-2612945 (Mail: Defensive email formatting)
X-original-commit: odoo/odoo@fc8442f133
Part-of: odoo/odoo#134934
Add 'id' in partner ordering, to be sure searching on duplicated partners is
deterministic.
In mail, use standard ordering when searching on users to be deterministic.
As ordering on users is based on name then login which is unique, this is a
safe ordering and can be used as it.
Task-2612945 (Mail: Defensive email formatting)
X-original-commit: odoo/odoo@1e6d50a141
Part-of: odoo/odoo#134934
MailTemplate model has a 'partner_to' field is dynamically rendered to contain
partners being recipients. After rendering it should hold a comma-separated
list of partner IDs.
However as we are unsure it was correctly written better be defensive. We now
check that we can effectively transform items to IDs using 'isdigit()'.
Task-2612945 (Mail: Defensive email formatting)
X-original-commit: odoo/odoo@a4e7f9b9dd
Part-of: odoo/odoo#134934
This commit:
- updates the DE balance sheet structure to use the correct one.
- updates the account tags used for l10n_de.
- renames the xmlids of the old tags to the new ones.
- updates the CoA for l10n_de.
task-3336261
closesodoo/odoo#134915
X-original-commit: 3b3c148827758d6dccf40f06f5834e33668a892a
Related: odoo/enterprise#47170
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
Signed-off-by: Ali Alfie (alal) <alal@odoo.com>
Before this commit, when changing the product template on a configurable
line with `no_variant` or `custom` attributes, an error would be shown
on the opening of the product configurator because those attributes were
not present on the new product template.
Now, `no_variant` or `custom` attributes will only be given to the
product configurator if it's open in `edit` mode.
closesodoo/odoo#134880
X-original-commit: 8434689d510a5a8fbcf81d2c123ad01d927efba3
Signed-off-by: Valentin Chevalier <vcr@odoo.com>
Before this commit, there was a 1 pixel border around the image that
remained visible after the "outline" hover effect mouse out animation
was triggered.
This happened due to a typo where the initial value for the "outline"
animation was set to 1 pixel instead of 0 pixels.
task-3495241
closesodoo/odoo#134975
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
This commit adds the module pos_paytm to add a new payment method of payTM
to point_of_sale.
task - 3377992
closesodoo/odoo#134960
X-original-commit: 2630c3e5f451df3b86f4906f7dfa3e5e1f5ec199
Signed-off-by: Harsh Modi (hamo) <hamo@odoo.com>
Before this commit, when showing list of attachments in a message
or attachment box, the images were too big. This made it hard to
see other content due to the big size of the images.
This commit fixes the issue by reducing the size of image previews
when in context of many attachments. When a message has a single
image, it keeps showing a big preview of this image.
Also slightly reduce size of images in attachment box, as they were
also too big.
closesodoo/odoo#134941
X-original-commit: cf2069e0f7cd36c4d2b3bcc79fdde7e0425e2e52
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Steps to reproduce:
- Install Loyalty module
- Go to Website and buy a gift card
- Checkout and pay the order
Issue:
Only 'Order Confirmation' email is sent directly to the customer,
gift card email is queued and sent later.
Cause:
`send_email` method is called with `force_send=False` by default,
which queues the email to be sent later.
Solution:
Add optional parameter `send_force` (default to `False`) to
`_send_creation_communication` method and call it with
`send_force=True` when confirming a sale order.
opw-3324386
closesodoo/odoo#134927
X-original-commit: cd9b47322948dda519230d25cf9ed31a3535f0c2
Signed-off-by: Nasreddin Boulif (bon) <bon@odoo.com>
The breakpoint() builtin was added in [Python 3.7] ([PEP 553]). It is
conveniently everything-agnostic, can be configured (including
disabled) via an envvar (`PYTHONBREAKPOINT`) and
code (`sys.breakpointhook`), and defaults to pdb (`pdb.set_trace`).
This is more flexible as it allows using arbitrary callables without
special casing, which mostly allows using less common
debuggers (e.g. IDE debug servers / hooks).
As using an empty string for the debugger name was not allowed
previously, co-opt that to invoke `breakpoint`. And deprecate the old
style.
[Python 3.7]: https://docs.python.org/3/whatsnew/3.7.html#pep-553-built-in-breakpoint
[PEP 553]: https://peps.python.org/pep-0553/closesodoo/odoo#134842
Related: odoo/documentation#5800
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Before this commit, CV's in demo data were created by transforming PNG files into Pdf files, meaning they weren't
being indexed properly (to make their contents searchable in recruitment for instance). This PR fixes that by making
their contents indexable properly by the ir.attachment model and thus searchable.
task-3471467
closesodoo/odoo#134530
X-original-commit: 67607ae2eb373d5909c538d58ce24a98d5a9db5a
Signed-off-by: Sofie Gvaladze (sgv) <sgv@odoo.com>
Signed-off-by: Jurgen Gjini (jugj) <jugj@odoo.com>
Purpose: set `lang_id` and `visitor_ids` fields on leads generated by a lead
generation rule.
We check that there are several languages used on the website to make sure the
visitor's language is relevant. Then we propagate the visitor's language when
creating leads.
Task-3293050
closesodoo/odoo#124303
Signed-off-by: Jérémy Hennecart (jeh) <jeh@odoo.com>
The problem was that if you have multiple stripe payment providers in
different companies, it may cause issues in getting the stripe payment
provider. That was because of using sudo in
calling `_get_stripe_payment_provider`.
The solution is to filter the result based on the company.
opw-3473577
closesodoo/odoo#134930
X-original-commit: 5ebd8d76a406b6199ea2a3c337a0b7205e861d1e
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Signed-off-by: Pedram Bi Ria (pebr) <pebr@odoo.com>
after using the token to link a database to an iot box, the odoo service
is not restarted and therefore no box is visible in the database.
Now we apply the odoo_restart() function regardless of the platform used
closesodoo/odoo#134928
X-original-commit: 70a66cfaceb9e241af23130287944d4e798327af
Signed-off-by: Quentin Lejeune (qle) <qle@odoo.com>
Reason:
Since the change to RelationalModel, the id is no longer present in the
record data by default.
Steps to reproduce the bug:
1. Create a new leave and save it (and keep it unapproved)
2. Click on your newly created leave, click delete and confirm
> Odoo Client Error
(unlinkRecord is called with an undefined value for recordId)
closesodoo/odoo#134885
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
In the floorplan, when clicking a table in edit mode, this table
changes to an editable table. The method setting the style of this table
was different from the one setting the style of a classic table leading
to placing it to high on the floorplan.
closesodoo/odoo#134810
X-original-commit: 54e51a2f247bff866d842f201841fd4c2c133d21
Signed-off-by: David Monnom (moda) <moda@odoo.com>
Signed-off-by: Adrien Guilliams (adgu) <adgu@odoo.com>
In the QUnit tests, the Chrome is mounted with the popup services mocked
but the globalState in the French localization for the PoS is using it.
This led to error when Chrome tried to load a popup. The popup service
is now correctly mounted in the QUnit tests of the PoS.
closesodoo/odoo#134736
Runbot-bug-id: 23080
X-original-commit: 53143a48e4804415c5e8c52c8e6f6cdbdafab8a8
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Signed-off-by: Adrien Guilliams (adgu) <adgu@odoo.com>
Steps:
- Install project & sales app
- Open project app
- Open Project
- Select any project
- Add sale order item
Issue:
- - the creation of SOLs on the fly , doesn't seem to be working anymore
Cause:
- There is no option for creating new sale order item
Fix:
- Appear create and edit the option for creation of Sale order item
Task: 3470877
closesodoo/odoo#134566
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Signed-off-by: Ritika Shekhawat (rish) <rish@odoo.com>
Commit [1] introduced a stronger regex to detect urls. Unfortunately,
it did so using a negative lookbehind, which is is only supported on
very recent version of Safari iOS.
This commit is an attempt at reproducing the same behavior, albeit
with a more complicated regex, unfortunately.
[1]: https://github.com/odoo/odoo/commit/a42a19e484d63cebeaed10b75ac20e507ff85d56closesodoo/odoo#134943
X-original-commit: ff99e454e2a38ae54aa57cb0df80df139e921ccb
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
When getting the available quantity of a product, it is possible to
specify the warehouse and/or the location in the context. However,
it does not correctly work. For instance, if we provide the stock
location ID (8) and the warehouse ID (1): we first use the view
location of the warehouse, and we then get the intersection between
this view location and the provided locations: nothing. In such case,
we should keep the stock location. Few other examples are given in
the test.
OPW-3450169
closesodoo/odoo#134910
X-original-commit: 8b53464dc51fb14cb37801a1d978185729c8e339
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Adrien Widart (awt) <awt@odoo.com>
Co-authored-by: Simon Schmid <simon.schmid@braintec.com>
Steps to reproduce:
- Create Storable Product "Super Test" with Cost of $1.
- Create Storable Product "Pack of Super Test" with Cost of $10.
- Create a Kit BoM that produces 1 "Pack of Super Test" from 10 "Super Test".
- Ensure product category on both products is set to Automated FIFO Inventory Valuation.
- Create a PO for 20 "Pack of Super Test" and confirm.
- Process the Delivery and look at inventory valuation.
- See that "Super Test" has moved quantity at 200 with Unit Value of 10 each (taken from kit product!).
Bug:
cost isn't split on the qty of the bom line
Fix:
take product quantities of the bom into consideration
opw-3453703
closesodoo/odoo#134909
X-original-commit: 8e516dccac4ced7e48adfabe756a899784bac9ca
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Walid Hanniche (waha) <waha@odoo.com>
The website menu is cached for each page, but there is no difference
between the cache of a logged user or of a public user. If you have a
page restricted to logged in users in the menu, this can sometimes lead
to:
(1) the link appearing in the menu even though the visitor is logged out
(because the cache was done when logged in), and
(2) the link not appearing even though the visitor is connected (because
the cache was done when logged out).
While (1) only leads to a 403 error if one clicks on the menu link, (2)
is more annoying as it hides a page that should be shown.
This commit therefore also caches the website menu depending on the
visitor being logged in or not.
Note that the same bug occurs for pages restricted to a specific group.
In these cases however, there is no technical solution as of now. It
should be considered as a limitation.
In such cases, workarounds are possible:
- Going on the "My account" page (by clicking on the username) will
always show the page.
- One could add a snippet on the homepage with a link to the restricted
page, and conditionally display the snippet only for users of that group
Steps to reproduce the bug:
1) Connect as admin, create a new page, open its properties and set its
visibility to 'Signed in', then publish it.
2) Logout, connect as portal
3) Logout, connect as admin
4) Unpublish and republish the page
5) Logout, reconnect as portal
6) Go to the homepage: the new page doesn't appear in the menu
7) Go to 'Contact us': the page reappears in the menu
opw-3445032
closesodoo/odoo#134908
X-original-commit: cfd19012f3a44b4961fe953cf077c55cc986d45c
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
To reproduce the issue:
1. In Settings, enable:
- Storage Locations
- Package
2. Create a product P
- Type: Storable
- Tracked by SN
3. Process a receipt with 1 x P, serial S
4. Return P in a package
5. Process a new receipt with 1 x P, still S as SN
Error: An error is displayed "The serial number has already been
assigned [...]". This is incorrect, the user should be able to
receive that SN.
After step 3, there exists a quant Q1: -1 x P at Supplier Location
with S. Then, after step 4, a new quant Q2 is created: 1 x P at
Supplier Location with S and the package. Because the field
`package_id` is not the same on Q1 and Q2, both quants are not merged.
As a result, step 5, we will update Q1 and have -2 x P at Supplier
Location with S. This will trigger the constraint, hence the error
message.
OPW-3390615
closesodoo/odoo#134902
X-original-commit: 0459e42ac452996831b0443bce088b84735975f0
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Adrien Widart (awt) <awt@odoo.com>
Steps to reproduce:
- Go to website > Create a mega menu.
- Go to edit mode > Switch to narrow width for the mega menu.
- After save, the update is lost.
After the refactoring in [1], non-returned class values (in the code
that replaces `_.without()` by native JS) will prevent setting the
option class on the mega menu, leading to the behaviour described above.
[1]: https://github.com/odoo/odoo/commit/f4f0f783183507df8227b37fe1234c256325df6d
opw-3465004
closesodoo/odoo#134901
X-original-commit: 293fce5cc5407705a4314c85fd780cff435202bc
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Outagant Mehdi (mou) <mou@odoo.com>
There is code to block the UOM changing if there are done moves.
Because it searches in non-sudo mode, it does NOT currently
stop you changing the UOM if the product has moves in a different
company.
closesodoo/odoo#134900
X-original-commit: 426744646c25e8c2b17e3a50de186bd91b5e645f
Signed-off-by: Tiffany Chang (tic) <tic@odoo.com>
Steps to reproduce:
- In Manufacturing, create a the following BoM
- Product: P1
- Components:
- 2 x P2
- 2 x P2
- Set the quantity in stock for P2 to 2
- Open the Overview from the BoM
Issue:
The 'Ready to Produce' column will indicate 1, as it checks line by line
how much product there is in stock compared to what is required for this
line.
To avoid this, we just need to sum the quantities required by products.
closesodoo/odoo#134890
X-original-commit: b8fda0bdb2238cba21a4541f4292da04003704cf
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Issue:
Displaying the data on the dashboard accounting can take up to 1 minute
Analysis:
The spreadsheet_fetch_debit_credit function needs a domain in order to compute the formulas. The domain being set in `_build_spreadsheet_formula_domain` use a like search for account_account.code on account_move_line which is a big table. Thus it does not scale well. There is also a unnecessary complexity on adding an "OR expression" on each one of the account_id code searched for.
Solution:
It can be optimized by searching for the full exhaustive (like in SQL) codes in account.accoun since it has way less records and thus more scalable. And then use an exact condition (=) which is faster than a like search. Also adding more readable while adding the balance_domain and pnl domain only once in the whole query.
Benchmark:
| Before PR | After PR |
|:----------:|:---------:|
| 8s 51 ms | 42 ms code search + 42 ms full query |
Related ticket:
opw-3328144
Version affected:
16.0 and above
closesodoo/odoo#134889
X-original-commit: a707f8345cec8f404077b184f4b0339932c10892
Signed-off-by: Lucas Lefèvre (lul) <lul@odoo.com>
This commit rewrite the module loader to simplify it and to improve error handling.
before this commit, you could have silent errors or "lucky" imports (import a module based on the fact that his asset will surely be load and if not, the error would be silent anyway).
e.g.: The tours cannot import modules extern to tours' bundle anymore. Or load module before your libs in assets.
TASK ID: 3266021
closesodoo/odoo#128502
Related: odoo/enterprise#44100
Signed-off-by: Bastien Pierre (ipb) <ipb@odoo.com>
Steps to reproduce:
- Create a serial tracked product
- Update quantity add random SN
- Edit "ir.sequence" for serial numbers
(search sequence with dev mode enabled)
- Add a prefix for exemple "xx%(doy)sxx"
- Manufacture the product and generate new serial
Bug:
if a serial already exist next number in the sequence will be generated
instead of using the sequence
Fix:
apply same logic than for lots i.e. first generate from sequence then
take next number if it already exists
opw-3291532
closesodoo/odoo#134879
X-original-commit: df96d9ca10c576981f6af79e330b5b46cdeea377
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Walid Hanniche (waha) <waha@odoo.com>
Before this commit, if you added a domain to a loyalty reward with
one of many2one fields like [("categ_id", "ilike", "test")], it wasn't
possible to open the PoS.
This commit addresses this limitation by replacing the many2one fields
with their corresponding value. To do this the product's field type is
loaded to ensure that this improvement applies exclusively to many2one
fields.
However, it's important to note that this improvement currently handles
only "one-level" of related many2one fields. Any domain that appears
like ("categ_id.foo", "ilike", "foo-val") won't function as expected.
opw-3473103
closesodoo/odoo#134811
X-original-commit: d0a6ab8d1f89f0dd2aa6641c63b6973ae7c753ad
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Signed-off-by: Pedram Bi Ria (pebr) <pebr@odoo.com>
Steps to reproduce:
- Install Attendances app and Employee app
- Setup an employee with a contract which work entry source is from
attendance
- Change the working schedule to different timezone, for example
Asia/Hong_Kong
- By default the working schedule should be start to work from 0800 to 1700
- Now create an attendance in the first day of the contract, i.e.
1st May 2023, check in time 0700, check out time 2000
- The total work hours should be 13
- However, in the work entry, the genearted work entry is 0800-2000, only
12 work hours.
Current behaviour:
The generated work entry mismatches the value of the attendance
Expected behaviour:
The work entry should match the attendance
Explanation:
This issue is casued by the timezone issue. When the system generate
the work entry, it will calculate the date_from datetime and date_to datetime.
Then it will compare between the attendance and the date_from datetime to choose
the larger datetime to put inside the work entry as start time.
However, the date_from datetime didn't consider the timezone of the working schedule.
In the above example, Asia/Hong Kong time is UTC+8 time. Therefore if we convert
the attendance time back to UTC time. It is check in time 30 April 2023, 2300 to
check out time 1 May 2023, 1200. In the mean time, if we compare between the date_from
datetime (1 May 2023, 0000) and the attendance check in time (30 April 2023, 2300).
The system will take the date_from time and therefore the generated work entry time
is incorrect.
task-3468012
closesodoo/odoo#134533
X-original-commit: 2baf4e3ebcd9ce3beb47ee2881aa3e8bd8a74cbf
Related: odoo/enterprise#47007
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Co-authored-by: Yannick Tivisse <yti@odoo.com>
To reproduce
============
* referrals -> configuration -> rewards
* try creating a new reward keeping description empty
* here description is required html field
* traceback on clicking save
Problem
=======
in case of html field, `this.data[fieldName]` is an object `Markup{''}`,
so `!this.data[fieldName]` is always `false` as objects are considered
as true value in JS.
Solution
========
in case of html, check the length of the Markup object
opw-3469539
closesodoo/odoo#134365
X-original-commit: dce8e1a8b6137c035488240f8004b870b73c8d51
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Abdelouahab Laaroussi (abla) <abla@odoo.com>
Co-authored-by: Niyas Raphy <https://github.com/niyasraphy>
Steps to reproduce:
- Install eLearning module
- Create a course with 2 slides and publish them
- Add a user as a member of the course
- Complete the first slide
- Add a new slide to the course and publish it
- Go to course and click on `Attendees` stat button
Issue:
The member completion percentage is not updated.
Cause:
When (un)publishing a slide, only the current user that publish the
course have his completion percentage updated.
Solution:
When (un)publishing, (un)archiving, unlinking or creating slide(s)
(slide must be published for the creation case), or when user mark
slide as (un)completed manually, update the completion percentage of
all members of the course except the members that already have
completed the course.
From version saas-16.3 we do not need the custom context key we
introduced in 94e2dd2 because we will not update the completion
percentage of members that have completed the course even if they
manually mark a slide as uncompleted.
opw-3225707
closesodoo/odoo#134845
X-original-commit: 2796b3163c02306f1309e2dde764fff2f1b287cc
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: Nasreddin Boulif (bon) <bon@odoo.com>
When passing a date out of the current as a props to the DateTimePicker
component, the chosen date is actually set but the calendar doesn't
rerender to display the corresponding month.
This commit fixes this behavior to properly focus the date's month.
closesodoo/odoo#134844
X-original-commit: 9dbb35479615f5aef7b22f21bf9f58f176874886
Signed-off-by: Julien Mougenot (jum) <jum@odoo.com>
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
Before this commit, when pinning an old message from thread,
then page reload then click on pinned message link in
notification message in thread at time of pinning message,
it fails to jump to the pinned message.
This happens because the message is not in the store, therefore
it attempts to jump to message `undefined`, which doesn't exist.
This commit fixes the issue by inserting the message before
attempting the highlighting that will jump to the message.
closesodoo/odoo#134818
X-original-commit: 70769963d240add98ed2ee231412201434a825ba
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
This traceback raises when user tries to create payment without payment date.
To reproduce this issue:
1) Install 'account'
2) Open any existing invoice (not a DRAFT one)
3) Click 'REGISTER PAYMENT' button.
4) Now remove 'Payment Date'
Error: 'Expected singleton: account.payment.term()'
Note:- 'TypeError: unsupported operand type(s) for +=: 'float' and 'NoneType''
is also produced for some invoices.
When user removes 'payment_date' '_compute_amount' method will be called, In which
'_get_total_amount_in_wizard_currency_to_full_reconcile' method is used.
In '_get_total_amount_in_wizard_currency_to_full_reconcile' method,
'_get_total_amount_using_same_currency' is used to get total amount.
On '_get_total_amount_using_same_currency' method payment_date is passed as an
argument for '_is_eligible_for_early_payment_discount' method.
See: https://github.com/odoo/odoo/blob/ed2e26633458f1284437286f71eba43c8d1818a7/addons/account/wizard/account_payment_register.py#L490-L498
On '_is_eligible_for_early_payment_discount' method if no reference date,
its returning True. which leads to above traceback
See:
https://github.com/odoo/odoo/blob/ed2e26633458f1284437286f71eba43c8d1818a7/addons/account/models/account_move.py#L1902-L1905
sentry-4337953422
closesodoo/odoo#134721
X-original-commit: a05be50b9cf75fb0226f7b464b3a8f580465d462
Signed-off-by: Laurent Smet (las) <las@odoo.com>
This commit adds the discuss message features to the livechat
threads:
- Edition/deletion of messages
- Reactions
- Replies
It also improves the history view present in the channel form view
by showing replies.
task-2742676
closesodoo/odoo#133456
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Removed the `ListRenderer` overload in `payment_term_line_ids.js` to fix
an issue where trying to set `this.props.list.editedRecord` to null was
causing a stack trace error when navigating away from a Payment Term
lines.
The original intention was to prevent the discard of new records when
clicking outside of the list, especially when the user is not required
to edit something on the newly created record.
It has been replaced by an overload `X2ManyField` component making the
`AddInLine` method mark all the new records as `dirty` by calling the
`update` mehod on them with an empty object to prevent them from being
discarded.
closesodoo/odoo#132257
Task-id: 3460696
Signed-off-by: Habib Ayob (ayh) <ayh@odoo.com>
This commit fixes an undeterministically failing tour.
`test_form_view_resequence_actions`
*Reason*
This test tour prepares some data before running the test.
The data preparation missed to specify the sequence of the actions.
*Fix*
The sequence is now set in the data preparation.
This reflects the way the form view would create the
actions if they were created through user input.
See the `canResequence` part in `_createNewRecordDatapoint`
inside `@web/model/relational_model/static_list`
Fixes runbot error 24578
closesodoo/odoo#134802
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
before this commit, the create/new button is shown in
the payment provider form, where us it is removed in
the kanban and tree
after this commit, the create/new button will be removed
from the form and users can use duplicate option to create
new provider
closesodoo/odoo#134779
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
This commit fixes the "website_livechat_chatbot_flow_tour" which was
nondeterministic. This was due to the message service update which was
assigning data blindly based on the payload instead of handling it
properly. This is solved by enriching the chatbot step instead of
overwriting it.
runbot-24625
closesodoo/odoo#134778
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Thibault Delavallée