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>
Since [this other commit], the recipient email option of the form on the
`/contactus` page is not filled correctly with the company email.
By chance, the form signature task fixed the bug but introduced another
one. The previous commit fixed the bug introduced by the form signature
task but reintroduced the inital bug. This commit fixes the initial bug
and adds a test.
By default, the form on the `/contactus` page sends emails to the email
address of the company. Unfortunately, before this commit, when a user
entered edit mode, the Recipient E-mail option always displayed
"info@yourcompany.example.com" even when the company's e-mail address
was different. This commit corrects this by displaying the dynamic value
of `company.email` in the Recipient E-mail option coming from the
data-for.
Steps to reproduce the issue fixed by this commit:
- Go to Settings > General Settings
- Update the company's email address
- Go to /contactus and edit
- Click on the form
=> The recipient email value is still "info@yourcompany.example.com"
instead of the company's email address.
This commit fixes the issue, adds a test to ensure the recipient email
option is correct and adds a utility to parse the data-for data.
Bonus: this commit also fixes the following issue catched by sentry:
- Go to /contactus
- Click on Edit
- In the Form option, remove the content of the 'Recipient Email' field.
- Save
- Fill and submit the form
=> An error is generated in the log.
[this other commit]: https://github.com/odoo/odoo/commit/043e1fdf923d2037dd8da128ab99388f0c92e544
task-3382195
sentry-4633940473
closesodoo/odoo#147933
X-original-commit: 56f6b8dccec5cebc9a93454538b39886d4d3f63c
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Guillaume Dieleman (gdi) <gdi@odoo.com>
The email_to field of the contactus form have to be dynamic except if
the user manually set it via the form options. Unfortunately, the
website signature task broke this feature. This commit fixes it and adds
a test to prevent this regression in the future.
Steps to reproduce the bug:
- Go to the contactus page
- Edit the page
- Add a field on the form
- Save the page
- Change the company email address via the settings
=> The contactus form still send the email to the old email address.
Related to task-3382195
X-original-commit: 10b4db60fbd077936b5c9586485fa40c3c890d3f
Part-of: odoo/odoo#147933
In #126914 a limit on the request size has been enforced, that limit is
by default 128MiB and can be configured via an ir.config_parameter. When
restoring a backup larger than 128MiB via the database manager, the
default limit was used and the request was cancelled with a Request
Entity Too Large (code 413) HTTP error.
It is now possible to define a default max content length per route,
that per-route limit takes over the `web.max_file_upload_size` ICP.
Moved the code from `get_http_params` to `pre_dispatch` to better align
with the httpocalypse new http stack.
Fixes: #144144
opw-3643475
closesodoo/odoo#147506
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
Issue:
- In mobile when we have multiple tickets, the quantity of
selected tickets is not visible
Steps to reproduce the issue:
- Go to events
- Select any event with multiple tickets
- Go to website
- Click on register now
- Notice in mobile the quantity of selected tickets is not visible
Solution:
- Add style to the quantity of selected tickets
this it was introduced by: 469d94a
opw-3602057
closesodoo/odoo#146904
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Problem
---------
Before, the default tax for sale and purchase was: GST 5%. Commit
084408a9bb, modfied by accident the
default tax to IGST 18%.
Objective
---------
Revert the deault taxes back to GST 5%.
Solution
---------
Update the default taxes in the l10n_in template file.
task-3634577
closesodoo/odoo#146809
Signed-off-by: Josse Colpaert <jco@odoo.com>
How to reproduce:
- Create an SMS and send it
- go to the sent option and select a contact
- Click on add to list
- Select a mailing list
- then click on add and sent mailing (you will be redirected to email marketing)
- Select a template and send it
- The recipient will not be able to see the template (The email is blank)
Issue:
Template value is not stored in the body_html field
Technical reason:
When the record is saved the changes in `body_html` are discarded from _getchanges() https://github.com/odoo/odoo/blob/c2b160fe50c24e9f01d0d5b350f2422cfdbc72d4/addons/web/static/src/model/relational_model/record.js#L574-L581
because, field is set to readonly = 'true' after this commit https://github.com/odoo/odoo/pull/132247
After this commit:
The recipient will be able to see the template
Task-3556020
closesodoo/odoo#143293
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Before this commit, _get_calendar_attendances was calling
the calendar method get_work_duration_data without specifying
the company in the domain, ending up in wrong data if global
leaves that don't concern the employee are concerning the calendar.
This commit adds a domain for that method call so that only
relevent global leaves are taken into account.
closesodoo/odoo#148043
Minor fix: the background grid is not observed in the first place,
setting a z-index on it should not be observed either.
Noticed when fixing `automaticStep(Un)active()` at [1].
[1]: https://github.com/odoo/odoo/commit/c2d952689c97add74a372c90aa18787094d5d93a
Related to task-3576046
closesodoo/odoo#147970
X-original-commit: 901ed6d8c6c6bdb8aff8e9366d63bba59051019a
Signed-off-by: Guillaume Dieleman (gdi) <gdi@odoo.com>
Steps:
- Open Field Service
- Create a new task
- At first, the product stat button shows the price as 0.00
- Add task name and customer
- Save the task.
- Check product stat button
Issue:
- Now, after saving the task, the product stat button will not have the price
shown as it was displayed before.
Cause:
- The class o_field_empty is applied which has the property of display: none
and hence the price field is not displayed.
Fix:
- The o_field_empty class is applied at the wrong place, we need to apply the
o_field_empty only when o_stat_text is applied.
closesodoo/odoo#147926
Task: 3394985
X-original-commit: 9ea49b1e0be064ef4dd7dafe05aff4bd742ac135
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Steps:
- Open Field Service
- Switch to the calendar view
- Click on any task
- Notice the space in the row of the worksheet template
Issue:
- There is a weird space between the title Worksheet Template and the template
name
Cause:
- Due to the long name of Worksheet Template, it moves to the next line but
occupies a certain amount of space around it
Fix:
- By giving flex-wrap, the content is displayed properly
Task: 3394985
Explanation:
When the label 'Worksheet Template' is long and moves to the next line without
flex-wrap, it may cause unwanted spacing issues. By using `flex-wrap: wrap`,
you essentially enable the content to flow onto a new line if it exceeds the
available width, ensuring a more visually appealing and properly aligned
display without unnecessary space around the label. It allows for a more
flexible layout, accommodating varying content lengths without compromising
the overall presentation.
closesodoo/odoo#147925
X-original-commit: 9be92729eaa4bc3b3cfe9778cb2b1fcc47a8cc59
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
Current behaviour:
When changing the text color in the document layout
of the company to one of the first row colors,
the text stays black in the preview of the document.
Steps to reproduce:
1. Go to Settings
2. Click on Configure Document Layout
3. In Company Details, highlight the text
4. Change the font color to any of the first row
5. (By example the color #35979c)
6. The text color in the preview is still black
7. (Same when exporting to PDF)
Cause of the issue:
The css code for colors in top row (o-color-1 to 6)
is generated in web_editor (.text-o-color-1 to 6)
and was not in the report_assets_common bundle
See https://github.com/odoo/odoo/blob/01b42c7d76c814e13325f8880dc9de765b0f43c8/addons/web_editor/static/src/scss/web_editor.common.scss#L662
opw-3360456
closesodoo/odoo#147645
X-original-commit: 0b914f3d0dc209ca87837feb15e6ec3f063be534
Signed-off-by: Antoine Demany (ande) <ande@odoo.com>
Issue:
- For GCC localization, the receipt lacked VAT details per line and
had mixed-up numbers at the bottom, and contained wrong translations.
Steps to reproduce:
- Activate the Saudi localization (l10n_sa_pos).
- Open the Point of Sale app.
- Create a new order and print the receipt.
- Notice the missing VAT per line, the mixed numbers for large amounts
at the bottom and the wrong translation.
Solution:
- patched the Orderline.prototype to display precise tax amounts with
two decimal places.
- updated the view to show tax details per line for gcc localization.
- added correct Arabic translations, and removed incorrect ones.
- See attachment for more details.
OPW-3652633
closesodoo/odoo#147859
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
To reproduce:
1. Sync the IoT with a 17 database
2. Once it is set up, force shut down the server by Ctrl+C 2 times
3. Wait a few seconds:
=> crash of `WebsocketClient` thread with the following traceback:
```
Traceback (most recent call last):
File "/usr/lib/python3.11/threading.py", line 1038, in _bootstrap_i>
self.run()
File "/home/pi/odoo/addons/hw_drivers/websocket_client.py", line 83>
self.ws.run_forever()
File "/usr/local/lib/python3.11/dist-packages/websocket/_app.py", l>
raise WebSocketException("socket is already opened")
websocket._exceptions
WebSocketException
socket is already opened
```
The IoT synchronised servers can stop in 2 ways that we need to handle:
A. Gracefully (Ctrl+C):
In this case a disconnection signal is sent to the IoT-box
The websocket is properly closed, but it needs to be established a new connection when
the server will be back.
Solution: `while True` loop as `run_forever` will return on close.
`time.sleep` for the reconnection delay
B. Forced/killed (Ctrl+C 2 times):
In this case there is no disconnection signal received
Solution: use `reconnect` that will automatically take care re-attempting a connection
This will also happen with the graceful quit as `reconnect` will trigger if the server
is offline while attempting the new connection
In both case, we perform a reconnection attempt with a delay of 10 seconds to avoid
spamming the database
After this commit:
The websocket will reconnect itself automatically after 10 seconds
if the connection is disrupted
opw-3612528
closesodoo/odoo#147858
Signed-off-by: Yaroslav Soroko (yaso) <yaso@odoo.com>
Steps to reproduce
==================
Go to Maintenance > Studio > Website > New Form
Click on the website editor
Click on the name field
UncaughtPromiseError > KeyNotFoundError
Cause of the issue
==================
Starting from 17, the FormEditorRegistry is not the legacy one.
If the key is not present in the registry, it will fail, unless we pass
a default value.
In this case, the key `website_form_key` is false.
Solution
========
Pass null as the default value.
opw-3652423
closesodoo/odoo#147840
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Following quantitypocalypse (odoo/odoo#137864), a couple of
`reserved_uom_qty` and `reserved_qty` references were left over. This
was partially due to no tests for these tricky parts of the code,
therefore we both fix these references to use the newer
`quantity`/`quantity_product_uom` fields and add/update tests to ensure
we avoid breaking these 2 use cases again.
Also discovered during this fix, the remaining assigned qtys when
unassigning done incoming moves from already reserved outgoing moves
(i.e. the "1. batch reserved + individual picking unreserved" use case
in the code comments) was NOT being calculated correctly. This also
fixes that + adds a test for it.
closesodoo/odoo#147815
Related: odoo/enterprise#53536
Signed-off-by: Steve Van Essche <svs@odoo.com>
Since odoo/odoo#140898 the pickings detailed operation view has been
moved to a smart button instead of showing in a picking tab. This
included the removal of the `force_detailed_view` context since there
was no longer a detailed view to force show. This commit removes some
leftover references to this context within tests.
Part-of: odoo/odoo#147815
asm