Recently, the vat validation was changed to
support 16 digits vat introduced in Indonesia
in January 2024.
This change replaced the stdnum validation,
but did not handle vat numbers written using
the standard presentation format.
This is fixed here, where we will remove the
characters used in this format and strip the
vat before doing the validation on the digit
amount.
closesodoo/odoo#148386
X-original-commit: 4c8629228f7842501d5a067451abca24d1089bf9
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Nicolas Viseur (vin) <vin@odoo.com>
The existing implementation for the fiscal device applies a number of
limitations to the content of the invoice in order to ensure the invoice
can be regularised and serialised in such a way as to make it
transmissible to the device.
One of these checks was ensuring that only one tax can be applied per
line. This check was implemented as the device itself only accepts one
tax per line.
This check isn't entirely accurate, since the user should be able to add
taxes such as levies, service charges etc (non-vat taxes) to the the
line, and have them skipped when transmitting the invoice data to the
device.
As such, this commit adapts the code to alter the checks (allowing for
only one 'VAT' tax, and any number of other taxes). The way the price
total is determined is altered to use only the "VAT" tax and base amount
to get the price_total for the line from the corresponding line's tax
details.
This commit also adds a test.
closesodoo/odoo#148397
Task-id: None
X-original-commit: bb3a32c7f45ac5adb3dddf560f6af33f9bca3780
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Daniel Kosky (dako) <dako@odoo.com>
Steps to reproduce:
1- Install Sales module
2- Activate Lock Confirmed Sales from Sales settings
3- Create a new order as a Public user and make the payment
4- Check the state of this order in backend
Current behavior before PR:
Upon creating and confirming an order as a public user the order does not get locked even if the 'Lock Confirmed Sales' setting is turned on. This is happening because when checking if the 'Lock Confirmed Sales' group is on or not we check if it is there for the current user which if he is a public user by default will not have this group.
Desired behavior after PR is merged:
Before we had this condition checking if self.env.user has the 'Lock Confirmed Sales' but this won't work if the SO is coming from eCommerce with public user env So now we are checking the creator of the SO that in the eCommerce scenario will be OdooBot and if the SO is created from the backend it will be one of the users who already has the group.
opw-3595964
closesodoo/odoo#148363
X-original-commit: 4cfd125837858f70d63d14f41265b9b9f47a933b
Signed-off-by: Youssef Bashandy (yoba) <yoba@odoo.com>
Issue Description:
==================
The system currently resets the expected duration in the Work Order tab of a Manufacturing Order (MO) to the default Bill of Materials (BOM) value after 'Produce All' is used. This occurs despite any manual duration adjustments. This issue can be traced back to the dependencies of the compute method involved in this process. Specifically:
1. The `qty_production` field in `mrp_workorder.py` is a related field (see [here](https://github.com/odoo/odoo/blob/2e5da1130f4a7056f746a4cce6ba75bf699dbe62/addons/mrp/models/mrp_workorder.py#L44)).
2. When marking the MO as done, we write on this related field (refer to [this code](https://github.com/odoo/odoo/blob/780dded71cc725d75a0739e6c7bf4ceab5850581/addons/mrp/models/mrp_production.py#L1886)).
3. This action triggers a call to the compute method (defined [here](https://github.com/odoo/odoo/blob/2e5da1130f4a7056f746a4cce6ba75bf699dbe62/addons/mrp/models/mrp_workorder.py#L324)), leading to the unexpected change in the expected duration value.
Steps to Reproduce:
===================
1. Create a Manufacturing Order (MO) with a product that has a BOM.
2. In the Work Order tab of the MO, input a custom expected duration different from the BOM's default duration.
3. Сomplete all product validation steps.
3. Click 'Produce All' on the MO.
4. Observe the reset of the expected duration to the default BOM value in the Work Order tab.
Proposed Solution:
==================
Implement a change to prevent the re-calculation of `duration_expected` in the Work Order tab once the work order's state is set to 'done' or 'cancel', ensuring that any custom duration set prior to executing 'Produce All' is maintained.
opw-3608185
closesodoo/odoo#148269
X-original-commit: 00876107734c2d5bcf3f057ead55e345493bb6e2
Signed-off-by: Adrien Widart (awt) <awt@odoo.com>
Signed-off-by: Ilya Rudy (ilru) <ilru@odoo.com>
After #38518, there are cases in which people uninstall l10n_it_edi so the following traceback is given when importing a PDF invoice (OCR):
```
File "/home/odoo/src/enterprise/saas-16.4/l10n_it_reports/models/account_move.py", line 9, in <lambda>
lambda rec: self.env['account.edi.format']._check_filename_is_fattura_pa(rec.name)
AttributeError: 'account.edi.format' object has no attribute '_check_filename_is_fattura_pa'
```
We move everything back to l10n_it_edi, but the test will be excised.
Enterprise PR: odoo/enterprise#53452closesodoo/odoo#147676
X-original-commit: 0f897c6dd9f89c1e262dd6420829c0466dae398b
Signed-off-by: Josse Colpaert <jco@odoo.com>
Version:
--------
- 16.0+
Steps to reproduce:
-------------------
1. Go to Timesheets / Configuration / Settings;
2. set encoding method to Days / Half-Days;
3. go to sales and create a sales order;
4. sell a service that will create project on sale;
5. confirm and go to the generated project's settings.
Issue:
------
The Allocated Days displayed is one eight of what's expected.
Cause:
------
On project creation, it was using `timesheet_encode_uom_id` to calculate
`allocated_hours`. Hence, if timesheets are being encoded in days, it
also tries to encode the project's `allocated_hours` as days, dividing
the quantity by eight.
Solution:
---------
It should use `project_time_mode_id` as UoM instead,
which is hardcoded to hours.
opw-3614995
closesodoo/odoo#148313
X-original-commit: 6817bb76b9f2cdb3a73489280efa7f73e7c8dacd
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Signed-off-by: Levi Siuzdak <sile@odoo.com>
Issue:
======
The auto signature has hidden overflow part in y axis when having long
characters in bottom like (y, j, g)
Steps to reproduce the issue:
=============================
- Use any sign template that have at least one name_and_signature sign
item.
- Enter a name that have at least one of the characters (y,j,g)
- Click on auto
- The signature doesn't show fully
Solution:
=========
Update the hardcoded values for the y-axis for the name and the line of
signature and the font size to make sure it fits perfectly inside the
canvas.
opw-3639171
closesodoo/odoo#148299
X-original-commit: c9653d5649a35640cc461c9baa0b73e8c6c1cace
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit, the link preview in the Link Dialog would not be
updated after changes on the label input field, depending on other
actions to be updated (e.g. picking a different type of link/button or
changing the URL input field).
This commit makes sure the link preview reacts to changes on the label
input field.
task-3580621
closesodoo/odoo#148202
X-original-commit: c7954225e8680821a46c9628e5e05df2ae575da7
Signed-off-by: Nicolas Bayet (nby) <nby@odoo.com>
Signed-off-by: Rodolpho Cammarosano de Lima (rcdl) <rcdl@odoo.com>
*: website
When the user uploads an image and remove the original image, some
image options continue to work thanks to a backend fallback on another
image. Unfortunately, this fallback is not available for images coming
from unsplash. This commit fixes this issue by preventing the UI to be
blocked when the original image is not found.
Steps to reproduce the bug:
- Activate the developer mode
- Configure Unsplash in the settings
- Add a Cover block on a page
- Replace the background image with an unsplash image
- Save
- Edit the page and via the media dialog, remove the original image
=> The options on the image cannot start anymore.
opw-3636499
opw-3474103
closesodoo/odoo#148197
X-original-commit: 3b0ac160a800f70ae965b60110e83e41655bca5f
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Guillaume Dieleman (gdi) <gdi@odoo.com>
Before this commit, the pager hook use useChildSubEnv to patch the
config with the pagerProps. We used useChlidSubEnv because this
information only targets one of its children (the ControlPanel),
not the components using the hook themselves (e.g. the controllers).
However, this has an infortunate side-effect. If a component using
the pager hook also wants to patch the env (e.g. with useSubEnv),
and does it after calling usePager, it will erase the sub env
created by the pager hook for the children by its own.
This happens with the TimesheetTimerListView:
```js
setup() {
super.setup(); // super will call usePager
useSubEnv({
config: {
// this config doesn't contain the pagerProps
// generated by usePager, as it's the config of
// the component itself
...this.env.config,
disableSearchBarAutofocus: true,
},
});
}
```
Since using useChildSubEnv in this case isn't necessary, we simply
replace it by useSubEnv.
Note that we don't add a framework test for this issue, as it
would be totally artificial. Instead, the enterprise PR adds a
test for the TimesheetTimerListView.
opw 3636182
closesodoo/odoo#147393
X-original-commit: 8dbf8021842b94b9b067e2582f3aa92d31ef62e5
Related: odoo/enterprise#53342
Signed-off-by: Francois Georis (fge) <fge@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
When we copy a sales order we were taking margins from the past which
have a high probability of not being valid anymore.
Now, once we copy a sales order, no past value is copied and the
purchase price is computed as new so we get the current margin values.
TT46721
closesodoo/odoo#148244
X-original-commit: 6da8aec93f1e66feaea16b12e245a229001cec21
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Steps to reproduce:
1) Install and enable the "Onsite" payment provider;
2) As a public user, add product(s) to your cart;
3) Try to pay with the "Onsite" provider.
-> Internal Server Error
Cause of the issue:
In the log, the cause of the issue is an AccessError,
specifying that we tried to read the field `transaction_ids`
on a `sale.order` without having the necessary access rights.
This shouldn't happen, since the payment & ecommerce flows
are executed in sudo mode, after making sure that the cart
belongs to the customer.
After investigation, pending payment transactions trigger
1) the sending of a mail to the customer
2) the first mail generation will request the report assets
3) the generation of the report assets will create an
attachment and commit the transaction
4) committing the transaction will trigger a global
flush of the environment, forcing the computation
of pending mail wizard fields, with a different
environment than the sudoed one initiating the sending
of the mail.
This will lead to security errors as we try to access
`sale.order` fields content without having the rights
for it.
Standard fields being already in the cache, it will
be noticed when trying to read the `transaction_ids`
field.
Solution:
Manually prefetch the `transaction_ids` content with
the sudoed environment, since the records cache is
shared between the environments (until a more global
fix is found and deployed).
Introduced by #121376
opw-3628753
closesodoo/odoo#148199
X-original-commit: 511fe642b9860bd9d2f6b7ed728e7d3e6af48748
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
When using safe_eval on this dict, "true" raises a NameError while "True"
is interpreted properly.
At the same time, this is more consistent with the rest of the code.
closesodoo/odoo#148203
X-original-commit: 0e91bf8b3956c1403e638421a91af3275b9e6489
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
When replenishing a product with a route buy selected on the product form but no vendor
added, we fall into an endless loop because the default_get sets the route,
which triggers the onchange that return a warning.
This will again call the default_get and the loop never ends.
The onchange is useless as it's only goal is to display the warning, and as the field is
required on the form, the user will not be able to submit it.
opw-3653714
closesodoo/odoo#148201
X-original-commit: e7fca1c849652920388526f4797397aa18247204
Signed-off-by: Tiffany Chang (tic) <tic@odoo.com>
Before this commit:
When inserting a star rating element, pressing 'Enter' would move the cursor
to the next line, and hitting 'Backspace' would delete the star rating element.
After this commit:
After inserting a star rating element and moving to the next line with 'Enter,'
pressing 'Backspace' now causes the cursor to move to the previous <p> tag
where star element is located. If 'Backspace' is pressed again, the star
element is deleted.
task-3555394
closesodoo/odoo#148198
X-original-commit: 64a1b38450e15162f89d370fbe30abda9e5f7fe7
Signed-off-by: Geelen Sébastien (sge) <sge@odoo.com>
Signed-off-by: Antoine Guenet (age) <age@odoo.com>
Purpose
=======
When an email is opened and is from the default notification mechanism,
i.e: coming from something like "notifications@mail.odoo.com", we don't
want to try to match the email address to an existing contact partner.
Instead, we now display a custom message on the mail addon side
mentioning to search the contact manually.
Task-3557545
closesodoo/odoo#148073
X-original-commit: 9ff0815e258160f0eca595e0c3cce4b005e79eea
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
This fix is to solve a bug that appears in the demo data od the l10n_be specifically in the cash journal using an income tyoe account for the negative cash difference which should be en expense type.
opw-3642586
closesodoo/odoo#146936
Signed-off-by: de Wouters de Bouchout Jean-Benoît (jbw) <jbw@odoo.com>
Incorporate German Loredo (xmglord) as Vauxoo's contributor.
I confirm I have signed the CLA and read the PR guidelines at http://www.odoo.com/submit-prclosesodoo/odoo#148245
X-original-commit: c3f1be0d418b06d9dff97e44538a53f52d8ae496
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Since the commit odoo/odoo@0d99f4b9d9, the header buttons with display="always"
can't be invisible. The invisible attribute is ignored for this type of
button in list view and kanban view.
This commit fixes this issue by adding t-if that will evaluate the invisible attribute.
closesodoo/odoo#148092
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
This commit simply replaces the shortcut for the action_done_schedule_next
buttons from alt+q to alt+z in the activity view dialog because the
alt+q shortcut is already used for the Save/Schedule buttons. This was
already done in https://github.com/odoo/odoo/pull/145738 but the wizard
which appeared in 17.0 hadn't been corrected.
opw-3565747
closesodoo/odoo#148160
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Adds a new COA for large businesses in China to better support their needs out of the box. Also implements new taxes for the same large businesses.
3202831
closesodoo/odoo#145879
Signed-off-by: Nicolas Viseur (vin) <vin@odoo.com>
Create a branch under the main company
Select an internal user and keep only this branch on the fields
"Allowed companies" and "Default Company"
Access with the user
Create an invoice
Add a product
Issue: user will be blocked by error
"""
Access Error
Due to security restrictions, you are not allowed to access 'Companies' (res.company) records.
Records: YourCompany (id=1)
User: Marc Demo (id=6)
This restriction is due to the following rules:
- company rule employee
Note: this might be a multi-company issue.
Contact your administrator to request access if necessary.
"""
This occurs because the accounting info is taken from the parent company,
but the branch user has no access to the parent company records
opw-3627439
closesodoo/odoo#148028
X-original-commit: fab2dc3ded2b638c8160bbc84ec14669c4e8546c
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Andrea Grazioso (agr) <agr@odoo.com>
*: project, survey, test_website, website_event, website_sale
This commit fixes all found occurrences of such a case:
```
<t t-set="classes">some_classes</t>
```
=> CSS classes being marked for translation by mistake.
A breaking case was found via task-3636009, where the arabic language
has a translated class on some element which makes some JS crash
because of it.
Steps to reproduce (only for 17.0):
- Create a website with the "Arabic" language as the default language
- Go to the shop page in Arabic
- If you are in grid view, click on the "switch to list view" button and
if you are in list view, click on the "switch to grid view" button
=> Crash
Note that commit [1] already did something similar a while ago (but
more generically than this commit). In this commit here, broken
occurrences were found using this regex:
```
<t\s+t-set=["']\w+lass(es)?["']\s*>
```
[1]: https://github.com/odoo/odoo/commit/98678199a32b3ba9af999f76980a6110546ec0fc
task-3636009
closesodoo/odoo#147688
X-original-commit: 01b223e3043a3d847fd7dbf8997edcee62c3254a
Related: odoo/enterprise#53463
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Before the refactoring introduced at 0a744ac, it was possible to return
a warning from a `code`-type base automation with the `action` variable:
```py
if len(record.name) > 20:
action = {
"warning": {
"title": "Name too long",
"message": "The name of the record is too long",
}
}
```
This would trigger a visual dialog with the title and message in the
client.
Due to a louche `+=` operator change in the refacto, this kind of
automation raises a key error on the server, as the additive part of
the operator will try to access the 'warning' key in the result dict,
which may not (and usually will not) exist.
I assume this was done in an attempt to 'accumulate' warnings, but the
warnings in questions are dict that are not really additive anyway.
Better to support the *last* returned warning rather than none at all.
This commit basically returns to the previous situation for onchange
warnings.
closesodoo/odoo#148140
Signed-off-by: Bouvy Damien (dbo) <dbo@odoo.com>
Description:
Saving a new `res.config.settings` (for ex: checking "Use QR code on
ticket") can be extremely slow on database with a large number
of `pos.order`.
Analysis:
Saving a new `res.config.settings` creates a new instance of the config.
This will invoke a check on the python constraints calling
eventually `_check_currencies` of `pos.config`, which will invoke the
compute of `currency_id` setting the field as dirty.
The `_compute_currency_rate` of `pos.order` depends on the `currency_id`
of the current `pos.config` (via a related).
This means the compute will be called with *all* `pos.order` ever made.
As the compute itself makes a few calls to `_get_conversion_rate`, which
makes a query, it can become slow when the method is called frequently.
Solution:
Memoize the call to `_get_conversion_rate`, as similarly done
in `account.move.line` from d8d47f9ff8
to reduce the number queries necessary.
Benchmark:
The `create` request to `res.config.settings` on a database with over
240k `pos.order` took
| | Before | After |
|-------------|-----------|----------|
| Timing | 36.9 secs | 4.3 secs |
| Query count | 47k | 627 |
Reference:
opw-3632273
closesodoo/odoo#148136
X-original-commit: 1c6f7f23b2c0dbd009d8d56689c7a98792990f7f
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Signed-off-by: Piryns Victor (pivi) <pivi@odoo.com>
Although it is not a common case, it could happen that some loops are
created in reconciliation.
This test is added to make sure all implementations still work in that
case. It was added after an optimization on the code was attempted to
use `UNION ALL` instead of `UNION` in `_update_matching_number`
closesodoo/odoo#148093
Signed-off-by: Laurent Smet (las) <las@odoo.com>
up default Working Hour for a company
Setps:
1. `Standard 38 hours/week` data doesn't have a company
2. Employees menu > Configuration > Settings
3. cannot select `Standard 38 hours/week` to set
closesodoo/odoo#147995
X-original-commit: 352843ff8a8d204007f021153765d093aeb11fb5
Signed-off-by: Bertrand Dossogne (bedo) <bedo@odoo.com>
Issue
Admin unable to change related user on employee profile due to
restricted access to bank account.
Steps to reproduce
1- In the Employee app, go to the HR settings tab of an employee.
2- Remove the related user from this profile.
3- Set that removed user as the related user on a different employee
profile and save (expect no error).
4- Attempt to revert back to the original user.
5- Encounter an access error.
resolution
- Added sudo() in the browse operation to prevent access errors.
opw-3578412
closesodoo/odoo#147993
X-original-commit: 2b27b740ec3cff2fc088f4d01d7347668f6eb441
Signed-off-by: Sofie Gvaladze (sgv) <sgv@odoo.com>
Signed-off-by: Kawtar Drissi El Bouzaidi (kdeb) <kdeb@odoo.com>
Originally, restricted editors don't have the rights to edit the SEO of
a record.
It was probably a bad idea as they can already edit the record itself
and can change the name / description of the record in the page.
Changing the SEO seems to be very similar.
Also, for our internal needs, we need our HR people (which are
restricted editor with rights on jobs position) to be able to edit the
SEO of their jobs. And we don't want to grant them the full editor
right.
Note:
- We already have a `data-can-optimize-seo` attribute set on the HTML
tag if one is logged in, but this is just about knowing if the record
has SEO-mixin capability, it does not check the rights for a given
record.
- In master, one day, we would like to have the "Edit" button shown only
when something can be edited for restricted editor (to not be able to
enter edit mode to then not be able to edit anything). The same would
be nice here: optimize seo menu could only be shown if you have the
right, but we don't want to do an extra RPC each time for now.
- We keep the info shown in readonly mode so the restricted user can see
it and ask for a change to someone else if needed
Related commits:
- https://github.com/odoo/odoo/commit/94e2eefca28196efc0ac38f155a3b85acbbdeaae
- https://github.com/odoo/odoo/commit/21464edf7ce858c065e113e32d857dfa4ace1788closesodoo/odoo#147981
Signed-off-by: Jérémy Kersten <jke@odoo.com>
When a message had more than 1 attachment, it was not possible
to preview the attachment on a mobile device.
This happens because the hover buttons for delete/download the
file took the whole clickable area of attachment to see the preview.
To enable quick actions in mobile, this require non-trivial UI
tweaking. To match behaviour of version 16.0, these quick-actions
have been disabled in mobile.
opw-3664795
closesodoo/odoo#148091
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
To reproduce:
- Create a product with 1 on hand quant;
- Enable 3 steps delivery;
- Create a SO with product and 1 quant the SO;
- The forecast widget shows that there is qty available in stock;
- Create 2nd SO with product and 1 quant;
- Unreserve the 1st SO pick and reserve pick of 2nd SO.
Current Behavior:
Forecast widget on 2nd SO says no stock available despite being reserved
and shows available stock for 1st SO.
Expected Behavior:
Forecast widget on 2nd SO says available stock and no stock for the 1st
SO. Basically the reserved SO should have qty in stock on the widget.
opw-3590385
closesodoo/odoo#148019
X-original-commit: 012c8ee44c059c578d11ca6ff79b767f233a01e1
Signed-off-by: Steve Van Essche <svs@odoo.com>
When you install point_of_sale and then pos_restaurant, you end up with
a pos_config with an archived journal.
Then, if you change the chart of account via demo data, it doesn't
delete the archived log and crashes.
To correct this problem, we add `with_context(active_test=False)` to
the pos.config search.
closesodoo/odoo#147889
Signed-off-by: Pierre Masereel (pim) <pim@odoo.com>
Issue:
======
the display of kiosk mode in phone is broken
Steps to reproduce the issue:
=============================
- Install hr_attendance
- Activate Employee Pin Identification in the settings
- Change to phone view
- Go to attendances/kiosk mode
- Identify Manually
- You can't search for employee , scroll employees and see the name of
the employees.
- Click on any employee, the button back isn't fully shown and clicking
on it does nothing.
Solution:
=========
Display:
- Added some css for `md` size devices.
Back button:
- There click function was missing.
opw-3645708
closesodoo/odoo#147830
Signed-off-by: Sofie Gvaladze (sgv) <sgv@odoo.com>
How to reproduce:
- Login as a portal user, create a new post by adding a URL link
- Post Your Question
- Login as admin to validate the post
- Click on 'To Validate' from the moderation tool
- Click on the mentioned URL
Throws a Traceback and redirects to the about:blank#blocked
page.
Technical Reason:
The '_update_content' method performs a regular expression
on the link by using the escape method, which is later convert
the backslash '\' into '%5C' while html_sanitize.
After this commit:
Clicking on the mentioned link redirects to the correct URL
Task-3472776
closesodoo/odoo#148064
X-original-commit: dedfb9a42e7bade98756e73a3d6c54c581e99547
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Description of the issue/feature this PR addresses:
The webhook URLs used by MercadoPago are not sanitized and cause the payment to fail when the URL contains spaces or other non-ASCII characters.
Steps to reproduce the bug:
1. Instal the Argentine localization and configure "payment_mercado_pago" as the payment method (test or production).
2. Create an invoice and generate a payment link (the reference will be something like "FA-C 0001-000133444").
3. Initiate the payment process and it will generate an error in the last stage of payment (on the MercadoPago website).
- Mercadopago tests credentials TEST-4811719641145832-020115-c5caffc149634e3e9d72fde2b74544d8__LD_LA__-172837665
- Used payment methods: https://www.mercadopago.com.ar/developers/es/docs/checkout-api/additional-content/your-integrations/test/cards
- Credencial de test usada TEST-4811719641145832-020115-c5caffc149634e3e9d72fde2b74544d8__LD_LA__-172837665
- Metodo de pago usados: https://www.mercadopago.com.ar/developers/es/docs/checkout-api/additional-content/your-integrations/test/cards
Current behavior before PR:
Payment in MercadoPago cannot be confirmed when the reference contains spaces.
Desired behavior after PR is merged:
Payment in MercadoPago is confirmed even when the reference contains spaces.
Adhoc Ticket: 68591
closesodoo/odoo#148027
X-original-commit: 320b316df0a2c7df183f80db4a561ff5d1517e70
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
The "grid images" are grid items that only contain an image (i.e. the
image is alone in its column). This distinction with other images in
grid mode allows to set the `object-fit` CSS property to `cover` so they
take the whole space of the grid item (see commits [1] and [2]). In
commit [3], the "Position" option has been added, allowing to switch
between the `cover` and `contain` values for this property, to have the
possibility to still choose to display the entire image, so it can keep
its ratio.
However, only the images that are direct children of the column have
been considered when checking if it was a grid image and in the related
CSS rules. This means that an image with a link cannot be one, since
the image is the child of an anchor element `<a>` in that case. It can
therefore not be set as "cover" or have the "Position" option.
This commit adds the support for images with a link set on them, so they
can be considered as grid images too.
Steps to reproduce:
- Drop the "Masonry" snippet.
- Click on the image and set a link on it.
=> The image is now "contain" and the "Position" option disappeared from
the right panel so we cannot change it.
[1]: https://github.com/odoo/odoo/commit/e9c7e020daf88022d6e02de0a5620074e8417b5a
[2]: https://github.com/odoo/odoo/commit/d8c374e3e6b31bf88aa42952aadf3379936f7600
[3]: https://github.com/odoo/odoo/commit/faf19ef7f87fc043fb9a814516e01b8eeafd9b61
opw-3580128
closesodoo/odoo#148022
X-original-commit: 085d70cea571ea80c141ac6005e8bd8333bd269f
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Soukéina Bojabza (sobo) <sobo@odoo.com>
Right now, when a turnstile error occurs, the user is displayed a
CORS error, which is incorrect. This commit fixes that by displaying a
more accurate error message.
The fix requires the addition of a small trick which is to use the
turnstile error handler system to catch and rethrow the error. It seems
useless, but it is actually required as errors thrown by files coming
from external domains will be set by the browser as "Script error" and
stripped of any further info. So for better error handling, these few
lines are worth it.
The error is most likely to happen when duplicating a database as
turnstile requires a specific domain name in its cloudflare settings.
This improved message will hopefully help support manage better this
situation.
Hopefully, we can make something in the DB duplication tool to avoid
the issue entirely and have this error message displayed only for "real"
but rare errors.
closesodoo/odoo#148016
X-original-commit: 112508dbc57bfbc3e8145bf4c8ed260e17071a91
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Simon Genin (ges@odoo) <ges@odoo.com>
Steps to reproduce
==================
Make sure your resolution is around '1368 x 768'.
1. Open/create an opportunity and assign a partner (Joel wills).
2. Go to Joel's portal view.
3. Click on the Opportunity and go to the priority.
The priority's alignment is distorted.
After this commit
=================
Align priority correctly on the portal view of opportunities.
Task-3607070
closesodoo/odoo#147983
X-original-commit: dfff592bea9cd393913b703e512dc56b83928849
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Before:
In chrome, you can see the message "[DOM] Input elements should have
autocomplete attributes (suggested: "username"):
(More info: https://goo.gl/9p2vKq)".
After:
The message does not appear.
Also, This maintains consistency with the password input which has the
attribute autocomplete.
closesodoo/odoo#147971
X-original-commit: df53b6a842f6eecc699ea9d8625c918279bb22c6
Signed-off-by: Francois Georis (fge) <fge@odoo.com>
Before this PR:
Previously, when the command palette was opened and a navigation command
("/") was being executed with single or multiple dialog boxes behind it,
only the command palette would close. This left the dialog boxes open.
After this PR:
Now, when a navigation command ("/") is being executed from the command palette,
all the dialog boxes and the command palette close simultaneously.
Task-3441132
closesodoo/odoo#147956
X-original-commit: 7b32b235ec488d347285a9f47aa9d4b04b0b186c
Signed-off-by: Francois Georis (fge) <fge@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Nicolas Viseur (vin)