Before this commit, errors were introduced when optimizing the synchronization by limiting it to the calendar's view range. For users different than the first to synchronize its calendar, when trying to create events in Odoo before or after the synchronized view range (e.g. 1 month), these events were being auto-archived in Odoo right after their creation in Outlook. This happens because the first range to be sent to Microsoft Outlook is currently defining how much time in the past and in the future the events will be synchronized.
After this commit, the previous approach of defining a range of two years for the delta synchronization (events that were last updated) in the future is back temporarily, now with one year in the past. This behavior must be improved considering the calendar view range and must be flexible with the first synchronized view range.
Issue from: 3525764
closesodoo/odoo#147366
X-original-commit: 2a503c1b08bd31c9ac0098e774eea8dd5b5c2c1e
Signed-off-by: Arnaud Joset (arj) <arj@odoo.com>
Signed-off-by: Gabriel de Paula Felix (gdpf) <gdpf@odoo.com>
Steps to reproduce:
- Add a "Form" snippet on the website.
- Select the first field.
- Try to toggle the "description" option of the field.
-> Problem: there is no description added on the field.
The problems appeared since [this PR] and comes more precisely from
[this commit]. The problem is that one condition required to fill the
`default_description` parameter is that `field.type === "description"`.
This should not be the case. Indeed, here was the flow before
[this commit]; When the user toggled the description option,
`toggleDescription` assigned `field.description` to `true`. The field
was then rendered trough `renderField()`. During this rendering, the
system called the `website.form_field_description` template through
`website.form_field` independently of the field type. Because
`field.description` was set to `true`, a `div` with the description
"Describe your field here." was added on the rendered field. To solve
the problem, the `field.type === "description"` condition has been
removed as a condition to set the `default_description` parameter. Now,
as it was the case before [this commit], this parameter is filled either
if `field.description` is set, either if the field name is `email_cc` or
`email_to`.
The error probably comes from the fact that the name of the template
used to render the field is `"website.form_field_" + field.type`. As the
name of the template in charge of rendering the description is
`website.form_field_description`, the author probably thought that this
template should only be called when `field.type === "description"`. This
is not the case; the template `website.form_field_description` is always
called when rendering a field (independently of the field type through
the template `website.form_field`) but is only relevant if
`default_description` is set.
Note that this fix fixes also another bug:
- Add a "Form" snippet on the website.
- Add a field which is of type "Cc".
-> Problem: there should be a description of type "Separate email
addresses with a comma." on the field.
This commit also adapts the `website_form_editor_tour` tour to verify
that the description option works as wanted.
[this PR]: https://github.com/odoo/odoo/pull/130467
[this commit]: https://github.com/odoo/odoo/commit/363251986dcd753796b4b037a2da2e118b3e8e35
opw-3630348
opw-3604548
closesodoo/odoo#146115
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
`onDuplicate` was marked as optional while it never was. If you don't
specify it, the call to `this.props.onDuplicate();` will still be
executed and will crash:
`Uncaught Promise > this.props.onDuplicate is not a function`
Randomly spotted while reviewing PR about duplicate button in list view
related to opw-3640878. But it's not related to it.
closesodoo/odoo#147647
X-original-commit: 296feaa9aa16cdb1766ce8d2f5ae8126d74f881b
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
This commit is fixing a last minute error in commit [1] after a push
force which move its code above the existing line `vals['url'] = url`.
After the code move, `vals['url']` was not the updated url value (which
went through slugify and unique path functions).
- Create a /test page, publish it.
- Set /test as homepage url directly on the website (in the settings)
- Go to that page
- Open the page properties and change its URL from /test to /test_un
-> The page url is /test-un but the website homepage_url is still
/test_un (not slugified) in the website settings
[1]: https://github.com/odoo/odoo/commit/374a1b31f70a3209b1ae11db8e5886350579c7f9closesodoo/odoo#147641
X-original-commit: 3c8a58b654418fc2fc0dc9bc28420c7dcb1bafee
Signed-off-by: Colin Louis (loco) <loco@odoo.com>
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Steps to reproduce
====================
1 Open the course and try to retake the quiz.
2 Traceback while submitting the quiz.
Technical
===========
Due to missing closing square bracket in the attribute selector of jquery.
After this commit
==================
There will be no traceback while submitting the quiz.
Task-3633410
closesodoo/odoo#147611
X-original-commit: eea7da64de4e6b70ea4d6b1fc277b36b278ad329
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Steps to reproduce:
-------------------------
- Install project and sale_timesheet module
- Open the Project module
- Go to task's timesheet notebook
- Add a new line
- Set empty in so_line field, raises traceback
Issue:
--------
- In timesheet notebook, when we set so_line as an empty .it will raises
traceback.
Cause:
---------
- #145821 when set empty so_line field there is undefined value read.
Fix:
-------
- On a field change, compare the so_line field value with proper record id check
with new value.
task-3642371
closesodoo/odoo#147546
X-original-commit: ed2417225975001dd7b6ec1d3655fe880fe2c108
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Prior, if the time off type needed second approval, there was no activity generated for the responsible.
This commit fixes that. Moreover we also organize the code by taking
references out of the loop.
task - 3584190
closesodoo/odoo#142327
Signed-off-by: Bertrand Dossogne (bedo) <bedo@odoo.com>
In case more that one leave record in passed to message _subscribe
in will throw "Expected singleton" ValueError.
This commit fixed the issue.
Part-of: odoo/odoo#142327
- Adds some permissions to protect sensitive pos_adyen data and methods.
- Reduces the risks of abuses of the pos_adyen features.
Those changes are not optimal. The whole system should be changed.
- Fixes the printing of Adyen receipts data in the receipt.
- Fixes an error when receiving a successful Adyen payment notification for the kiosk.
- Fixes an error when Adyen returns an error for a payment for kiosk.
- Fixes an error when requesting adjustment/capture to Adyen (pos_restaurant_adyen and kiosk).
- Removes unused handling of adyen_latest_diagnosis field (the field will be removed in master).
closesodoo/odoo#140327
Task-id: 3500598
Signed-off-by: Théo Vincent (thvi) <thvi@odoo.com>
Steps to reproduce the issue:
- Have two companies in your database.
- Create a partner:
- Set "receipt_reminder_email" to True for Company 1.
- Set "receipt_reminder_email" to False for Company 2.
- Create a Purchase Order with Company 2.
Problem:
The field "receipt_reminder_email" is a related field, so its value
is False. However, if you switch the current company to "Company 1"
while keeping the Purchase Order in Company 2, the
"receipt_reminder_email" is updated to True.
Solution:
The field should be computed instead. the readonly for this field in not
neccessary anymore so the inverse is not mandoatory.
opw-3593577
closesodoo/odoo#147648
X-original-commit: 2211e08f69eed7af9be20f178f659f6a71fb6ac4
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
Each date in the timeline snippet was displayed with the time line going
through them. The line is supposed to be cut around the date. This
occurs since [1] which made it so `<span>` elements are automatically
removed by the editor if they do not have any attributes. Unfortunately,
this snippet relied on such a span, since [2]. This commit solves the
issue by making the snippet better (and the XML structure will further
be improved in the master forward-ported version). Unfortunately, this
is not entirely stable, even though it leads to the exact same result
provided no custom code tweaks the snippet. It will also solve existing
timeline snippets in current databases.
Note: [1] was obviously a mistake to merge in stable, although it might
be kept seeing the delay since it was merged and nothing critical seems
to have happened.
[1]: https://github.com/odoo/odoo/commit/a26e27c85e6a0685b6cf4d2dbab90453899df34c
[2]: https://github.com/odoo/odoo/commit/fbe38fb41dfdb76878748a1149f93700b566d228
task-3657771
closesodoo/odoo#147598
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
*: website_event_sale, website_sale_slides, website_event_booth_sale
In website_sale, we have a setting to prevent the sale of zero priced products.
It works fine but triggers also on order of free events, free event booths and
free courses.
This is unwanted behavior and a check has been added to still allow those three
product types to be sold for 0.
Task-3388254
closesodoo/odoo#147589
X-original-commit: ab839650be3f04422aab8af81b72af475c0b6fd7
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Steps to reproduce the bug:
- Create a storable product “P1”:
- Tracked by: SN
- BoM:
- product qty: 1
- Component: consumable product qty:1
- Create a MO to produce 12 unit of P1
- Update the qty of the consumable product to 31
- Confirm the MO
- Click on “Mass produce”
Problem:
An user error is triggered:
“It is not possible to unreserve more products of Consu than you have in stock”
The product is a consumable, we should not update its reserved quantity.
opw-3620437
closesodoo/odoo#147571
X-original-commit: 33728387925439eaf4971dc732ff46fd19432f2c
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
To reproduce (on runbot):
- Enable "debug" mode
- Switch to company "My Begian Company"
- Go to: Payroll / Configuration / Contracts / Template
- Create a new contract template:
* Name: Student contract template
* Salary structure: Belgian Student
* Job position: Student
- Create a new applicant for job position (Student)
- name: John Doe
- email: john@example.com
- Click "Generate Offer":
- Contract Template: Student contract template
- Click "Save"
- On the offer, click "Salary Configurator"
=> by default student has only 1 benefic in kind (regular pay) but on
the salary configurator you see many more entries listed (ex: 13th Month)
that are coming from another salary structure (Belgian Employee).
During the simulation as no employee exists (it's an applicant), a new
"temporary" employee is created and assignee to the contract; this
update the company which trigger a recomputation of the `structure_type_id`
field (since odoo/odoo@21aca4704) resetting its value to the country's
default.
This commit ensure we only reset that field when the country do change
closesodoo/odoo#147079
Signed-off-by: Sofie Gvaladze (sgv) <sgv@odoo.com>
Several tests are non deterministic because they are using
`assert.verifySteps` at the wrong moment. Helpers such as
`afterNextRender`, `nextTick`, `Deferred` are used but those are
either not reliable or cumbersome to setup.
This PR introduces an asynchronous API on top of
`assert.step`/`assert.verifyStep`. This will wait until steps are
executed or until the timeout is reached.
fixes runbot-52660,54471,52794
closesodoo/odoo#147455
Signed-off-by: Matthieu Stockbauer (tsm) <tsm@odoo.com>
Previous PR odoo/odoo#143570 moved some move line ordering logic from the
model to the view to avoid recomputing of these fields since it was
causing issues with the computes occurring at the wrong time.
Unfortunately every field used in the `default_order` in the view has to
be present in the view and since v16 any fields that have a groups
attribute that isn't met isn't loaded in the view.
Therefore we have to force the `result_package_id` to always be in the
view even if `stock.group_tracking_lot` is not true (i.e. packages are
active)
Steps to reproduce:
- create +save a receipt with a tracked product
- click on the burger button to open the detailed operations of the
tracked product
- add 2 move lines + Confirm
Expected behavior:
the move lines save
Actual behavior:
JS traceback due to trying to sort on a field that isn't present in the
view
closesodoo/odoo#147188
Signed-off-by: Quentin Wolfs (quwo) <quwo@odoo.com>
Signed-off-by: Tiffany Chang (tic) <tic@odoo.com>
When orderpoint.qty_multiple is decimal, then remainder may be wrong. The applied formula is: qty_to_order % qty_multiple = remainder
Examples:
510 % 10 = 0
51% 1 = 0
5.1 % 0.1 = 0.09999999999999937 which is rounded to 0.1 > 0
0.51 % 0.01 = 0.009999999999999998 which is rounded to 0.01 > 0
This PR fixes it.
closesodoo/odoo#147521
X-original-commit: e8f35a63fac9e9c3613c2b56fd6d65e79b64d6e9
Signed-off-by: Tiffany Chang (tic) <tic@odoo.com>
The `calendar notification` tests patch the `setTimeout` function.
This sometimes leads to infinite recursion when the `multi_tab`
service has enough time to initialize: this service make use of
`setTimeout` to call the `heartbeat` method repeatedly. Moreover,
patching the `setTimeout` method is not a good idea since it makes
this method synchronous which totally changes the flow that is tested.
This PR fixes this issue by using the `contains` helper instead: this
method will wait for the element to be inserted in the DOM and perform
the assertion afterwards.
closesodoo/odoo#147503
X-original-commit: 973db5a
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Signed-off-by: Matthieu Stockbauer (tsm) <tsm@odoo.com>
Description of the issue/behavior this commit addresses:
When 2FA is on on a user and he tries to use an API key to do a xmlrpc request,
the request fails. This is due to the system which choses whether or not to
send an alert via mail to look in the request's values while there is actually
no url request in that case.
Desired behavior after this commit is merged:
This commit adds a check to make sure a request is available before checking
its values.
opw-3645609
closesodoo/odoo#147475
Signed-off-by: Thomas Becquevort (thbe) <thbe@odoo.com>
PDF written with scribus (and some other software) have a problem when filling fields: the output
does not work as expected. The replaced value is there, but hidden behind a blue overlay, shown
only when clicking on it.
We now show the field value and ensure filled fields are read only.
Additionally, some readers only allow a single value per field name. Even if the values were
different on the documents, only one would be shown. We now rename the fields to ensure they are
different when they have different values.
task-3626047
closesodoo/odoo#145163
Signed-off-by: Morgane Demesmaeker <edm@odoo.com>
Steps to produce
========================
- Activate QR code in pos config
- Open session
- Make an order for a certain partner (do not invoice)
- At receipt, scan the QR code
- Sign in as a normal user (like admin)
bug - Invoice is created for admin and not the partner in the order
After this commit
========================
The partner of the created invoice will be the partner of the pos order.
task - 3497301
closesodoo/odoo#147484
X-original-commit: 2b45e8732e39f13a6293ffda7bf9fed9e8d951f8
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Signed-off-by: Parth Solanki (paso) <paso@odoo.com>
Steps to reproduce:
- Activate debug mode
- Install `Purchase` module
- Set user timezone to `Europe/Brussels`
- Create a purchase order and add an order line
- Set `Receipt Date` to any date in the future with time 01:00:00
- Confirm the purchase order
- Click on "Confirm Receipt Date" button
- Check message in the chatter
Issue:
The receipt date is the day before the one set in the purchase order.
(Same issue when sending reminder by mail)
Cause:
`date_planned` is stored in UTC in the database and used as it is in
the message.
Solution:
Convert `date_planned` to the order timezone before sending the
message.
opw-3503928
closesodoo/odoo#147525
X-original-commit: 7407cf441ae271aa6a4e67c351a5d5ca8de30b08
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Nasreddin Boulif (bon) <bon@odoo.com>
Steps to reproduce:
- Install Project module
- Login as admin
- Create a task an assign it to admin
- Go to 'My Tasks' page (`example.com/my/tasks`)
Issue:
The avatar of assignee is not displayed.
Cause:
Using a row over two elements that are already in a table.
Solution:
Add `px-0` bootstrap CSS class to the avatar.
opw-3592972
closesodoo/odoo#147369
X-original-commit: fc94a19c3ae66765a2f814533c17d6ec0f9533fb
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Signed-off-by: Nasreddin Boulif (bon) <bon@odoo.com>
steps to reproduce:
- as admin, go to /shop and add a storable product to cart
- disable all delivery methods
- use a coupon to set the price to 0
before this commit:
- the payment button is clickable even if there is a big red
warning saying "Sorry, we are unable to ship your order"
after this commit:
- the payment button is hidden if an error is displayed and
the route /shop/payment/validate is blocked if there is an
error displayed
opw-3582207-nda
closesodoo/odoo#146251
X-original-commit: 6db61c5cc0ca49a31252985fa2d690cb6514e7f7
Related: odoo/enterprise#52753
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Signed-off-by: Nicolas Danhier (nda) <nda@odoo.com>
Current behavior:
When a quotation is modified and the order is settled in the same time,
you get an error when trying to pay for the order.
Steps to reproduce:
- Create a quotation with 3 lines
- Settle the order in the PoS
- Modify the quotation (remove one line)
- Go back to PoS, and try to pay for the order
opw-3614770
closesodoo/odoo#147499
X-original-commit: 7e48111a9678c5acf8188796824f2cb9b4f1af9d
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Signed-off-by: Robin Engels (roen) <roen@odoo.com>
Unit price is recomputed on non groupable order line instead
of being the same as its sale order line counterpart.
Steps to reproduce:
- make sure unit measure category are not groupable
- create a sale order and add a line with a product with UOM
unit (ex: acoustic bloc screens) and quantity 3
- change the default unit price (100$ instead of 295$)
- open the point of sale
- open the SO and click on settle the order
=> price is 295$ instead of 100$ on each of the 3 lines
opw-3569481
closesodoo/odoo#147487
X-original-commit: 00d8a876c501098da1e8b2f7484e5e3808b61865
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Signed-off-by: Nicolas Danhier (nda) <nda@odoo.com>
Steps to reproduce:
- Create a product with AVCO that you invoice on Ordered quantities in the Vendor tab.
- Create a PO with a value of 200
- Create an invoice and change the price to 100. Then cancel the Invoice.
- Create a new invoice and confirm it without changing anything (so price is 200)
- Receive the product
- The valuation will be 150, the average of the 2 invoices.
Bug:
all linked invoices are taken into account
Fix:
only consider posted ones
opw-3633051
closesodoo/odoo#147485
X-original-commit: b899edd5b9c2f5e813fc0a83ea5506672785f47b
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: Walid Hanniche (waha) <waha@odoo.com>
Configure a product having category set with:
- Costing Method: Average Cost (AVCO)
- Inventory Valuation: Manual
Create a purchase order with the product
Confirm
Receive Products
Create bill (do not set date)
Confirm
Traceback will appear:
'AssertionError: convert amount from unknown date'
It occurs because of an attempted currency conversion without a date
As the bill is without date it should raise an UserError instead
opw-3628295
closesodoo/odoo#147367
X-original-commit: 03436a006f31f4bf42336fe31514161562c9b180
Signed-off-by: Adrien Widart (awt) <awt@odoo.com>
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Steps to reproduce:
- Inventory -> Delivery -> New Planned transfer
- Add two lines with two different products and save
- Set different scheduled dates for each move
- Set the earliest move quantity_done to the demand
- Validate and create a backorder
Issue:
The done picking scheduled date will be changed to the latest move (that
is moved to the backorder).
This is due to a recompute of the picking's scheduled_date *before* the
remaining moves are assigned to the backorder.
Note:
The order on the `stock.move.line` had to be removed, as it forced a
recompute of the original picking *before* the assignation of the
remaining moves to the backorder.
What happens is :
- Updating the move will check its move lines
- To follow the SML order, it will need their pickings
- To follow the picking order, it will need their scheduled date
- Their scheduled dates can be out of date (since we already put some
moves to `done`)
- This will lead to a recompute of the original picking's scheduled date
Instead, what we do is adapt the changes from odoo/odoo#79069, moving
the order from the model to the reports where it's used.
opw-3346598
closesodoo/odoo#147330
X-original-commit: 92092420548cb68db03ac139c23608fc1aa3a7cd
Related: odoo/enterprise#53320
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: Quentin Wolfs (quwo) <quwo@odoo.com>
The "Channel subscription is renewed when channel is left" test
ensures the bus subscription is renewed when the user leaves the
channel. In order to do so, the test relies on a patch of the bus
service and awaits the `waitUntilSubscribe` helper. This is not
correct: the subscription will never be triggered since the bus
service method is patched to only call `assert.step`.
This test passes most of the time by luck: `waitUntilSubscribe`
detects the first subscription (the one that is triggered when
starting the bus service) and the delay is most of the time enough for
the step to be ready.
This PR fixes the issue by:
- waiting the first subscription to ensure it does not interfere with
the test.
- removing the bus service patch: waiting for the subscription is
enough.
fixes runbot-46941
closesodoo/odoo#147255
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Befoer this commit, duplicating a POS payment method led to automatic
assignment to the source payment method's POS configs. This behavior
caused issues, particularly when the POS session was open.
opw-3635647
closesodoo/odoo#147238
X-original-commit: 0725850a9d2893ea80518575735ca407cc608968
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Since [1] when the `Colorpicker` template cache was moved from
`ColorPalette` to `getColorPickerTemplateService`, the custom buttons
fill color cannot be set as a gradient anymore.
This happens because the needed `getTemplate` props is injected for the
font and background colors, for the `we-colorpicker` but not for the
link tools color palettes.
This commit restores the gradient color selection for custom buttons by
linking the `getColorPickerTemplateService` to the link tools color
palettes.
Steps to reproduce:
- Edit Home page.
- Click on "Contact Us" link in header.
- Select link style "Custom" in link tools.
- Open "Fill Color" palette.
=> Gradient tab was not shown in palette.
[1]: https://github.com/odoo/odoo/commit/1d2e54088b0f0e28464ab6aa884fb2e1110e8e04
task-3641914
closesodoo/odoo#147373
X-original-commit: 087861bcbfe444765fdb0b81e0398c12d8db34e8
Signed-off-by: Soukéina Bojabza (sobo) <sobo@odoo.com>
Signed-off-by: Benoit Socias (bso) <bso@odoo.com>
A anchor menu in the mobile offcanvas related to an element in the
current page doesn't work in offcanvas:
- The offcanvas doesn't close
- The page doesn't scroll to the clicked location
This is because the menu anchor navigation is hooked to use our own
scrolling behavior instead of the browser one.
Doing so, we preventDefault, which prevent the offcanvas menu to close
itself when clicking on a anchor menu.
This commit simply manually closes the offcanvas and once the closing
animation is complete, starts our own smooth scrolling.
It also targets the desktop offcanvas menu (when hamburger layout is
selected) so it got a smoother UX: it closes then scrolls, instead of
scrolling but not closing.
Another possibility would have been to just close manually the offcanvas
without a preventDefault and without a call to our custom scrolling
method.
Doing so, the browser would naturally scroll to the element while we
close the offcanvas but it would be less elegant as you wouldn't see the
scrolling animation.
Note that the offcanvas was introduced with commit [1].
[1]: https://github.com/odoo/odoo/commit/bc13176de8d66bbdc1c536017b1f046c5fd31a86
opw-3604963
closesodoo/odoo#146907
X-original-commit: db881e66785a866319bd4980a9ae7b6393e55457
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Keeping things in the same order between both files will help when
modifying this file later.
After this commit, the `globals` in both files are 100% sync'd.
Part-of: odoo/odoo#146907
A later commit will add `Offcanvas` as new bootstrap global in the
eslintrc files.
Since the globals are randomly sorted, the chance is taken to regroup
those.
Part-of: odoo/odoo#146907
Before this commit, the "on hover" animation option would be shown for
images of type url-attachment-redirect.
Selecting that "On Hover" option value would result in a crash if the
image was CORS protected (which is often the case).
Steps to reproduce:
- Drag & drop "Text - Image" snippet
- Double click on an image to replace it
- Select in the media dialog "Add URL" and insert a CORS protected
image URL
- The image is correctly added, and its url is something like
`/web/image/123-redirect/xxx.jpg`
- Click on the image and then click on its "Animation" option and select
"on hover" as value
-> It crashes
The same error will happen with absolute URL of a CORS protected image
(instead of the relative local redirect attachment-url
`/web/image/123-redirect/xxx.jpg`).
Technical stack:
> the XML option `data-animation-mode="onHover"`
> call the js method `animationMode()`
> calls `trigger_up('enable_hover_effect')`
> calls `setImgShape()`
> calls `_applyShapeAndColors()`
> calls `_writeShape()`
> calls `applyModifications()`
> calls `loadImage()` which fails to load the image
-----------
Technical note: JS `fetch()` takes advantage of the browser cache, no
need to create a `Map` cache for it, despite the `_computeVisibility()`
method being called multiple times.
----------
Related to commit [1].
The code is failing since commit [2] which added the "On hover" image
animation.
Other animation values won't fail. And not-cors-protected images will
work fine with the on hover option.
[1]: https://github.com/odoo/odoo/commit/f0fe283c761cd6b1d7293dd41795ac6fc721e341
[2]: https://github.com/odoo/odoo/commit/7f730f81ec541cc7791fc6b3fded17c838433f85closesodoo/odoo#146732
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
There is a code in charge of removing image animation attributes, but
this code was not removing the `o_animate_on_hover` class.
Probably not that big of a deal but during the investigation of a bug,
this class was not removed while the attributes where, which seems to
lead to a crash later.
Related to commit https://github.com/odoo/odoo/commit/7f730f81ec541cc7791fc6b3fded17c838433f85
Part-of: odoo/odoo#146732
There is cases leading to have a `data-shape` but no
`data-shape-colors`. It then makes the code crash.
Step to reproduce:
- Drag & drop "Text - Image" snippet
- Double click on an image to replace it
- Select in the media dialog "Add URL" and insert a CORS protected
image URL
- The image is correctly added, and its url is something like
`/web/image/123-redirect/xxx.jpg`
- Click on the image and then click on its "Animation" option
-> It crashes
In such a case, the code was crashing on the line below this fix:
`img.dataset.shapeColors.split(';')`
The modified code here is related to commit [1].
But the code only break in Odoo 17, probably following commit [2].
[1]: https://github.com/odoo/odoo/commit/cd403480f90cf7103651f3be818a14b06d3c73ca
[2]: https://github.com/odoo/odoo/commit/7f730f81ec541cc7791fc6b3fded17c838433f85
Part-of: odoo/odoo#146732
The default is 25000 rounds, which is too low nowadays.
An off-the-shelf laptop takes ~400ms for a single hash at 600k rounds.
closesodoo/odoo#147202
X-original-commit: e200e96bfbb9cc29771b3727231e2f9a9ae01825
Signed-off-by: Olivier Dony (odo) <odo@odoo.com>
Some printers incorrectly specify the content-type of PDFs as "pdf" instead of
the correct "application/pdf." To handle this situation,
an alias has been introduced, treating content-type "pdf" as "application/pdf."
[Reproducing original bug]
1. run odoo with documents module
2. prepare email file
2.1 create email with a pdf attached
2.2 export email to .eml
2.3 modify content-type of the pdf from "application/pdf" to "pdf"
3. send prepared email to odoo to inbox-financial alias (the default one
creating documents)
4. Go to documents, observe that the created PDF is blank!
[Motivation for fix]
Since:
1. Odoo uses the Python built-in module for parsing emails*
(the actual issue lies outside Odoo code).
2. "pdf" is not an accepted MIME type according to current norms
(https://datatracker.ietf.org/doc/html/rfc6838#section-4.2).
It's not an actual Odoo bug.
However, redirecting this issue to the appropriate printer manufacturer and
waiting for a fix may be time-consuming, hence the proposed fix.
*function parsing email with the Python built-in module
https://github.com/odoo/odoo/blob/407ea60796a2b18eb02f5569e1cfab9f1163a572/addons/mail/models/mail_thread.py#L1282
opw-3462260
closesodoo/odoo#147363
X-original-commit: e95a19341536e442239a7e940089d7f66ab9f534
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Versions:
---------
- saas-16.2+
Steps to reproduce:
-------------------
1. Have a project with tasks & sub-tasks;
2. invite portal user to project;
3. log in as portal user;
4. go to a sub-task;
5. click the parent task button.
Issue:
------
Javascript is trying to get the type attribute of an `undefined` value.
Cause:
------
Commit 590beec447 added `task_properties`
to `view_task_search_form`, this search view is used by
`action_project_sharing_view_parent_task`, bringing it into view for
portal users who do not have read access to this field.
Solution:
---------
Add a `search_view_ref` to the context to force using
`project_sharing_project_task_view_search` instead.
opw-3498012
closesodoo/odoo#147377
X-original-commit: 47b0f6a42464ff41d40507cec5771b6dc3131d47
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
When the user inputs nothing in the setQuantity input in the product catalog input,
NaN is fixed in the productCatalogData.quantity value, which is fine for the backend
since the NaN will be converted to Null then 0 when fixed in the SOL qty_product
but the product card will display an empty input which is not good.
with this change the productCatalogData.quantity will be fixed to 0, making the input space
(and minus/plus buttons) disapear, which is more logical since the product quantity has
been set to 0
In addition to this it'll prevent a traceback in industry_fsm_sale module where we used
float_round() to fix the product quantity, which doesn't handle Null value
Task-3599491
closesodoo/odoo#142523
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Gabriel de Paula Felix (gdpf)