When a message is posted, sometimes the label tells the message
is edited when it definitely shouldn't.
This happens because implementation of detecting whether a message
is edited relies on difference between `create_date` and
`write_date`. This implementation is flawed, especially when the
message being newly posted has its fields being updated in another
ransaction, which is unfortunately what happens when the message
should be sent by email.
No good solution to preserve this label in a working state was
found, so the showing of this label is being disabled.
Messages can still be edited: only the label is no longer shown
after this commit. This makes feature of message edition matches how
it was in prior versions of Odoo, where the label was also missing.
closesodoo/odoo#128656
X-original-commit: f5d108eff2276ba577a52d9d10a82f9ea769c701
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Commit [1] inadvertently broke the handling of the "class"
attribute on a <widget> node, in the view compilers. When set,
the value of the "class" attribute was given in props to the
Widget component as "name", instead of "className".
[1] https://github.com/odoo/odoo/commit/0b574df2599da3dae66b9785198420d707a280a3closesodoo/odoo#128646
X-original-commit: 3024f2121848ec414d596ef9c3eb0a1bd7e6cfd2
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Protect left/right arrow key handling against an empty selection (no
previous/next character to find without a selection).
Example of steps to reproduce the issue (= lose the selection while keeping the
focus):
- create such a configuration in the editable:
```html
<p [p1]><br></p>
<table>...</table>
<p [p2]><br></p>
```
- Place the cursor inside [p2] and delete the node with `CTRL + BACKSPACE`
- The cursor should have moved in the last cell of the table
- Place the cursor inside [p1]
- Start the table deletion process with `CTRL + DELETE`
- The table should be selected, as well as [p1]
- Type `DELETE` (this time without CTRL) a second time.
- The table and the paragraph are replaced by a single `<br>` node and the
selection is lost.
- Type `LEFT/RIGHT ARROW KEY`
=> Traceback
- A paragraph is inserted again when clicking in the editable afterwards
- The isolated `<br>` node stays until it is deleted by pressing on `DELETE` in
the last (reinserted) paragraph.
Typically, any other case where the selection is manipulated programatically and
not put back in the editable (be it through a bug, or because a target
selection has become obsolete and can not be found) would produce such a
taceback.
task-3425395
closesodoo/odoo#128631
X-original-commit: 2ee6e08f42f913e3102ca7340bb40b0203432b67
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Fix `deleteBackward` and `deleteForward` processes around nested editable
zones, i.e.:
```html
<div class="odoo-editor-editable" contenteditable="true">
<div class="nesting" contenteditable="false">
<div "nested" contenteditable="true">
<p>content</p>
</div>
</div>
</div>
```
- `deleteBackward`, when used:
- just after the nesting element; should remove the nesting element
- at the start of the nested element; should do nothing
- `deleteForward`, when used:
- just before the nesting element; should remove the nesting element
- at the end of the nested element; should do nothing
This commit also move some existing tests that were related to the handling of
non-editable elements in their correct `describe` section.
task-3425395
X-original-commit: a52deabecef8a5d489743b0ae07d4d32302fd76e
Part-of: odoo/odoo#128631
This commit fixes the method so that it is not allowed to probe outside the
boundaries of the `root` editable element, no matter the value of `parentLimit`.
This also allows to not specify `parentLimit` (becomes the editable element by
default).
task-3425395
X-original-commit: ffeb1abcc675dd05fb9546e39aac4498e510bbbc
Part-of: odoo/odoo#128631
The commit [b7b05a2] added a `PLACEHOLDER_TEXT` constant to consistently
change the text in `we-toggler` when no element is selected from "/" to
"None", but forgot to update one comparison.
Steps to reproduce the issue:
- Drag and drop an "Add to cart" button
=> The "Product" toggler menu shows "None" when nothing is selected.
With the updated code, it says "Choose a record...".
- Type a partial name (e.g. "desk") in the search box and press enter
=> It still shows "None".
It should select the first item available in the list. In this case with
demo data, "desk" would be "[FURN_118] Corner Desk Left Sit".
[b7b05a2]: https://github.com/odoo/odoo/commit/b7b05a2d1c1d5
task-3266751
closesodoo/odoo#128617
X-original-commit: f0f9094334e5a09b89c1fc50865c9da339d0605d
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
When the user is creating the certificate for EDI Inoices and saves it without
providing the password then, the user will face error.
Steps to produce:
- Install l10n_es_edi_facturae.
- Change the company to ES Company.
- Create a certificate without giving password through,
(Invoicing > Configuration > Spain Facturae EDI > Certificates)
Error: 'AttributeError: 'bool' object has no attribute 'encode''
sentry-4257267006
closesodoo/odoo#128605
X-original-commit: 1422ebe86a4697b6ed706d82ce176434c2345c24
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
Signed-off-by: Saurabh Mishra (sami) <sami@odoo.com>
The test `test_search_project_root_id` fails when demo data are not installed.
This commit makes it demo data independent.
Task-3410352
closesodoo/odoo#128514
X-original-commit: cf63d549c8592400af6d96bd145169bd3ac636fe
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
A few months ago, the onboarding process for the journals according to ZATCA's Saudi eInvoicing
standards required arabic strings to be encoded in a specific format. The format in question
was not mentioned by ZATCA on any official document, however by reverse engineering some of
the sample CSRs shared by ZATCA through their SDK, we were able to figure out that the strings
were encoded using CP1252. Back then doing that allowed us to generate a CSR successfully.
A few days ago, just after the Saudi Localization was merged with master, we received a
complaint where trying to onboard a journal for a company for which the information was
encoded in arabic sometimes raised an exception. Upon investigating we found out that
the CP1252 encoder was the culprit. We tried removing it and now everything is working
fine, including the onboarding.
closesodoo/odoo#128312
X-original-commit: 31a3c25739bb6c0806da887a1f65e670c1b2f7ad
Signed-off-by: Josse Colpaert <jco@odoo.com>
Steps to reproduce
==================
- Open studio
- Go to reports
- Click on invoices
- Try do drag a text block at the end of the page after the table with
the total
Studio doesn't place a drop hook after the table.
Cause of the issue
==================
Studio only adds hooks before and after each direct child of the element
with a 'page' class.
Since [commit], the `#right-elements` and `#payment_term` elements are
outside the page and thus we can't place an element after.
Solution
========
- Move the `#right-elements` and `#payment_term` inside a new div since
they are part of the same line and we don't want to put an element
between them.
- Move that div inside the page.
- Add a clearfix class in order to have it's height correctly computed.
[commit]: https://github.com/odoo/odoo/pull/107714/commits/66373a538e123b29b983a8e02f302e7e258e084d
opw-3345430
closesodoo/odoo#127771
Signed-off-by: Florian Gilbert (flg) <flg@odoo.com>
Before this commit:
The property_stock_account_output_categ_id set on the product category can be empty.
This should not be a problem if the valuation is set to manual, as no account moves should be generated.
After this commit:
A condition was added to ensure the account moves are only created if the valuation is set to Automated (real_time).
closesodoo/odoo#128641
X-original-commit: 25b3c07063c0b45b60af4a1c1aca46a52d8b790a
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Pedro Nogueira (pno) <pno@odoo.com>
Before this commit, some notifications handler were using `return`.
The issue is that this will exit the notification processing loop
preventing further notifications to be processed. In practice, this
scenario is limited since notifications come by small batches but
it could be an issue.
closesodoo/odoo#128606
X-original-commit: e8fbc26716917b1066b9002010662d41aaeacbf0
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
This issue occurs when the user has not provided production account and is
trying to produce the manufacturing order.
steps to produce:
- Install `mrp_production`, `account_accountant`.
- From Settings > Users > Manage Users select a user (eg: Mitchell Admin) and
under `Technical` select `Stock Accounting Automatic group`.
- Inventry > Configuration > Products > Product Categories open a category and
change it's `Inventry Valuation` (property_valuation) to Automated.
- Through Accounting > Configuaration > Settings >
Stock Valuation check `Automatic Accounting` and remove Production Account and
save it. (You will see that production account got removed from the product
category).
- Now create a manufacturing order by Manufacturing > Operations > Manufacturing
Orders
- While creating manufacturing order select the product which comes under
product category you have modified, then confirm the
manufacturing order.
- Once it is confirmed click on `Produce All`.
video: https://encr.pw/09a2c
Error: `AttributeError: 'bool' object has no attribute 'id'`
Through our commit if the user does not specify a `Production Account` then the
user will face the UserError. The error is specified in
`_get_accounting_data_for_valuation` function while checking for `account_src`
or `account_dest`.
sentry-4271608065
closesodoo/odoo#128594
X-original-commit: 9265e785dedd8943296573fc6e5218925a33c522
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Finetuning of the events' kanban cards by increasing the left column's
width and resetting the font-size.
task-3380825
part of task-3326263
closesodoo/odoo#128580
X-original-commit: cfc2cd2283b9687f10209e1dc7e3c84060b12fcf
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
before this commit, if user is searching on member_ids
field in crm.team is giving an archived record also from
member_ids table.
* create a partner (Test Partner) and sales team (Test Team)
* set the created sales team for partner
* add and remove a user (A) to this sales team
* search for partners with sales team in which
user (A) is part of.
* result says that partner (Test Partner) matches the
search condition, which is wrong
In [1] we ensure that m2o relations in multipath domains
do not filter on 'active'.
However the context variable that does this will propagate
to all potential subqueries.
In this case this means 'crm_team_member_ids.user_id' on sale teams will be searched without filtering on 'active'
when it is a subquery of searching 'team_id.member_ids'. Even though searching 'crm_team_member_ids.user_id'
on its own would have filtered on 'active'.
The fix is to set the context for 'active_test' on the field directly, as we already have another field with 'active_test=False' if that is ever needed.
[1]: c15c07c405
after this commit, the search will return active records
only.
closesodoo/odoo#128563
X-original-commit: 08d4aeb0449d145a4e96565ff7e68dc856392904
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
If `stock_dropshipping` is installed, the "Transfer To" field of a lot
does not work with standard flows
To reproduce the issue:
1. Create a tracked-by-sn product
2. Update its quantity with 1 x SN
3. Deliver SN to a partner
4. Open the list view of lots/serial numbers and enable the column
"Transfer To"
Error: The field "Transfer To" for SN is empty, it should be the partner
The field `last_delivery_partner_id` is a computed one and the compute
method calls `_find_delivery_ids_by_lot` to get all relevant
information. In this method, we search the SMLs based on a domain
provided by `_get_delivery_ids_by_lot_domain`. If `stock_dropshipping`
is not installed, the method will return a legit domain:
https://github.com/odoo/odoo/blob/7adc661be1eb426a90842160b2e062446d3ccc03/addons/stock/models/stock_lot.py#L191-L196
However, if the dropshipping module is installed, an override creates
the same domain (directly in the override, without any call to `super`)
and adds a `OR` condition:
https://github.com/odoo/odoo/blob/7adc661be1eb426a90842160b2e062446d3ccc03/addons/stock_dropshipping/models/stock.py#L62-L70
But it contains an error: the `AND` operator is missing, it should be
```py '&', ('location_dest_id.usage', '=', 'customer'),
('location_id.usage', '=', 'supplier') ``` As a result, for an SM to be
found, its source location usage has to be `supplier`. This is the
reason why, in the above use case, the lot does not have any
`last_delivery_partner_id`: we did not find such an SML.
OPW-3386247
closesodoo/odoo#128558
X-original-commit: 8ecc177478f0ffc8ba9cfc65f47386363bd6cb4a
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
From 16.0 any user can delete a customer invoice/vendor bill even if it creates a sequence gap.
This commit updates the rights and the warning message:
- The deletion confirmation message contains a warning about the sequence gap
- Only a Billing Administrator/Accountant can delete customer invoices/vendor bills creating the gap
- Also, if the fiduciary mode is on (`quick_edit_mode`) it should be possible to delete
invoices/bills regardless of the user group
task-3284218
closesodoo/odoo#128556
X-original-commit: 2249f899049ef94b14b083c8db976662b868b026
Related: odoo/enterprise#44128
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Aliya Tastemirova (alta) <alta@odoo.com>
before this commit, on clicking the publish/unpublish
buttons from the tree view of the forum post, is showing
traceback due to missing is_published field in the
forum.post model.
publish/unpublish buttons in the action menu is added
by the js class website_pages_list.
after this commit, the js class is removed from the
tree and thus no publish/unpublish button is shown
in the action menu.
closesodoo/odoo#128540
X-original-commit: ada177c9a840347330942a8e1db2204bf0c280e0
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
The previous domain fix 84d8bf8167
was skipping all potential leaves of type other left out for work entries
therefore properly inherit instead of overriding and add the proper domain
closesodoo/odoo#128527
X-original-commit: 076d2179ad2f19c0ff8be043e492bdc7b780baef
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Prior this commit, non perfectly squared `.o_avatar` images were
not correctly fitted in the their boxes
task-3419159
part of task-3326263
closesodoo/odoo#128526
X-original-commit: cbe665eb2929a01e12714ae8e3fe66610780e7b9
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
Before this commit, 'last_session' inaccurately returned the newest
session, which was incorrect as the first session technically has no
preceding session. This update ensures that `last_session` does not
return any session when it is the first instance.
opw-3302489
closesodoo/odoo#128516
X-original-commit: d676f60af8f2ef45ed26e80f34bd4244f6f8157f
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Signed-off-by: Pedram Bi Ria (pebr) <pebr@odoo.com>
A recent discovery has led us to understand that actual HTTP requests to external services are performed even during non-external tests (even during at-install tests in fact).
This PR puts a stop to that, by installing a requests mock which results in a ConnectionError for any request to an other host than localhost / 127.0.0.1. May add richer routing support in the future, but currently the easiest way to handle is to override `_request_handler` and return custom responses as needed when matching expected endpoints.
Issues found so far:
- `/link_tracker:TestMailRenderMixin` performs requests to all sorts of domains real and fake during testing, originally fixed in #128249 but re-fixed more generically here (the link tracker handles connection failure gracefully).
- `partner_autocomplete` tests cause a request to clearbit to resolve the logo of the mock partner, failure is handled silently so nothing more is needed, this probably occurs in a few more locations (I didn't check every single log).
- `/mass_mailing:TestMailingControllers.test_tracking_short_code` creates shortlinks to example.com, then opens the shortlink. While the shortlink is local, it redirects to an external site and the test is not happy when that fails. Intercept requests to that endpoint and returns successes.
- `/website_sale:TestProductPictureController.test_resequence_images` touches the video_url of a product, which causes a call to `get_video_thumbnail`, which did handle (ignore) non-200 responses but not complete request failure. Add support for that (ignore `RequestException`).
closesodoo/odoo#128497
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Error responses are already ignored, but connection errors would blow
up the entire thing, which breaks `test_resequence_images` (and
possibly others).
Part-of: odoo/odoo#128497
Non-external tests should not be performing requests to external
websites or services.
Add a mock to handle such requests:
- if the test is not tagged external
- and the request is not to localhost
- and the request is not to `file:` (it's possible to install a
FileAdapter in a session to resolve file URLs)
- raise a connection error (and log, both with some details of the
blocked request for debugging)
The mock is layered on the lowest possible level (`Session.send`), so
tests can either:
- reconfigure the mock to handle cases differently (the mock is
re-created on every test)
- layer their own mock at a higher level of the library
Eventually we might also built-in a routing / dispatch mechanism so
it's easier to declare external services you want to mock, somewhat
similar to what's available client-side.
Whitelist `file:` because e.g. zeep performs `file:` request, using a
bespoke adapter installed in its session.
Part-of: odoo/odoo#128497
Steps to reproduce the bug:
- Create a storable product “P1” with BoM:
- Component: "C1", cost: $100
- Create a Manufacturing Order to produce 1 unit of "P1":
- Set any analytic account
- Confirm and validate the MO
- An analytic account line is created for $100 of C1.
- Change the quantity of the component to 0.
- Try to save
Problem:
A traceback is triggered, because the `amount` and `unit_amount`
variables are used without assignment.
Solution:
Assign “0” value to both variable in the beginning of the function,
therefore the analytic account line will be deleted.
opw-3257240
closesodoo/odoo#128495
X-original-commit: 513e3dea2c838bb6f805c567069ea39406c6634e
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
Steps to reproduce
==================
- Create and confirm MO with BOM1
- Consume the theoretical qty of your MO
- Update the BOM1
- Click on the `Produce All` button
- You will receive a message that the consumed quantity does not match the quantity
of the BOM1 anymore
- When clicking on the set quantities and validate button, the consume
quantities are not the ones that are previewed in the flexible consumption message,
but the initial MO quantities.
So in this commit, we updated the `To Consume` quantities as per the flexible
consumption wizard.
task - 3323154
closesodoo/odoo#128488
X-original-commit: fe95a33770c8b701b007310e2b9b5f7b0596f5a9
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Steps to reproduce the bug:
- Connect with a company using USD currency.
- Create a storable product "P1":
- Cost: $100
- Create a Purchase order:
- Add 1 unit of "P1"
- Currency: USD
- Create another Purchase order:
- Add 1 unit of "P1"
- Currency: EUR
- Go to the purchase analysis and select the list view.
Problem:
The purchase order in EUR is converted into the current company
currency, but the Euro currency symbol is used instead of the dollar
symbol
opw-3354221
opw-3348265
closesodoo/odoo#128479
X-original-commit: ad05cea889cb632946abceeb5c0db36b73a18afc
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Current behaviour:
When searching in `All Tasks` for tasks whos user is archived, no
results are returned.
Expected behaviour:
You should be able to see tasks of users that are possibly archived.
Steps to reproduce:
- Install Project
- Archive the user and contact Marc Demo
- Go to Project > All tasks
- Search for assignees "demo".
- No results
Reason for the problem:
The `user_ids` definition in the task is:
```xml
<field name="user_ids"
filter_domain="[('user_ids', 'ilike', self), ('user_ids.active', 'in', [True, False])]"/>
```
But there is no context of the `active_test=False` on the view. So
the ORM for the `filter_domain` generates a query which contains 2
relevant `EXISTS` clauses, and for the leaf `('user_ids', 'ilike',
self)`, the generated `WHERE` clause is
```sql
("res_users"."active" = TRUE) AND ("res_users__partner_id"."name"::TEXT ILIKE '%demo%'))
```
where we can see the presence of the `active_test`, because we don't
disable it in the *view*.
Fix:
Change the domain on the user to check on the field `name`, with this
domain, the ORM will not add an active test on this part. This
essentially does the same as 7a366abb40
but there was a regression in b77f60b155.
Affected versions:
- saas-16.1
- saas-16.2
- saas-16.3
- master
opw-3383564
closesodoo/odoo#128471
X-original-commit: aa6aa636de0f9f0a43bb1f603ecebbcd26b94bbd
Signed-off-by: Piryns Victor (pivi) <pivi@odoo.com>
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
In the new version of the iot we import a new "crypt" library which is not available for windows
Addition of the class in the input of the password
closesodoo/odoo#128467
X-original-commit: f84bbfac2de786bf73e1fbe6d3b77452e17ac4bb
Signed-off-by: Quentin Lejeune (qle) <qle@odoo.com>
In a sale order, an error is raised when selecting a product
(`product.template`) that has an archived variant (`product.product`)
which uses an attribute (`product.attribute`) still used in other
variants
Steps to reproduce:
1. Install Sales and Stock
2. Create a new product 'TEST'
3. Add the attribute 'Legs' with values 'Steel' and 'Aluminium"
4. Create a new sale order for any customer with product 'TEST' and
variant 'Steel' and confirm it
5. Open the form of product 'TEST' and add the attribute 'Color' with
values 'White' and 'Black'
6. Create a new sale order and try to add the product 'TEST', an error
is raised
Solution:
Make sure there is a product attribute value to disable before excluding
one in the ptavList
Problem:
A `product.product` of a `product.template` can be archived if it has
been used in past orders and a new `product.attribute` has been added to
the `product.template`. Thus, the old product attribute value will
appear in archivedCombinations but there is nothing to disable because
the `product.attribute` is still used.
opw-3413721
closesodoo/odoo#128465
X-original-commit: 8240a34a7f5b082aca4b495447abf87481a04913
Signed-off-by: Guillaume Merlin (megu) <megu@odoo.com>
Steps to reproduce the bug:
- enable “package” option in inventory settings
- Create a package
- save and click on “Package Transfers”
- Create a new transfer
Problem:
No operation type is displayed. Because we do a `name_search` with
the following domain: `[["code","=",none]]`
opw-3394868
closesodoo/odoo#128463
X-original-commit: 149af0ebf22b4575c89d6f4f875f988dc6064c07
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
On smaller screens, `.o_status_bar_buttons` are displayed in a dropdown.
This commits reset the styles of these buttons when they are displayed
in the dropdown, so they look like regular dropdown items
task-3414462
part of task-3326263
closesodoo/odoo#128462
X-original-commit: 071d92b3926f6a062ca3b0b0c9c70d8567bb6899
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
This commit removes the displayName variable of the calendar controller
since it wasn't used anymore and the extension of the displayName is now
updated in the ProjectCalendarController instead. This fixes an issue in
project where the extension of the displayName in the project calendar
controller ( - Tasks by Deadline) would not be shown in the view.
opw-3410987
closesodoo/odoo#128461
X-original-commit: 120ab2513b487d0c117e5c67ed76e6d154d0243f
Signed-off-by: Mathieu Duckerts-Antoine (dam) <dam@odoo.com>
While creating a Manufacturing Orders, when user give date format as '%d/%m/%Y'
and when it tries to match the date format with '%m/%d/%Y' in
'_add_transit_line' method, the error will be generated.
Steps to Produce:-
1. Install 'mrp' and 'purchase' module
2. Change the format of date in 'Languages' as '%d/%m/%Y'
3. Activate 'Multi-Step Routes' in inventory configuration
4. Go to 'Warehouse' and select 3 steps route in 'Incoming Shipments' and
'Manufacture' and save
5. Go to 'mrp' and create a new BOM
6. Go to 'purchase' and create a PO with the same product in BOM and confirm it
7. Click on smart button 'Receipt' -> 'set quantities' -> 'validate'
8. Go to 'mrp' and create a MO with same BOM change the 'Scheduled Date' and
confirm it
9. Click on smart button 'Overview'
Trace-back will be generated.
Applying these changes will resolve this issue.
sentry-4088257491
closesodoo/odoo#128453
X-original-commit: d1d7141fd52bd7167910074adcde2cd95e8b9440
Signed-off-by: Ivan Elizaryev (iel) <iel@odoo.com>
QR code extraction fails in some cases when we try to get the Base64 content
from the Saudi EDI attachment when the datas is too voluminous. To avoid this, we pass
bin_size=False in the context to always get the attachment datas correctly.
closesodoo/odoo#128429
X-original-commit: c0369d9f5bda428e7501a7ab1e11134af8c7888d
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Mehdi Bendali Hacine (mebe) <mebe@odoo.com>
Sometimes, when the base64 data used to render the QR code is too long,
some of the special characters included might be wrongly encoded in the
url passed to the /report/barcode route. To avoid this, we format the QR
code string through the quote_plus method to make sure it's always
properly encoded
X-original-commit: 4b5b0caa75302c945d9f762526f1939783ef3250
Part-of: odoo/odoo#128429
With the new website header templates, a search bar will be available
in the header. To avoid two search bars in the page add an option to
remove the search bar in the /shop page.
task-3302735
closesodoo/odoo#121391
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Before this commit `.webp` images could not be used in odoo.
After this commit `.webp` images can be uploaded to odoo.
- can be used in image field
- can be used in HTML field image
- can be used in mails and website
- can be transformed (shape mask, filter effect, crop, rotate, resize, quality)
- can be included in PDF reports
Because the Pillow plugin for `webp` relies on the `libwebp` native library, it cannot be used.
Because of this, the server-size resize (for Image fields) and conversion to `jpeg` (for `wkhtmltopdf`) are done beforehand by precomputing them when a webp is uploaded.
After this PR, the general flow when uploading an image is:
1. On upload in `website`: suggest conversion to `webp`
2. On `webp` upload:
2-A. upload converted `jpeg`
2-B. upload resized `webp` (and therefore `jpeg` of each resize because of (2-A))
There is currently no "fallback to original" in (2-A).
task-2774352
closesodoo/odoo#85494
Related: odoo/enterprise#24998
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
This commit introduces the computation of the image size from a webp
binary source without relying on PIL.
This is needed by eCommerce to determine which image to fetch when using
the zoom functionality on the product page.
task-2774352
Part-of: odoo/odoo#85494
Since [1] dropped images are saved as attachments.
When such an image is a WEBP, its pre-computed resizes and conversions
to jpeg are not generated.
This commit adds the behavior of saving an `o_modified_image_to_save`
when a `o_b64_image_to_save` is a WEBP.
[1]: https://github.com/odoo/odoo/commit/3bbce756c69a206d07abd31059f0392c26b36096
task-2774352
Part-of: odoo/odoo#85494
`libwebp` cannot be used to perform resize operations on webp images on
the server.
This commit uploads all resizes of webp images whenever a webp image is
uploaded:
- resized to any smaller size in 1024, 512, 256 & 128,
- each size converted to jpg as well to be usable in `wkhtmltopdf`.
When an Image field requires `_imageProcessing` to resize a webp image,
it retrieves the pre-resized image instead of running through the
Pillow toolbox.
Pre-converted images are stored as `ir.attachment`s with:
- `res_model` = ir.attachment
- `res_id` = id of transformed attachment
i.e. id of original size webp for resized images
id of webp for jpeg-converted images
- `description` = "format: image/jpeg" for jpeg conversions,
"resize: [size]" for resized images.
task-2774352
Part-of: odoo/odoo#85494
Wkhtmltopdf is unable to render WebP images.
This commit intercepts the requests for the image data during PDF
reports rendering to replace them by the converted image that was
uploaded with it.
task-2774352
Part-of: odoo/odoo#85494
The library used to generate PDFs does not support the WEBP image
format. For those images to be included in reports, they need to be
converted. For security reasons, this conversion cannot be done on the
server, therefore it was decided to keep an already converted copy of
such images.
This commit converts uploaded WEBP images to JPEG and uploads them both
so that the report generation can use the JPEG instead.
This commit also pre-generates the resized version of images - and JPEG
versions of each of them.
task-2774352
Part-of: odoo/odoo#85494
The library used to generate PDFs does not support the WEBP image
format. For those images to be included in reports, they need to be
converted. For security reasons, this conversion cannot be done on the
server, therefore it was decided to keep an already converted copy of
such images.
This commit converts uploaded WEBP images to JPEG and uploads them both
so that the report generation can use the JPEG instead.
task-2774352
Part-of: odoo/odoo#85494
Before this commit two options of images are named "Width":
- the one that adjusts the image resolution
- the one that changes the `width` CSS property
This commit makes the following changes:
- the option about the image resolution is renamed to "Format"
- the "Format" option combines the image resolution and the file format
- an option item gives access to the initially uploaded file format and
resolution
- for all sizes the image format is set to `image/webp`
- for the uploaded size, an `image/webp` version of it is available too
- upon upload, the default selection is an `image/webp` version of the
image
task-2774352
Part-of: odoo/odoo#85494
Alexandre Kühn