Thanks to changes in 82314364c6029a83 the auto-lock settings
also works for public users. But, going from self.env.user to
self.create_uid to check the group lead to a traceback when
self.create_uid is not a singleton. This is because has_group expects
a single record.
To fix that, this commits checks the group of the create_uid of the
first record in self. Because sale.group_auto_done_setting is an
implied_group of a res.config.settings parameter, it's enough
to only check for the first record in the recordset.
To reproduce:
- Install sale
- Create a quotation as Mitchell Admin
- Create a quotation as Marc Demo
- Create a cron that searches on all draft sale.orders and confirm them
in batch
- Run the cron
-> Singleton Error
closesodoo/odoo#152338
X-original-commit: dfb2eaaaf5c08c0aa46cc5eb0defdc97b35953b0
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Signed-off-by: Aurélien van Delft (avd) <avd@odoo.com>
Before this commit:
- In the project module, when a user opens the color picker, it opens as
a dropdown even if there is not enough space available, resulting in
some parts of the color picker being inaccessible.
- In the project, when a user opens the color picker a second time, it
always opens as a dropup, even if there is space available for it to
open as a dropdown.
After this commit:
- Now, when a user opens the color picker, it opens as a dropup when
there is not enough space available for the color picker to open as a
dropdown.
- The color picker will open as a dropdown when there is enough space
available.
task-3608803
closesodoo/odoo#152337
X-original-commit: b60aa4f4effcec38d0e18707ce268c0cc07a2515
Signed-off-by: Antoine Guenet (age) <age@odoo.com>
In form views, when the user closes the tab while having unsaved
changes, and if those changes are valid, we want to save them
automatically before leaving.
Before this commit, there could be situations where the changes
weren't actually saved. For instance, if they involved an heavy
payload for the write rpc, or if the network connection was poor,
it might happen that the xhr is killed. Or at least, browsers do
not offer any guarantee to wait for those xhr to reach the server.
Instead of a classical xhr, we thus use navigator.sendBeacon which
ensures that the data will be sent reliably [1]. There's a drawback
though, as its payload is limited. When the payload is too heavy,
sendBeacon simply returns false and does nothing. In this case,
we prevent the page from unloading and display a notification
suggesting the user to manually save his changes before leaving.
[1] https://developer.mozilla.org/en-US/docs/Web/API/Navigator/sendBeacon
Task 3537838
closesodoo/odoo#151834
X-original-commit: 0b53daa60ee5b370def21c8e0e30a6819597a0e4
Related: odoo/enterprise#55457
Signed-off-by: Francois Georis (fge) <fge@odoo.com>
When a customer sends a message to Odoo via WhatsApp, their number is saved in the `phone.blacklist` model, but the active state is set to False. If the customer sends 'STOP', it will be set to True, and if the customer sends a new message, it will again be set to False.
Before sending a message from Odoo to a customer via WhatsApp, we check if the number is in the `phone.blacklist` with this line in whatsapp_message.py
if self.env['phone.blacklist'].sudo().search([('number', 'ilike', number)]):
In SaaS 16.4, this line returns the following SQL request:
SELECT "phone_blacklist"."id" FROM "phone_blacklist" WHERE (("phone_blacklist"."active" = true) AND ("phone_blacklist"."number"::text ILIKE '%32491730941%')) ORDER BY "phone_blacklist"."id";
Here, we check if the Active state is True to block the message if necessary.
In 17, this same line returns this SQL request:
SELECT "phone_blacklist"."id" FROM "phone_blacklist" WHERE ("phone_blacklist"."number"::text ILIKE '%32491730941%') ORDER BY "phone_blacklist"."id";
I correct it in a PR https://github.com/odoo/enterprise/pull/55498
But if we go further we find that it's really because of the active_test = False of this line in thread.py
thread = request.env[thread_model].with_context(active_test=False).search([("id", "=", thread_id)])
from this commit
https://github.com/odoo-dev/odoo/commit/8b2605b99348b7707b3db3db46af880c17c7029c
with the fix of this PR, the discussion on Whatsapp is now possible and we keep the fix of the previous commit.
opw-3704136
closesodoo/odoo#152273
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Before this commit:
When in a checklist where first and second checklist are marked done after
selecting first and second checklist and deleting it the third checklist would
be marked as done.
After this commit:
Deleting previous done checklist would not affect the current checklist.
task-3203889
closesodoo/odoo#152387
X-original-commit: 2ddda7a66076ef99e1aa4ba9d463b0fd2f73626d
Signed-off-by: Antoine Guenet (age) <age@odoo.com>
Signed-off-by: Deependra Solanki (deso) <deso@odoo.com>
Commit [1] introduced a way to "hide" an ir.ui.view through a new
visibility field.
That field has multiple possible values to restrict the access. One of
those is "Restricted Groups", but when selected it's really hard to
figure what to do next because nothing happens on screen: there is no
"groups" field where to add the groups.
Those groups should actually be added a bit below, in the groups_id
field which is "hidden" inside the "Access Rights" second tab.
This is because the groups_id field already existed (in base module)
before introducing the website visibility feature which just relied on
that field when set to "Restricted Groups".
Note that another possible value for visibility is "Password", and in
this case a password field appear below the visibility field as one
would expect.
[1]: https://github.com/odoo/odoo/commit/e239934abe456257c9dc285d1ad9829c0353900cclosesodoo/odoo#151602
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
This commit's purpose is to fix the display of the default field when
entering studio mode from a task form with no allocated time.
Step to reproduce :
-open project
-open office design
-create new task/select a task with 0 allocated hours
-open studio
the display of the field 'allocated time' is partially hidden by the
span 0%
Source of the bug:
the widget timesheet_uom_no_toggle has a max width of 7CH, which is too
little to allow the full display of the default name.
Solution:
Create and add a new scss class which is only active in studio mode.
Version affected:
saas-16.2 to master
task - 3553101
https://www.odoo.com/web#id=3553101&menu_id=4720&cids=1&action=333&active_id=4105&model=project.task&view_type=formclosesodoo/odoo#152159
X-original-commit: 30092f7a67579551ac3fb7a7d5668699cae8b3aa
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
In Language settings, change decimal separator to ','
Go to Journal Items
In the search bar input '4,50' and search for 'Amount'
Error: ValueError: could not convert string to float: '4,50'
This occurs becuase when the search component assemble the domain for the
orm we use the original string '4,50' and not the parsed value '4.5'
opw-3700578
closesodoo/odoo#152075
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
9e0277e changed the reporting from users to employee and the user field was removed
but a record rule was forgotten.
opw-3653746
closesodoo/odoo#151992
Signed-off-by: Rémy Voet (ryv) <ryv@odoo.com>
Signed-off-by: Nicolas Danhier (nda) <nda@odoo.com>
When the user passes a wrong domain in the record rule, the system allows users
to save that record without checking whether the new domain is correct or
incorrect.
steps to reproduce:
- create an ir.rule on res.users and write a domain with a typo
before this commit:
- users can't log into odoo
after this commit:
- an error is raised to prevent saving a bad domain
opw-3653746
X-original-commit: dc8dfc246d3de9d447a360f15f41f2388ac8d638
Part-of: odoo/odoo#151992
Steps:
- In mobile install project
- Project.project form view
- Go to the project settings
- In Alias Domain(Custom Email Servers)
- The input alignment is not good
Issue:
- The input should go under the alias domain in project.project
form view in mobile
Cause:
- Here they adding extra bootstrap class so that's why it will be
showing in correctly
Fix:
- By removing the bootstrap class of 'oe_inline' the problem will be solved
task-3550702
closesodoo/odoo#151829
X-original-commit: 2819d6e076404140f5c26e76829a8f5bb171cf14
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Since https://github.com/odoo/odoo/pull/1432[FIX] base/models: Prevent incorrect behavior in `_read_group_format_result`
To reproduce the problem, you need to ensure that a read_group returns several groups,
with the first element being a group with no value if you choose to group on a many2many (see test).
Here's an example to reproduce in website_sale:
- Install `website_sale` without demo-data
- Go to `eCommerce/Products`
- Create a new product
- Go to `Sales` tab in the product form view
- Set a new `eCommerce shop/Categories` like `Sales`
- Save
- Return to `eCommerce/Products`
- Remove default filters
- Group by `Website Product Categories`
- There are two group: `None` and Sales`
- Click on None
- Traceback
In this case, the orderby is website_sequence:sum ASC,
and will therefore return as first group None containing `Delivery Product`
and as second group `Sales` containing the newly created product.
What happens is that `read_group` will build `rows_dict` thanks to `_read_group`.
https://github.com/odoo/odoo/blob/cb67b4e1472ae6689e943ade1e27cb43e8d87025/odoo/models.py#L2724
this `rows_dict` will be ordered according to `orderby`and then passed as an argument to the `_read_group_format_result` function
https://github.com/odoo/odoo/blob/cb67b4e1472ae6689e943ade1e27cb43e8d87025/odoo/models.py#L2759
For each row, this function will convert `row[group]` (group in this case is the many2many field)
into a tuple containing (id, displayname) in case the value (`row[group]`)
is found which will be used to build the domain `[(field_name, =, value)]`.
So, for example, replacing
```py
rows_dict = [
groupbyField': odoo.model(1),
groupbyField': odoo.model(4),
]
```
with
```py
rows_dict = [
groupbyField': (1, 'First record'),
groupbyField': (4, 'Fourth record'),
]
```
https://github.com/odoo/odoo/blob/cb67b4e1472ae6689e943ade1e27cb43e8d87025/odoo/models.py#L2460-L2462
If the value is False, we'll use the 'not in' operator instead.
To do this, we need to retrieve the ids of all the other groups to
include in this one all the records that aren't in any group,
either by retrieving the id if it's a model,
or by retrieving the first element of the tuple if it's already been modified,
or by directly retrieving the value of the field if it's not a many2x.
Except that if the first element is directly a group without a value,
it won't be able to retrieve the values of the other groups,
because the condition for checking that it's a `BaseModel` instance contained a typo
https://github.com/odoo/odoo/blob/cb67b4e1472ae6689e943ade1e27cb43e8d87025/odoo/models.py#L2465-L2467closesodoo/odoo#151497
Signed-off-by: Rémy Voet (ryv) <ryv@odoo.com>
This is a backport, with the original commit occurring in master:
e80f5e3.
The motivation for backporting these states is that they're useful in
the upcoming eTIMS OSCU integration for Kenya, which targets version
17.0.
Added Kenyan states as per https://www.iso.org/obp/ui/#iso:code:3166:KE
Task ID: 3665315
closesodoo/odoo#152256
Signed-off-by: Josse Colpaert <jco@odoo.com>
Logo on pdf send to customer after generating coupon code was disorted if
it was not in certain ratio.
task-2588963
closesodoo/odoo#152245
X-original-commit: b1b94a075672067325ddcc125cbc57ae214b0a9a
Signed-off-by: anko-odoo <anko@odoo.com>
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Steps to Reproduce
==================
1). Create an empty quotation and link it to a mass mailing
(same medium and source).
2). Open the mailing form, the stat button displays "1 Quotation"
3). Click to open it
-> Empty Screen
Technical
==========
There are no records in this view as it is based on the sales report model.
If a quote has no line, there is nothing to display.
After this commit
=================
Now empty quotes will not be counted.
Task-3635429
closesodoo/odoo#152241
X-original-commit: 05c2859ccebcfc60e27a4833c57f98c2d7944bbb
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
If reordering rules' visibility is set bigger than DAYS_FROM_TODAY_TO_ORDER
(plus lead time). Then the order should be included in the calculation of
quantity to order.
┌─ Today ┌── Scheduled Delivery
│ (2024-01-01) │ (2024-02-01)
│ │ aka commitment_date
│ │
▼ ▼ time
──────────────────────────────────────────►
◄────────────────────────────►
DAYS_FROM_TODAY_TO_ORDER
◄────►
lead_time
Before this commit visibility_days were taken into the account only if
there forecasted quantity was lower than product minimal quantity. This
commits ensures that the visibility_days will always be included into
the calculation.
[Reproduce]
- install stock,purchase,sale_management
- Create a product P (storable)
- Add vendor V under the purchase tab
- Create Reordering with route buy, vendor V, min 0, max 0
- Create a Sale Order for 1 unit of P, under the 'Other Info' tab, set the Delivery date to 1 month in the future, Confirm.
=> If you go back to the reordering rule, you have Qty To Order at 0 (ok)
- Set Visibility Days at 40
=> Qty To Order is still at 0, even though it should now see the sale order we made before (bug)
- Set the Min qty at 1
=> Qty To Order is now at 2, it found the sale order we made, and computed the correct quantity. (ok)
- Set the Min Qty back to 0
=> Qty To Order is back at 0 (bug)
opw-3638398
closesodoo/odoo#152167
X-original-commit: 8a5541d16caa793c7549d78c082f7879d3aba233
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Andrzej Pietrusiak (pian) <pian@odoo.com>
Commit that introduced the issue: fbc167bf84340b4bb6d0f8c59f2734814f56c6df
Issue:
======
Adding a table in a long chatter message with scroll raise a traceback
Steps to reproduce the issue:
=============================
- Switch to RTL lang
- Go to any form view and open the editor composer to create a log note
- Write a lot of lines so that the scrollbar appears
- Add a table
- Log the note
- Try to scroll -> traceback
Origin of the issue:
====================
The `_onScroll` method is called and it has `this._rowUiTarget` as the
row from the composer dialog which is not in the ui anymore so
`closestElement(row, 'table')` will return `null`.
Solution:
=========
We just do nothing when the element is not connected.
task-3707808
closesodoo/odoo#151800
Signed-off-by: Antoine Guenet (age) <age@odoo.com>
Steps to reproduce:
- Enable Automated Valuation.
- Set the cost of Acoustic Bloc Screens to 287.33.
- Set the Product Category on the product to have AVCO automated valuation.
- Enable Cash Rounding.
- Create a Cash Rounding (see tests).
- Make an invoice selling one Acoustic Bloc Screen and remove the tax.
- Set the Cash Rounding on the invoice under "Other Info".
- Confirm the invoice.
Bug:
when summing the ammount of all the lines the result is slightly off
(float accuracy) this will create an unnecessary cash rounding to
compensate
Fix:
round the sum to the currency precision before checking for the cash rounding
opw-3681307
closesodoo/odoo#152112
X-original-commit: 4a6ec1a667ee3d2fba00d277b4c7e8a730a45ecd
Signed-off-by: Walid Hanniche (waha) <waha@odoo.com>
Current behaviour:
When planning more than 88 work orders,
there is a recursion error.
Steps to reproduce:
1. Go to Manufacturing
2. Operations > Manufacturing Orders
3. Create a manufacturing order
4. Add 90 work orders
5. Click on Confirm
6. Click on Plan
7. Recursion error
Cause of the issue:
Maximum depth of the Python interpreter stack
The recursion limit being set at 1000
by default (with getrecursionlimit)
Fix:
Upped the limit to ~320 work orders
opw-3651494
closesodoo/odoo#152198
X-original-commit: 25081646ef0b679356ad46f62fe737fb44269baf
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Co-authored-by: Rémy Voet <ryv@odoo.com>
Issue:
======
Discard changes of form having html field doesn't remove the changes
applied in the html field.
Steps to reproduce the issue:
=============================
- Open any mail template
- Add modification on the template
- Click on discard changes
Origin of the issue:
====================
The function `this.props.update` is responsible of updating `_changes`
and updating the record which is called for usual input_field using
`useInputField` hook, but since this html field isn't of the same format
we didn't use it and it's only called in `commitChanges`
Solution:
=========
We update the value of in `_onWysiwygBlur` in case we are `inlineStyle`
so we don't commit but we save the changes for the discard to work
properly.
task-3453497
closesodoo/odoo#151993
X-original-commit: 1624da6f42561792be816836c6d88bc986c3538a
Signed-off-by: Antoine Guenet (age) <age@odoo.com>
Signed-off-by: Mahdi Cheikh Rouhou (macr) <macr@odoo.com>
Forgot to update the test so that it tests both warning and success
notifications.
closesodoo/odoo#152186
Signed-off-by: Laurent Smet (las) <las@odoo.com>
When fields are submitted through the website form, their values are
used as they are. Because of this it is possible to include HTML in the
sent email while this is not desired.
To avoid this, this commit HTML-encodes the values received for custom
fields and html fields.
Steps to reproduce (with default_field):
- Go to the "Contact us" page with form untouched (it should send mail)
- Fill in the form
- In the name put John <b>Smith</b>
- Submit the form
- You will see that Smith will be in bold in the received mail
Steps to reproduce (no default_field):
- Install website_recruitment
- Go to the "Contact us" page
- Enter edit mode
- Change the form type to apply for a job (and select a job to apply in
the right panel option, like "Consultant")
- In debug mode in the backend, go to ir.model fields
- Find "Applicant (hr.applicant) record and edit it
- Remove the website_form_default_field_id in the "Website Forms" tab of
the form view of this record
- Back to the "contactus page", add a new custom field to the form
- Now, out of edit mode, add "<b>Something</b>" in the custom field and
submit the form
- Find the job application in the backend in the recruitment module, it
should be inside the "Consultant" job.
- You will see the "Something" in bold in the chatter
Note: In Odoo 16.2, commit [1] is already doing something similar for
one of the 2 places fixed here.
[1]: https://github.com/odoo/odoo/commit/3e7acff8d9302c3332fe3011f75374170484c61d
task-3650953
closesodoo/odoo#152170
X-original-commit: c2e934f421a8afee4ce537b1e03871a1bcef99d1
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Bram Van Gaal (brvg) <brvg@odoo.com>
Co-authored-by: bram1000 <brvg@odoo.com>
Co-authored-by: Benoit Socias <bso@odoo.com>
Install Studio
Activate form view of journal items and disable readonly flag on Analytic distribution field.
Create a journal entry adding analytic distribution to a line and post.
Now open the journal item in form view and try to change the analytic distribution
Action will be blocked by error
This is caused by the onchange in _inverse_analytic_distribution. As the
method take care of unlinking and creating new lines no more actions are
required by the orm
opw-3690346
closesodoo/odoo#152143
X-original-commit: 89ef4ae17a507007855ce21e166bec82fc25bd93
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Andrea Grazioso (agr) <agr@odoo.com>
HOW TO REPRODUCE
================
Don't sign in and go to front-end > Courses > Trees, Wood and Gardens >
Main Trees Categories. '< Prev' and 'Next >' are not centered vertically.
HOW TO FIX
==========
Slides navigation buttons are <a> HTML elements. Add them bootstrap
class 'my-auto' to handle their height properly.
task-3633452
closesodoo/odoo#152130
X-original-commit: 4fb0631526153272c7fe203b35980fd7b18f6125
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Before this commit:
if you have <p> within <li>,sometimes removing the <p> will result in the loss
of all classes.
After this commit:
Replace p inside li with span while preserving classes.
task-3546209
opw-3602047
closesodoo/odoo#152104
X-original-commit: e396a1097463d014a1aba553022451365b31f5f3
Signed-off-by: Geelen Sébastien (sge) <sge@odoo.com>
Current behavior:
When you try to pay with razorpay, you got an error saying the phone
number was missing.
Steps to reproduce:
- Setup RazorPay
- Set a phone number on admin
- Go to the POS
- Add a product to the cart
- Click on the payment button
- Select razorpay
- Scan the QRCode with your phone (make sure you'r connected on the
admin account)
- Try to finalize the payment
opw-3669600
closesodoo/odoo#152040
Signed-off-by: Vlad Stroia (vlst) <vlst@odoo.com>
Before this commit:
`destroyLinkTools` function sets the selection to entire link. However, in
case where a website snippet had a structure like
```html
<a>
<div>
<i class=fa-xxx></i>
<div>
<h4>Text</h4>
<font>Text</font>
</div>
</div>
</a>
```
selecting the complete link caused problem. The toolbar couldn't be
updated correctly, also one could not change the a tag of a single element
within the link.
After this commit:
`destroyLinkTools` selects the `anchorNode` and the `focusnode` of the
selection instead of entire link.
task-3245819
closesodoo/odoo#151752
X-original-commit: e88ffecc4bdb0480fc1d47af14558f28f72a665d
Signed-off-by: Antoine Guenet (age) <age@odoo.com>
Commit [1] introduces an approach to preserve the cursor in `setTag` when new
node is inserted. It used `setStart` at `firstLeaf` of `startContainer` and used
offset of the `startContainer` similarly for `endContainer` which is incorrect
and would throw traceback regarding no child at that offset.
This commit fix it by getting the correct startContainer and endContainer when
new node is created.
[1]: d04e32c
task-3245819
X-original-commit: d9095d277e4dbfa318ff6ddd2692dbb3c71e4775
Part-of: odoo/odoo#151752
After upgrading (specifically following this [upgrade PR]), when editing
an element, the editor may be tricked into considering that the page
isn't correct even though it is. It causes the "discard" dialog to open.
Steps to reproduce after the [upgrade PR]:
- Remove the CTA in 16.0 with the bin icon (on the button itself, or
from the edit panel, next to the "Block" section).
- Upgrade to 17.0.
- The button is back. Edit the header and click to hide it.
=> a dialog opens "Are you sure you want to discard your changes?".
- Click either "yes" or "cancel".
=> either way, nothing is discarded nor cancelled.
[upgrade PR]: https://github.com/odoo/upgrade/pull/5500
Related to opw-3644220
closesodoo/odoo#151291
Signed-off-by: Guillaume Dieleman (gdi) <gdi@odoo.com>
When repartition_lines are added to an already existing account_tax
record, on upgrade, the new repartition lines are inserted with just
tags, which results in the insertion of null value in document_type
column.
To reproduce:
1. Modify l10n_fr/__manifest__.py version to 2.0
2. Create an empty DB
3. Start ./odoo-bin -c ../.myodoorc -i l10n_fr with demo data
4. Stop the database (can dump it for convenience)
5. Start ./odoo-bin -c ../.myodoorc -u l10n_fr
6. Add a couple of repartition lines (invoice + refund) to an existing tax to odoo/addons/l10n_fr/data/template/account.tax-fr.csv
7. Modify l10n_fr/__manifest__.py version to 2.1
8. Start ./odoo-bin -c ../.myodoorc -u l10n_fr
closesodoo/odoo#149733
X-original-commit: 8dfdc6f9abe490f46d3df92bf056e334e1a02750
Signed-off-by: Aslam Noman (asno) <asno@odoo.com>
The expression record.id relies on a Python descriptor that has some
overhead, which is small but not negligible when used in a low-level
method of the ORM. We simply factor out this expression in order to
evaluate it once for the method.
closesodoo/odoo#149624
Signed-off-by: Raphael Collet <rco@odoo.com>
In e0297bdac4, the creation of a new
record always patches the inverse fields of relational fields in order
to make the cache of those inverse fields consistent.
For instance, when creating a new record like
user = model.new({'group_ids': [Command.link(group.id)]})
The inverse of field 'group_ids' on the new record having 'group' as
origin is patched so that its value includes record. A side effect of
this mechanism is that it fetches group.user_ids in order to patch the
value of new_group.user_ids, where 'new_group' is the new record having
'group' as origin.
The side effect described above is problematic when that inverse field
has huge cardinality, like hundreds of thousands of records, and this
performance overhead is unacceptable when the inverse field is actually
not used at all.
We address this performance issue by patching the value of x2many fields
only when they are used. If the value of the field is not in cache yet,
the patch is applied once a value is put in cache. If the field is not
used, the patch is simply never applied.
Part-of: odoo/odoo#149624
To prevent no-wanted behaviour on empty list during creation, we will check it before the call creation
closesodoo/odoo#144394
Signed-off-by: Sofie Gvaladze (sgv) <sgv@odoo.com>
STEP TO REPRODUCE :
1. create a time off type with alloation_validation_type == 'no'
2. create a batch allocation (with company, department, employee tag or employee mode but with some employees)
3. records will be duplicated
Expected behaviour : no duplication
task : 3615657
Part-of: odoo/odoo#144394
Since searches in the home screen are now handled by the command palette,
some ARIA attributes are required for assistive technologies to know
what is the currently-selected result. That because the actual focus is
always on the search box, while the actually-selected result is
highlighted by toggling classes, which makes not possible anymore to
know what is the selected result for e.g. screen reader users.
For more info, see original implementation on enterprise's home menu on
[1]. This commit is just re-applying such changes here.
[1] odoo/enterprise#14511closesodoo/odoo#152147
X-original-commit: 9764e6f7fe39a10f3b04e1764110d8c274d0431a
Related: odoo/enterprise#55562
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
Steps:
- Go to Invoicing, list view.
- Select two records with the same partner.
- Send receipt by mail.
Issue:
Just one mail is sent.
Reason:
``mailing_document_based`` parameter which is used to enable sending multiple records to the same recipient
is not passed in the context.
opw-3552562
closesodoo/odoo#151273
X-original-commit: b806ef9fbdbb149ab0df1b63902236982ca88233
Signed-off-by: Habib Ayob (ayh) <ayh@odoo.com>
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Consider an invoice that was reset to draft.
When its is edited to be '/' (and the record is saved) an additional "Draft" title appears.
It should not appear.
After this commit the "Draft" title will not be shown on invoices
that were posted before.
task-3680398
closesodoo/odoo#152110
X-original-commit: d0876de81dc66cb6483598deb33bf6c81212ec89
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
Signed-off-by: Sven Führ (svfu) <svfu@odoo.com>
Steps to reproduce:
- Create a branch for a company (e.g. Branch X)
- Go to "Website / Configuration / Websites"
- Create or configure a website on Branch X (e.g. Website X)
- Go to "Website / Configuration / Settings"
- Select Website X
- Set "Display Product Prices" to "Tax Included"
- Create a product for a price of $100 and a tax from parent company (e.g. 15%)
- Go Website X
- Edit Home page and add Products snippet
Issue:
On the Products snippet, the price of the product should be "Tax Included" ($115),
but it is not. The displayed price is $100.
Cause:
When computing the prices, taxes from parent companies are not taken into account.
This fix is a complement to https://github.com/odoo/odoo/pull/151223
opw-3660156
closesodoo/odoo#152105
X-original-commit: ba6cb4f16fdbfa121e52f3c17c70e9783e8c2ea5
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Signed-off-by: Anh Thao Pham (pta) <pta@odoo.com>
Before this commit, the website of the industry module ends with
`/False`. This is because the website of the module requires the name
of the module. It is therefore added in the _get_modules_from_apps
method.
closesodoo/odoo#152078
Signed-off-by: Pierre Masereel (pim) <pim@odoo.com>
Steps to reproduce:
===================
1. Configuration > Projects
2. Open any project
3. Setting tab
4. Document field
5. Create and edit a new workspace.
6. Inspect mobile view
7. Save it or discard it -> traceback occurs
Technical Reason
================
The dialog values are prepared based on the desktop view, which results in the
scrollToOrigin function is not being prepared when the condition is not met.
Consequently, when the view is switched to mobile and inside the onWillDestroy,
the scrollToOrigin is called but it is not prepared so traceback occurs.
After this commit
=================
Now the function will be prepared even if we are not in the mobile view and
traceback will not occur.
Task-3573747
closesodoo/odoo#152074
X-original-commit: bc0a313f56347ea74eea1e5106cef8d86357c9ef
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
The reCaptcha score was set by default on 0.5. According to [Google's
documentation], that score isn't valid by default. It should be one of
0.1, 0.3, 0.7, 0.9. To use other values you must first go through a
security review from reCaptcha.
[Google's documentation]: https://cloud.google.com/recaptcha-enterprise/docs/interpret-assessment-website#before_you_begin
task-3585213
closesodoo/odoo#152073
X-original-commit: 6f18069c71fc09fc624df03243bccedf0dbf96e5
Signed-off-by: Benoit Socias (bso) <bso@odoo.com>
Signed-off-by: Robin Lejeune (role) <role@odoo.com>
The 'saveModifiedImages' function is already called by the parent class'
(HtmlField) 'commitChanges', in which the replacement of the images' src
attribute and the removal of the 'o_modified_image_to_save' class are
done with the editor's observer deactivated.
Before this commit, calling this function before the call to
super.commitChanges resulted in converting the images within a history
step that was later reverted by the 'historyRevertCurrentStep()' call at
the end of the '_pendingCommitChanges' function.
Morover, the '$content' property is undefined.
closesodoo/odoo#152065
X-original-commit: 622ca94b958444ae2279f13871c6a05942fdaf0e
Signed-off-by: Geelen Sébastien (sge) <sge@odoo.com>
Signed-off-by: Rodolpho Cammarosano de Lima (rcdl) <rcdl@odoo.com>
Before this commit, base64-encoded images were converted to attachments
only for the body_html field, leaving the body_arch's content unchanged.
As a result, every time a record was updated, the body_html content,
which is generated from the body_arch's content, would have the same
base64-encoded images, which were converted again to new attachments.
Moreover:
- the created attachments were not linked to the mailing record (no
res_model and res_id).
- the attachment name contained "cropped_image", even for images that
were not a result of cropping.
- when the image conversion happened for a record in creation, the
resulting attachment name was "cropped_image_mailing_False_0" (or any
other number, the relevant part is "False", where the record's id was
expected).
- the body_arch could take an excessively large amount of space in the
database table, due to its base64-encoded images (see [1]).
This commit makes sure the body_arch has its images converted to
attachments as well, and also makes sure such attachments are reused
when replacing the image sources in the body_html, instead of creating
new ones.
Besides, the "cropped_image_mailing" in the attachment's name was
replaced by the more generic "image_mailing".
Lastly, when a record is being created, the conversion to
attachments now happens after the call to super().create, so that the
record's id is known when creating attachments.
task-3479586
[1]: https://github.com/odoo/odoo/pull/128452
X-original-commit: 9c5a56d2be9c1a480d526755327c79e2daa90a35
Part-of: odoo/odoo#152065
Although the lack of these statuses does not block the flow of a
transaction, they create confusing records for the user.
- Authorized: it is returned by Mercadopago when it authorizes
payments by bundle. It should behave as a pending payment as it's not
yet captured and could still be canceled by timeout.
- Cancelled: It is returned by Mercadopago when a payment is not made
within the expected timeframe. This prevents odoo from leaving payment
transactions in draft that cannot be cancelled by the customer.
closesodoo/odoo#152064
X-original-commit: 44790e7f115610548b140c0d53f97bb11f973224
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Signed-off-by: Morgane Demesmaeker <edm@odoo.com>
This commit fixes a ValueError that occurred when an order contained
two or more order lines with kits. The error was caused by the
'self.qty' expression, which failed when 'self' was a recordset.
The code has been updated to correctly handle multiple order lines
with kits.
opw-3708950
closesodoo/odoo#152053
X-original-commit: 668933002e2912f8df531b065f81777b2b491514
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Signed-off-by: Pedram Bi Ria (pebr) <pebr@odoo.com>
Aurelien van Delft (avd)