Add a test for exporting the source terms of modules.
This will allow automated scripts to fetch latest terms
Backport save_test_file with a parameter on date_format to have
predictable filenames
closesodoo/odoo#159373
X-original-commit: e7246ea48828746471a2e3a485bee30687eeee80
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Currently, a logger exception is generated when the user tries to upload
any image as document in the mass mail.
This is because an UnidentifiedImageError occurs when the user uploads
an image file as a document and code [1] tries to open it with Image.
This commit adds code that handles an UnidentifiedImageError, and it adds
the message in the log for an invalid image file.
[1] - https://github.com/odoo/odoo/blob/029b84f3c061f819bacb9a4818504cced4adeb1c/addons/mass_mailing/models/mailing.py#L1405
sentry-4311184876
closesodoo/odoo#159653
X-original-commit: e4b7ec191fc81ec806736758f273e20b6260bbeb
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: ANSARI MAHAMADASIF (maan) <maan@odoo.com>
In 8e3283aa we solved the issue of onboarding progress records
preventing the deletion of a company. We also added a test for this
solution.
In practice, it will not always make sense nor will it be allowed to
delete a company and in some cases, the first thing that would fail
is a foreign key from another model where it wouldn't make sense to
cascade as we do for onboarding progress.
Some modules create related records when a company is created such
that it would be cumbersome to bypass that.
Therefore, we disable this test until a clean flow robust to all
sorts of installed modules configuration is implemented.
See runbot 60475
Task-3829936
closesodoo/odoo#159679
X-original-commit: ea215fe59b45a0c4ff29b4defb38f9ae91a6ca37
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Current behavior:
Brazilian phone numbers are not managed correctly
following the 2016 changes in Brazil.
(Adding a 9 to mobile phone numbers)
Fix:
Patched the phonenumbers library, adding a 9
at the right place for mobile phone numbers.
opw-3694150
closesodoo/odoo#159641
X-original-commit: a4f884456180769e0e7db7152d40ddcfb497b090
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
The method `_get_reward_values_free_shipping` assumes there is only one
delivery line per sale order. But it is not always the case. This commit
therefore makes sure the method does not raise an error in case of
multiple lines by taking into account only the first delivery line.
Fixes#136395closesodoo/odoo#159584
Signed-off-by: Vallaeys Valentin (vava) <vava@odoo.com>
Strings within inline templates are not translatable, so we convert
these templates into standard templates so that they can be.
Task-3761551
closesodoo/odoo#158844
Signed-off-by: Louis Wicket (wil) <wil@odoo.com>
Addresses the issue where reapplying an already applied coupon
in the website shop led to the disappearance of the discount.
With this fix, the discount remains applied, and the system
continues to inform the user that the coupon has already been
used, preventing confusion and maintaining consistency in the
discount application process.
task-3621246
closesodoo/odoo#153485
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Since commit [1], the "tempusdominus" date(time) picker has been
replaced by the OWL date(time) picker. A traceback appears when loading
a website form containing a field dependent on a date(time) field.
This traceback occurs because when checking the value of an empty
date(time) field (which happens when the user hasn't yet filled out the
form), we parse the field value into a Date(Time).
Before the changes in commit [1], we parsed this differently, which
didn't crash but returned "NaN" with an empty date(time) field.
In this commit, we now check whether a date(time) is valid and if not,
we now assign it "NaN" to maintain exactly the same behaviour as before
the commit [1]. Any value other than "NaN" would not work with the date
comparison system and would break certain conditions.
This commit also adds steps to the "website_form_editor" test tour so
that it fails without this commit.
[1]: https://github.com/odoo/odoo/commit/910897fc97d87b08f01627094ec8c159f5267628
task-3790809
closesodoo/odoo#158288
Signed-off-by: Robin Lejeune (role) <role@odoo.com>
Since commit [1], the "tempusdominus" date(time) picker has been
replaced by the OWL date(time) picker. This change resulted in a
modification of the HTML structure for date(time) input fields.
Consequently, a bug emerged in the visibility options for fields reliant
on a date(time) field. Specifically, the time condition selector failed
to display the time conditions because they are rendered based on the
HTML structure of the fields.
Since the code was not adjusted to fit the new structure, this
functionality stopped functioning.
[1]: https://github.com/odoo/odoo/commit/910897fc97d87b08f01627094ec8c159f5267628
task-3790809
Part-of: odoo/odoo#158288
Steps to reproduce:
- Remove all permissions to write/create/delete a view for the user "demo"
- Open a view form with "demo" user
Actual result:
- View code is displayed in plain text and with formatting
Expected result:
- View code is displayed with formatting only
- You can't edit the view or the translations
opw-3776073
closesodoo/odoo#159592
X-original-commit: a1f4e3de224d91e49d5adb2a6385d76c3282d206
Signed-off-by: Rémy Voet (ryv) <ryv@odoo.com>
Signed-off-by: Nicolas Danhier (nda) <nda@odoo.com>
This commit's purpose is to display the correct currency for the hourly
cost of employee in the project sol mapping.
Currently, the currency displayed is the one of the sol instead of the
currency of the employee. This is due to this commit:https://github.com/odoo/odoo/commit/83760b9f10b4bfe6a83671e4426bc5596e8d5f5c
We added a monetary widget, but we are feeding it the wrong id.
After this commit, the correct currency is displayed
closesodoo/odoo#159588
X-original-commit: 8603d628bfc5c7dc620333ad674a1afb7b7123d1
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
1. Fixes an issue where the parent product wasn't correctly set when
computing the routes of a component, leading on components from
subcontracted products displaying the wrong route (as it was trying to
resupply the selected warehouse instead of the subcontracted location).
2. If a route is found when searching for subcontracting routes but
doesn't lead to a way to resupply the stock (either buy buying or
manufacturing something), then ignore the found rules and revert to the
default of trying to resupply the stock location.
This avoids issue when using reordering rules to resupply the
subcontracted location instead, where the 'Buy' route would be hidden
even if it was selected.
closesodoo/odoo#159516
X-original-commit: c7b84a4a602f72c7a67144b7a81b38afe36e0eee
Signed-off-by: Quentin Wolfs (quwo) <quwo@odoo.com>
Signed-off-by: Steve Van Essche <svs@odoo.com>
Before this commit, the custom attribute names were not correctly
displayed when added to an order.
opw-3795843
closesodoo/odoo#158805
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
- Instead of raising an error, we simply exclude sub-tasks of the current
task from the domain of the 'parent task' field
task-3584963
closesodoo/odoo#143282
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Steps to reproduce:
- In 'project sharing' create a task T in project A.
- Add 2 subtasks to task T in project A.
- Share project A in edit mode.
- Access the view form of task T as a portal user.
- Click on the subtask button to navigate to the tree/kanban view of subtasks.
- Select the kanban view.
- Create a new task on the fly, resulting in a traceback.
Issue:
- When a portal user creates a new task on the fly from the subtask kanban view,
a traceback occurs, and the expected behavior of creating a new task Y in
project A is not met. Additionally, task Y should not be a subtask of task T.
Solution:
- Resolve the traceback issue when creating a new task from the subtask kanban
view as a portal user in project sharing.
- Ensure that the new task Y is correctly created in project A and is not
set as a subtask of task T.
task-3584963
Part-of: odoo/odoo#143282
Steps to reproduce:
- Access the 'project.task' module.
- Create a subtask.
- Attempt to save the subtask after adding a project to it.
Issue:
- Saving a subtask becomes impossible when a project is added, causing an
obstruction in the process.
Solution:
- Rectify the functionality to enable successful saving of a subtask even after
adding a project, ensuring a seamless process for subtask creation and
association with projects.
task-3584963
Part-of: odoo/odoo#143282
Replace the use of 't-esc' with 't-field' for the payment icon image in
the icons list template. The latter, for an image field, provides two
options for rendering the payment icon image: use the PIL library to
obtain the image when given the option 'qweb_img_raw_data', or use a
URL. The former only considers the first option, allowing only image
formats compatible with the PIL library.
closesodoo/odoo#159586
X-original-commit: bc76cca37504b40eac73190363c452f89dca65ed
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
When some clients are upgrading their databates and reconnect their IoT Boxes to the new version of the database, we currently can have an issue where the old iot handlers are not being overwritten, but the new ones are being deleted.
This happens in situations like where we add a new driver distinction in Windows, so its name "SomeDriver.py" becomes "SomeDriver_W.py".
Since we dont delete SomeDriver.py the IoT can have both drivers in such situations, causing conflicts and unwanted behaviors.
The goal here is to delete all the old drivers and interfaces before downloading the new ones to make sure we don't have this issus
task-3729890
closesodoo/odoo#159538
X-original-commit: 53a04406e6563d141b7b2378dc25b29b8a8086d6
Signed-off-by: Quentin Lejeune (qle) <qle@odoo.com>
Wild try to avoid failures on runbot builds (not reproducible locally).
* simplify and split tour steps
* correctly specify check steps as isCheck: true
* make sure python setup is deterministic
* batch template creation to avoid creation of dummy archived variant
* target values for the variant to archive instead of its number in the
list of variants
runbot build error 25046
closesodoo/odoo#159372
X-original-commit: 9906785faf81d3152a94942f8e25827d2234db29
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
In this commit:
==================
Invisible the 'Removal strategy' field when selecting the other
location type except Internal location.
task-3555853
closesodoo/odoo#157888
X-original-commit: f24a77d073d609b03c0ff686f843db10218ad1b7
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
It cannot happen through the default SO form view, but some funny guys
have found other ways to do it, even though it can be quite problematic,
especially if the new pricelist is in another currency.
closesodoo/odoo#157742
Related: odoo/enterprise#58744
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
* Adds text values for the call settings sliders.
* Replaces `onChange` events with `onInput` events so that the values
respect the position of the sliders.
* Debounces some functions to handle the increased amount of calls
due to the swap to the `onInput` listener.
* Changes the default value of `voiceActiveDuration` from `0` to `200`
to match the minimum value of the input.
closesodoo/odoo#151028
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Issue: When using the Fullscreen mode of slides for articles we do run
first the website animations before loading the slide, which will make
the content to stay invisible since we will never actually perform the
animation.
Steps to reproduce:
1. Create a new course with an article content.
2. Add any block (text, image).
3. Add an animation to this piece of block.
4. Go to Fullscreen mode.
Solution:
We manually instantiate and attach the WebsiteAnimate widget to
the wpContainer element to ensure animations are properly initialized
and applied after the slide has loaded, after that we get rid of this
instance after every new slide that load so we avoid having multiple
instances.
opw-3757919
closesodoo/odoo#159445
X-original-commit: 593ca1f36a4a9da753d8361840b07e2445f2d99b
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Signed-off-by: Maruan Aguerdouh Mohtar (magm) <magm@odoo.com>
When using the up/down arrows in an `InputUserValueWidget`, only the
first value is updated but the other ones are lost.
This commit adapts the behavior so that all parts of the composite value
are updated.
When decreasing, parts that have reached zero are set to zero.
Steps to reproduce:
- Drop a "Banner" snippet.
- Select the text block.
- Set the "Border" option to "5 10".
- Press the up or down key.
=> Only the "5" was updated, the "10" was lost.
task-3800288
closesodoo/odoo#159385
Signed-off-by: Robin Lejeune (role) <role@odoo.com>
When specifying a composite value in a `UnitUserValueWidget`, if the
first element is a 0, it is considered inactive and resets to its
default value.
This commit considers composite values that start with a 0 as active.
Steps to reproduce:
- Drop a "Banner" snippet in a page.
- Select the text column.
- Specify "0 10" in the Border.
=> The value was reset to 0.
task-3800288
Part-of: odoo/odoo#159385
Since [1] when `extraClass` was introduced, styles are wrongly applied
if an `extraClass` is defined on a `selectStyle` option, but both the
class and the option modify the same CSS property.
Typically, the "Round Corners" option sets the `border-radius` property
and uses the `rounded` extra class. But that extra class specifies
values for the `border-radius` properties.
Without the class, `applyCSS` determines that the style of some corners
is already `0px` and does therefore not need to be added to the inline
style.
But once the class is added, this is not true anymore - and the `0px`
should have been specified.
This commit avoids this issue by applying the CSS again once the
`extraClass` is added.
It also reverts [2] partially to remove the `extraClass` handling from
within the `applyCSS` function.
Steps to reproduce:
- Drop a "Text - Image" snippet.
- Select the image.
- Set the "Round Corners" to "50 0 0 0".
- Press tab to leave the field.
=> The entered field values was transformed.
[1]: https://github.com/odoo/odoo/commit/bf5b4b69330747af7b09d48e59218b78a29a4b14
[2]: https://github.com/odoo/odoo/commit/d3c3dab8950abc25b29937605091d8ce32305fa4
task-3800288
Part-of: odoo/odoo#159385
Steps to reproduce:
-------------------
- create 2 websites (for one or two companies);
- create 2 jobs;
- publish job A in website 1;
- publish job B in website 2;
- as a public user go to website 1 and apply for job A;
- go to website 2 and try to apply for job B;
Issue:
------
When we encode the email address, we receive the message:
```
You already applied to another position recently. You can continue if it's not a mistake.
```
Cause:
------
We don't take into account the website linked to the job we are applying for.
Solution:
---------
Incorporate the website into the domain for application search.
opw-3798670
closesodoo/odoo#159263
Signed-off-by: Bertrand Dossogne (bedo) <bedo@odoo.com>
**Current behavior:**
If a recurring sale order has an associated sale order option
and the recurring plan of the order is changed, a trace back
occurs.
**Expected behavior:**
The recurring plan can be changed as it ordinarily would.
**Steps to reproduce:**
1. Add a recurring product to a sale order
2. Add an optional recurring product to the order
3. Try to change the recurring plan of the order to encounter
the trace back
**Cause of the issue:**
This flow causes some 'phantom' sale order lines to have their
price recalculated (phantom because they have no price, qty,
currency, nor order_id field values). During this recalculation
a currency_id is expected either in the line itself or in the
sale order it is a part of. Because there is no value for either
of these, it fails the ensure_one() method in the sequence
(0 vals, expects 1).
The phantom lines are created in the `sale.order.option` model
in the `sale_management` module, in `_compute_price_unit()` and
`_compute_discount()`.
**Fix:**
Call `invalidate_recorset(flush=False)` on these cached records
at the end of the methods in which they are created.
opw-3754297
closesodoo/odoo#158950
X-original-commit: 16f51c93d0f9cadcdbcd9ed2d58e43ed0d550bf9
Related: odoo/enterprise#59301
Signed-off-by: Vincent Ethan <etvi@odoo.com>
Signed-off-by: Arnaud Joset (arj) <arj@odoo.com>
Currently, an exception is generated when the user tries to access embed view
of slides by following the steps:
- Install "eLearning" with a demo data
- Open external embed view of slide 1 by "/slides/embed_external/1" in url
Error:
`AttributeError: 'slide.channel' object has no attribute 'website_share_url'`
This error is because commit [1] added code that tries to access the
'website_share_url' field in the 'slide.channel' model in template
'embed_slide' , but it actually belongs to 'slide.slide'.
This commit resolved the above issue by accessing "website_share_url"
with "slide" instead of "slide.channel".
[1]-https://github.com/odoo/odoo/commit/db63c03af9932ae4d9b786620e88e62ce938589a
sentry-5095823727
closesodoo/odoo#159513
X-original-commit: e2e868cca86f09e4e71d47837432884e886a42c6
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: ANSARI MAHAMADASIF (maan) <maan@odoo.com>
Description:
On a database with heavy activity, it is possible for the payload
size we pass for the `NOTIFY` query on the bus to be larger than what
PostgreSQL allows by default, 8000 B. This limit is defined as:
https://github.com/postgres/postgres/blob/6686e9676c8faff4ee04c1574e117ae38f117efa/src/backend/commands/async.c#L158-L166
and it is used to compare the size of the payload before processing:
https://github.com/postgres/postgres/blob/6686e9676c8faff4ee04c1574e117ae38f117efa/src/backend/commands/async.c#L654-L657
Fix:
- Binary split the payload into multiple chunks if it's exceeding
the above-mentioned limit. The unit of splitting is a channel, so
if the content of one channel itself is larger than said limit, it
is not handled, but shouldn't occur under normal circumstances.
- Introduce also a new ENV variable `ODOO_NOTIFY_PAYLOAD_MAX_LENGTH`
to allow tweaking of the limit if they are running a handrolled
custom PostgreSQL cluster.
Reference:
opw-3650618
closesodoo/odoo#159469
X-original-commit: 61c7bba44990522d853bae25aa7899cb03c72e31
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Signed-off-by: Piryns Victor (pivi) <pivi@odoo.com>
[This commit] fixed an issue with the menu cache. Unfortunately, during
the forward port, we missed updating the cache key according to what has
been done in [this other commit]. This commit updates the cache key and
improves the test.
Steps to reproduce the bug fixed by this commit:
- Render a website without a record URL in the menu (to the cache)
- Edit the website's menu
- Add a link to a product page (e.g., customizable-desk)
- Add a link to another product (e.g., chair-floor-protection)
- Save the menu
- Click on the menu link to go to customizable-desk
=> At this point, the active menu element is correct
- Click on the menu link to go to chair-floor-protection
=> The active menu element does not update
This issue does not occur if there is a record like URL in the menu
before the first render.
[This commit]: https://github.com/odoo/odoo/commit/970c173530e5523d0e3242ad84dae6fe5e332d68
[this other commit]:https://github.com/odoo/odoo/commit/595aa248433246959a5fa9288e477091701c6a35
opw-3694651
opw-3750925
opw-3781668
closesodoo/odoo#159464
X-original-commit: 9b5647f2951cdd7bde214f860b5ea95d42d2a501
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Guillaume Dieleman (gdi) <gdi@odoo.com>
Currently, on sale orders, you cannot access parent's fiscal positions
from a branch.
Steps to reproduce
-----------------
* install `sale_management`
* set up a company hierarchy. Let's say we have two companies P and C
such that C is a branch of P.
* let's say that P has a fiscal position F
* switch to company C
* attempt to set fiscal position F on a sale order
You will see that F does not appear on the list.
opw-3773335
closesodoo/odoo#159386
X-original-commit: fa419e550497b1291930f9fb8215a719de331024
Signed-off-by: Séna Serge Nshimiyimana (sesn) <sesn@odoo.com>
Before that commit, the search defaults would not be filtered when the
WithSearch is started with a search model state or updated by its parent.
closesodoo/odoo#159406
X-original-commit: dac527b7baa699cef0828a9d87a4c814ff3f7f05
Signed-off-by: Francois Georis (fge) <fge@odoo.com>
Signed-off-by: Mathieu Duckerts-Antoine (dam) <dam@odoo.com>
Issue:
- When adding opportunity/lead to a contact using Studio
and attempt to add a line, we encounter the following error:
"TypeError: 'NewId' object is not iterable."
Steps To Reproduce (in 17.0):
- In a contact form open Studio and add a O2M field
Customer (Lead/Opportunity)
- Try to add a line
- Notice Traceback Error "TypeError: 'NewId' object is not iterable"
Solution:
- The issue arises in the search domain of
`return_if_relevant` , exactly in
("partner_id", "child_of", lead.partner_id.commercial_partner_id.id)
where the type of `lead.partner_id.commercial_partner_id.id`
is NewId since the partner is being edited to add a task.
This action triggers the `parse` and `to_ids` methods with
a value type of NewId. thus the error.
- The operator child_of expects a list of IDs, and the ids
property refer to the record's origin ids. to resolve this,
replace `commercial_partner_id.id` with `commercial_partner_id.ids`.
opw-3760372
closesodoo/odoo#159296
Signed-off-by: Kawtar Drissi El Bouzaidi (kdeb) <kdeb@odoo.com>
Before this commit
==================
Unable to activate the industry from the form view in the industry section.
Additionally, the button in the form for upgrading would be called the
button_immediate_upgrade method, resulting in errors.
After this commit
=================
Activation of the industry from the form view in the industry section is now
possible. Furthermore, the issue with upgrading the industry from the form view
has been resolved.
task-3775729
closesodoo/odoo#157008
Signed-off-by: Pierre Masereel (pim) <pim@odoo.com>
Before this commit:
===================
In coins/bills pop pup, if user adds some coin and removes quantity from any of
the fields (blank space) then it's showing `NAN` and not calculating the other
inputted value which is completely annoying.
After this commit:
==================
If user removes quantity from any of the fields (blank space) then the input
will count `0` in the backend and calculate accordingly.
task - 3728728
closesodoo/odoo#153770
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
The barcode nomenclature allows to define custom prefix for gift cards.
e.g. the default nomenclature in demo data allows both 043 or 044 as
prefix for rule of type coupon.
Therefore the hardcoded string with 044 doesn't allow to sell a gift
card whose barcode does not start with this.
Instead of hardcoding the value, fetch it from the configuration and
the nomenclature that is defined in the settings.
OPW-3499787
closesodoo/odoo#159349
Signed-off-by: David Monnom (moda) <moda@odoo.com>
In c983f8a5 we updated the `test_survey_invite_action` test
to create surveys in batch instead of one by one.
This is problematic because `session_code` (given by utility
method) must be unique for all surveys.
Technically, using 6-digit codes makes it very unlikely that
a collision occurs with existing records (see
Survey._get_default_session_code's iterative process).
Task-3829536
closesodoo/odoo#159295
Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>
When using the "ConditionalVisibility/DeviceVisibility" option for
blocks that are inside a popup, you can end up with an empty popup.
This was has been a limitation of those options for a while, but there
is a real use case for hiding a popup under certain circumstances.
Adapting the options to work on popup was complex enough that it does
not seem suitable for a stable version.
But a simple solution that tries to break as little as possible existing
code could be a huge benefit.
This commit makes it so that if the all children of the .oe_structure
are currently being hidden by ConditionalVisibility selectors or by
DeviceVisibility classes, the popup will not be shown to the visitor.
It will still show if content is being hidden by other means, either
with customizations, or if the content is dynamically generated (like in
the case of a Dynamic Snippet).
This change is done starting saas-16.3 as this is the version the OPW
was opened with, and since this is still a significant change, it will
limit the impacted versions.
opw-3734501
task-3128349
closesodoo/odoo#158303
X-original-commit: 3f5e3c4d49d4c0f67b548d22846e27c5ff8c73f1
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Arthur Detroux (ard) <ard@odoo.com>
Avoid redirect to forum/<name>/question/<post> that will rediret in all
case to /forum/<name>/<post>.
closesodoo/odoo#158148
Signed-off-by: Jérémy Kersten <jke@odoo.com>
- 17.0
Steps to reproduce:
- Open Project app and click on overflow menu of a project
- Select project updates option
- Try and create a new update document
Issue:
- The budget details text is just coming under activities which should be in
profitability section.
Cause:
- Unset priorities of the inherited XML to cause files load before on another
changing the orientation of display order and same Xpath for two inherited
files.
Solution:
- Changing Xpath of one inherited view to accommodate for the order of display
Task-3678808
closesodoo/odoo#149564
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
*: website_sale
This is a follow-up of [1], which missed some occurrence of the same
issue that it fixed.
E.g.
- Add a delay to the "write" of the event model
- Go to /event/<event_id>/community
- Enter edit mode
- Click on the page
- Enable the room creation option
=> The page reloads but nothing seems to have been done... it is
actually *being* done: the page reloaded too soon.
Note: this commit also marks some other occurrences which are not buggy
but might be in the future if not properly changed. To be adapted in the
master forward-port.
[1]: https://github.com/odoo/odoo/commit/556ae457b02e9c077d09fa9c3f9f1e6c6e26b345closesodoo/odoo#159393
X-original-commit: e941363242c918f52222b105de7336e8c830e8db
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Issue: When trying to duplicate courses with the visibility set to
members we won't be able to duplicate it, since when creating the
duplicate course we won't copy the enroll policy and instead we will
apply the default value, 'open' which triggers our validation error.
Steps to reproduce:
1. Install website_slides.
2. Create a new eLearning course.
3. Set the options:
-Show course to: Course Attendees
-Enroll Policy: On Invitation
4. Try to create a copy of this course.
Solution: If we allow the copy of the enroll policy we will make sure
that the new created course has the right parameters to be created.
opw-3749209
closesodoo/odoo#158651
X-original-commit: f17a3d331f877116271e014c5a7b61938311944c
Signed-off-by: Maruan Aguerdouh Mohtar (magm) <magm@odoo.com>
This commit addresses slow performance of the JS `OrderLine.findAttribute` method when `attributes_by_ptal_id` is exceedingly large.
Before this commit, `findAttribute` would loop over all the values of `this.pos.attributes_by_ptal_id`, and filter out only the attributes that have at least one of the passed in ptal IDs (from the `values` parameter) within the attribute's "values" list. It would also modify the attribute to include a `"valuesForOrderLine"` key mapping to a list of all of the found ptal IDs from that attribute's values.
This method becomes slow when `this.pos.attributes_by_ptal_id` is very large. Since it needs to loop over every single attribute.
This commit provides a workaround to this slowness, by caching the search for valid attributes that this method performs in a lookup table.
First, we construct the lookup table in `_processData` method of the `PosStore` class. `_add_ptal_ids_by_ptav_id` does this, by looping over all the values of all the attributes, mapping the ptav ID of the attribute to all the ptal IDs we find.
Now, inside `findAttribute`, we will instead loop over each of the passed in `values`. For each value, we will retrieve the all the cached ptal IDs from `this.pos.ptal_ids_by_ptav_id` for the given value. Now that we have the ptal IDs, we can get all the corresponding attributes from `this.pos.attributes_by_ptal_id`. For each of those attributes, we can do the same modification from the original method by adding the `"valuesForOrderLine"` key/value. Finally we return all the modified attributes.
This new method has a nested for loop, which may seem like a problem. But I believe that both the things being looped over (`values` and `this.pos.ptal_ids_by_ptav_id[value]`) should be very small compared to the potential size of `this.pos.attributes_by_ptal_id`. (43,000 in this customer's DB)
`findAttributes` is called many times whenever the POS's numpad buttons are pressed, so this commit has the overall effect of drastically reducing the input latency for a numpad press.
However, I do believe that this is a workaround, and the real problem is that the entire `attributes_by_ptal_id` is always passed to the POS, regardless of what products are actually being ordered. `attributes_by_ptal_id` should instead be incrementally fetched as products are ordered (if this is possible).
Benchmarks (in customer DB):
Before commit, each keypad press took around 1-3 seconds per Order Line present in the POS. For 11 products this was ~15 second latency.
After commit, each keypad press is almost instant.
The `ptal_ids_by_ptav_id` lookup table will consume additional memory, in this customer's DB I've estimated it to be about 0.3MB more memory. Taking memory snapshots in profiler shows no significant different between versions, however this is inconsistent.
Will attach profiler results to PR.
opw-3788840
closesodoo/odoo#159402
Signed-off-by: David Monnom (moda) <moda@odoo.com>
If the move in the test is created at 23:59:59, and the wizard on
the next day at 00:00:01, the test will fail because the wizard
takes today as the date at creation.
We just add a freeze_time (for this test only, as the other tests
in the class don't have the issue).
Linked to runbot error 60478
closesodoo/odoo#159377
X-original-commit: d064068ff46ef8f84224f50c4c86922ae2004159
Signed-off-by: Cedric Snauwaert <csn@odoo.com>
Signed-off-by: Wala Gauthier (gawa) <gawa@odoo.com>
When the user creates a new ribbon without a background color,
a traceback will appear.
Steps to reproduce the error:
- Install "website_sale"
- Go to Website > eCommerce > Products
- Pick a product > Sales > Create a new ribbon without a background color
- Save & Close
Error: A traceback appears:
"TypeError: argument of type 'bool' is not iterable"
https://github.com/odoo/odoo/blob/806a60d9766e4e04f461a0fb7c824cf5f5c7d5ae/addons/website_sale/models/product_ribbon.py#L24
Here, when the user creates a new ribbon without a background color,
"bg_color" will be False, so when it tries to check "vals['bg_color']".
It will lead to the above traceback.
sentry-5077714703
closesodoo/odoo#158954
X-original-commit: e9021f1332b49042733cf263e8cb62218ccc2965
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Signed-off-by: Renilkumar Kajavadra (reka) <reka@odoo.com>
Martin Trigaux (mat)