"Non-stored fields like product.template.location_id/warehouse_id cannot
be searched" log error is generated because the non-storable fields are
not searchable, so it shows a log error for those fields.
This commit added the blank filter_domain in the above fields to avoid
the log error in search.
This fix is for the "product.product" search view for the
"product.template" search view has already been fixed in
https://github.com/odoo/odoo/commit/a5835a160ea3f7aea37644ed4e1a49e2e4a6effd
sentry-3933983991
closesodoo/odoo#115522
X-original-commit: 92448abfb4d488cc03a14e5cec0ca15c49b8e8e5
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Task: 857
Description of the issue/feature this PR addresses:
The customer's address is added twice in the printed invoice report but it only has to be shown only one time in the printed invoice.
Current behavior before PR:
The customer's address is added twice in the printed invoice report
Desired behavior after PR is merged:
The customer's address is added only one time in the printed invoice report
closesodoo/odoo#114874
X-original-commit: 9a9c6a5ffcf67f67a1a074caa412345a3b71cbe4
Signed-off-by: Josse Colpaert <jco@odoo.com>
Since c857473 the Kanban arch parser do not take into account the root
node class attribute anymore.
This lead to an issue regarding the x2many fields making use of kanban
views.
This commit brings the following changes:
- the kanban and list arch parsers now share the class attribute in
their arch infos.
- the x2many field adds the className from arch infos to its root node.
closesodoo/odoo#115534
X-original-commit: 980244fa8bf2b720527e457f22c4039c450eed5b
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Bruno Boi (boi) <boi@odoo.com>
In the fix introduced in https://github.com/odoo/odoo/pull/114341
we have added a 'position-relative' in the event_track_content
template. As it fixed a quite important issue on screen layout,
we also added a check in the JS to also impact stable instances
not updating their modules.
This commit removes this check in master.
Original task : 3215833
closesodoo/odoo#115515
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
How to reproduce:
- Create a tracked product;
- In the receipt picking type form view, for the lot and serial numbers,
uncheck "Create New" and "Use Existing ones";
- Create a planned receipt for some of this tracked product;
- Confirm and validate the receipt:
It opens the "Immediate Transfer" wizard;
- Apply the immediate transfer:
-> It asks if you want to create a backorder.
Since the picking type doesn't use new or existing LN/SN, it accepts to
be confirmed even if some move lines for tracked product have no
tracking numbers.
The issue was, when a `stock.move` sets its done quantity to its
reserved quantity, if its product is tracked, it doesn't change its done
quantity if it has no tracking number, regardless the picking type's
configuration.
OPW-3186155
closesodoo/odoo#115234
X-original-commit: 89567288e9c134f1262e8ba8b5fc65f730a239cf
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: Steve Van Essche <svs@odoo.com>
When closing a POS session, a journal entry is generated for it. By
default, first we try to create that entry as the logged in user, and if
that fails we try again with sudo.
Suppose you only have the Point of Sale and Accounting apps installed,
and the user has the Auditor role in Accounting. In that case they won't
be able to create account moves. If the user closes a POS session, the
creation of the account move in `_create_account_move` will fail with an
AccessError and the creation will be retried with `sudo` by
`_validate_session`. This works fine.
Now suppose that you have the Purchasing app installed as well. By
default that will give the User role in Purchasing. That role introduces
a restriction on which account move types the user can write to. The
permissions do not include 'entry', which is the move type of the POS
journal entry. If the user again tries to close a POS session, the
creation of the move is able to proceed further, because the role from
Purchasing granted additional rights. The SQL statement inserting the
account move data gets executed inside the transaction. When it
validates the Python constraints afterwards, another AccessError is
raised, because of the rule on `move_type` failing due to the move being
an 'entry'.
If at this point the operation is simply tried again with sudo, the
original database changes inside the transaction will still there, and
will be committed together with the journal entry created with sudo.
This results in an empty draft entry showing up in addition to the POS
journal entry.
To prevent this from happening, the initial attempt is wrapped in a
savepoint so that the transaction gets rolled back fully if the creation
of the account move fails, no matter at which point.
opw-3160140
closesodoo/odoo#115519
X-original-commit: 176ab1db87648198641d0b880d6d2c8ffddf108a
Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>
Signed-off-by: Merel Geens <mege@odoo.com>
The purpose of this key was to force the form view to be in edit
mode directly when opening a record, in specific actions. This is
now automatically the case since form views are always in edit
mode. This commit thus removes the support of the key, and removes
all occurrences where it was set in the codebase.
Part of task 3179751
closesodoo/odoo#115172
Related: odoo/enterprise#38130
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit, the "Your contact" details in the portal
layout were not shown if the user_id (salesperson) was not set
on the portal user's partner.
In order for them to have contact info in that case, we now use
as a fallback contact the one responsible of their company, i.e.
the first company in the parent hierarchy (corresponding to the
commercial_partner_id field).
We still do not use the user if it they are a public user.
Task-3213421
closesodoo/odoo#114599
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Fix a forgotten field after a renaming after a forward conflict:
[REF] *{stock,mrp}*: rename reserved fields
This commit rename product_uom_qty into reserved_uom_qty and product_qty
into reserved_qty on stock move line to stop mistake them with the stock
move quantities fields.
Task: 2648449
Part-of: #80434
opw-3225854
closesodoo/odoo#115501
X-original-commit: 022de9edabb9993bfab6dd4e45feed788b7e1c38
Signed-off-by: Tiffany Chang <tic@odoo.com>
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Before 16.0 and the "always edit" form views, some fields allowed to
be edited in readonly (e.g. the statusbar in crm lead or project
task). Users could thus change the stage of a record in readonly and
the change was saved directly. If the field was tracked, the change
was even logged in the chatter directly. Since the form view is always
in edition now, we loose that behavior and the user must click on the
save cloud icon to manually save and see the tracking messages. To
mitigate this, those fields that were editable in readonly could save
the record directly when edited, like buttons do.
Changing the values of the following fields should automatically save
the record.
- BooleanToggleField
- PriorityField
- StateSelectionField
- StatusBarField
To accomplish this, we now unconditionally save the record when the above
mentioned fields are changed.
closesodoo/odoo#115500
Task-id: 3175672
X-original-commit: c9b7c43c69eaf87e7900801b926d3868adc36d8c
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Before this commit:
In mobile view, when text as well as link is in range the unlink button
in the toolbar was visible.
After this commit:
The unlink button is only displayed when link is in range
Task-3184393
closesodoo/odoo#115161
X-original-commit: 5cab1c90b13074e642f3da3a773c55d37419f90b
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
In mail, changing the setting "Restrict mail templates edition and
QWEB placeholders usage" to false should remove all users but admins
from the group, including the template user.
Before this commit, you could have weird behaviou such as
1. Disable the restrictiong (group_mail_template_editor in
group_user.implied_ids)
2. Install mass_mailing (group_mail_template_editor in
group_mass_mailing_user.implied_ids)
3. Create a user test with minimum employee roles (still has
group_mail_template_editor as employee)
4. Check the box "Restrict mail templates edition and QWEB
placeholders usage"
-> test still has the template group nothing implied it
The issue was a combinaison of recomputation of implied groups
https://github.com/odoo/odoo/blob/b2f760cae74201d1622e56a0027dae67dcff9e33/odoo/addons/base/models/res_users.py#L1292-L1295
that triggered the synchronisation of groups on template user
https://github.com/odoo/odoo/blob/b2f760cae74201d1622e56a0027dae67dcff9e33/odoo/addons/base/models/res_users.py#L611-L616
By removing the users already in a group, we avoid falling into the
condition added at 121cd0d608 where the default user gets a
group removed, readded, hence added for everybody.
closesodoo/odoo#115108
X-original-commit: 6398dd287f07641c85807f291d9fe078fcb8a231
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Purpose
=======
When having long choices in the question form, prevent
the "Upload your file" button from being cropped by applying
a fixed width to the image column.
Task-3215473
closesodoo/odoo#115481
X-original-commit: eb0f2b27cf9c8af1c5c77f0736e430b793e54b2d
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
By default, clicking on links in a contentEditable context does not open
the link because it would make it hard to edit it otherwise.
This is a problem now that the views are always in edit mode because it
means the user cannot quickly and easily click on links to open them.
This commit aims to solve this conundrum by finding a middle-ground
between these two use cases, that is reintroducing the oh-so loved
Ctrl+Click behavior that was commonly used in previous versions.
This required two changes:
1. Explicitely implementing the behavior of opening the link in a new
tab in that case since it is not the native behavior in a
contentEditable context.
2. Giving special treatment to links inside a contentEditable context in
the `globalClick` listener introduced at [1] such that the event can
actually reach the custom handler in the editor.
task-id 3188438
[1]: https://github.com/odoo/odoo/commit/47acba560a8954f10bfa97b28daf90047005fdf1#diff-ce4923ebad38db28d4fc17267c93d147c4404feefd42eb140ef990bddbe1a9ffR93closesodoo/odoo#115428
X-original-commit: 8bd6b28f7915d7d84ff42722e5cb4b6f798cb81d
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Stpes to reproduce the bug:
- Create a storable product “P1” with 2 variants:
- Color: Red and blue in this order
- Create a BoM for each variant
- Create a SO:
- select the product “P1 - blue” → the second variant
- Click on the forecast button → manufacturing forecast
Problem:
The BoM overview is showing the wrong product variation because it pulls
the default BoM of the base product (always the first variant from the
list)
opw-3166074
closesodoo/odoo#115421
X-original-commit: 873d6d921c3955b707d10826a898ae405f296531
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
Signing CLA to be able to merge other pull requests.
closesodoo/odoo#115470
X-original-commit: def64958c3c67d889df4caf4709004f77575ddf5
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
In some cases name and email are NULL in survey.user_input so it's
return False and can't change the case of the boolean value.
So here add the blank string if name and email is not set.
sentry-3951409506
closesodoo/odoo#115455
X-original-commit: 68b5ab4f2936a02fe8245b887bf402abd4fd2997
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Before this fix, the 'hide_sponsors' value was used to hide the
row of sponsors in several views:
- page of all exhibitors
- page of single exhibitor
- if website_event_track is installed -> registration confirmation
But actually it did not do anything anymore, because the old
selector used to apply the display none !important was hard-coded
to the previous code structure. This is very unstable, and structure
changed first in 35f70e5f11
Also, o_wevent_sponsor_wrapper selector was not used anywhere.
FIX:
Use o_wevent_sponsor_wrapper to not depend of structure anymore.
'hide_sponsors' adds o_wevent_hide_sponsors on the view and the
sponsors bar will be hidden, as expected.
Task-3213873
closesodoo/odoo#115453
X-original-commit: 13778a454b10aa40fae3cc0e3b7fcbd9e8781ce1
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Commit https://github.com/odoo/odoo/commit/22baab2d0ec2c076a4c769f6c594062c0cea5f90 introduced changes to make sure that
footer is not visibly moving when user moved from course to rating tab
on website slides. However, that issue was already solved in the same
commit, with style changes on o_wslides_course_main. Thus, we were left
with big empty space underneath comments section on not only website slides,
but also on any other place where comments section(portal.chatter_messages)
was present.
This commit removes redundant code in order to correct style in pages where
comments section is present.
Task-3203106
closesodoo/odoo#115431
X-original-commit: a58123c1faf888c561e41fd5716be25a44973d6c
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Issue introduced in https://github.com/odoo/odoo/pull/95450
After migrating to 5.1.3 Bootstrap, the col-12 element no
longer had implicit position-relative attribute, meaning that
o_wesession_track_main div was no longer position-relative.
Therefore, children position-absolute elements for loading
and track suggestion at the start / end of the video became
absolute to the window instead, and format failed to match
the video frame anymore, as it should have.
-> FIX : add manually the position-relative back on the live
track container element (see o_wevent_event_track_live).
We also add JS check to make sure we add position-relative
even if templates are not updated in stable, as the screen
is very disturbed otherwise.
Task-3215833
closesodoo/odoo#115430
X-original-commit: 643cdc649bf14d51528e9502266bfbcd62576b6e
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Fix the isuue that manual consumption is not correctly calculated when
backorder/split/merge.
closesodoo/odoo#115429
X-original-commit: d72ddd80d8a6aaa808c07db685972a1c05e8d6a4
Signed-off-by: Tiffany Chang <tic@odoo.com>
Signed-off-by: Yuchen Huang (yhu) <yhu@odoo.com>
Purpose
=======
Change the current alert banner closing icons
(a "x" in a gray box) by the new good-looking
bootstrap 5 closing button.
Task-3222588
closesodoo/odoo#115424
X-original-commit: 6f83f60f2f0d031c15df5c3b450fb583feaea3b9
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Since #104062, the uom field on a scrap order is still editable when it is in the done state. This behaviour is now fixed.
Community PR: https://github.com/odoo/odoo/pull/115288closesodoo/odoo#115399
X-original-commit: 5785d19c749fb1456bf1079d07e83e401850b330
Signed-off-by: Tiffany Chang <tic@odoo.com>
In the profit and loss report, if you go to "Analytic Group By" and select
'Search More' (need more than 7 plans), there is a traceback because
"True" is not a valid JSON.
This PR fixes this by changing "True" by "1" like other occurrences
of multi_edit parameter.
opw-3222611
closesodoo/odoo#115422
X-original-commit: 687a166e8c089a650c99eefe9d604c8c2762e1b7
Signed-off-by: John Laterre (jol) <jol@odoo.com>
Signed-off-by: Beckers Thomas (tbs) <tbs@odoo.com>
This commit aims at preventing the deactivation of a company currency.
Was the issue on 2852452 support ticket (v14). But it seems appropriate to merge it in 13.0 as it is probably a good idea that a company currency always stays active.
How to reproduce bug:
In 13.0:
Install accounting with demo data > activate multi currency in settings > deactivate usd > create new invoice > select eur currency > cannot set usd currency back on invoice
Reconcile JS traceback in 14.0:
Install accounting with demo data > activate multi currency in settings > deactivate usd > go to accounting dashboard > click on reconcile 7 items on Bank journal > click on any “customer/vendor matching” line.
closesodoo/odoo#115444
Task: 2852452
X-original-commit: 09cb57446d99a48651cbfeeb5405029bc2d77226
Related: odoo/enterprise#38255
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
Signed-off-by: de Wouters de Bouchout Jean-Benoît (jbw) <jbw@odoo.com>
When a company is created during the odoo installation, depending on the installation parameters, importing "res_company_data.xml" before "res_currency_data.xml" can prevent the activation of the company currency.
E.g. a fresh odoo install with account_accountant and no demo data will have 0 active currencies.
X-original-commit: f9247a276b71e9d09bb03c85dc93b36c53703e60
Part-of: odoo/odoo#115444
To Reproduce
============
- go to employees app and filter by `Absent is Yes` then by `Absent is No`
some employees are present in both filters which is not logical
Problem
=======
the search method on `is_absent` field always performs the search `ids in absent_ids` no matter what are the operator and the value
Solution
========
use the `operator` argument in the searching
opw-3205967
closesodoo/odoo#115443
X-original-commit: 89a762ec463efd936c5d60a483f3cac876724b7e
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Signed-off-by: abla001 <abla@odoo.com>
At the moment translations are only available if a user chooses es_CO specifically. This commit changes it to es, making it available regardless of which Spanish version is chosen by the user.
task-3230384
closesodoo/odoo#115462
X-original-commit: 33b96bce49ea7e0173faf4dc20312dcbe5657634
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Aliya Tastemirova (alta) <alta@odoo.com>
before this commit, the pivot view of hr.work.entry model
is not showing the details by default.
after this commit, the pivot view will be expanded by
employee and work entry type and duration is added
as measure for the pivot view.
closesodoo/odoo#115303
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Before this commit, when toggling the codeview in mass_mailing (debug=1),
the overlay that highlights the selected snippet is not deactivated.
This results on the blue rectangle being seen on the codeview when the mouse
cursor is hovered over the corresponding position.
This commit deactivates the current snippet overlay when the codeview is
toggled.
closesodoo/odoo#115299
X-original-commit: ec8070adb38d092d743679c2dd30872424d46e9d
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
When the selection is outside the editable and the `autohideToolbar`
option is false, `_updateToolbar` will perform computations in order to
update a toolbar that is not visible.
In fact, trying to do so can lead to a traceback, as `getComputedStyle`
is called with a null argument when the selection is not contained in
the editable.
This commit avoids such useless computations and tracebacks by returning
from the function when the selection is not inside the editable element.
task-3171892
opw-3161789
X-original-commit: d4b13a147f2a69628c050a04655452fcb2e6d759
Part-of: odoo/odoo#115299
Every imported vendor bill now will have the chance to make its invoice_origin linked to a Purchase Order.
The function is moved from account_journal to account_edi_format to allow the link being done from all webservices, thread attachments and upload.
- Avoid mocking the proxy testing
The test on the check that the same attachment is coming twice from the proxy doesn't actually need to test the proxy. By splitting the function, we avoid mocking the proxy for no added value. Added an ir.rule for companies to only look for their account_edi_proxy_client.users
- PA Index label should be Destination Code
PA Index is a completely wrong description. This is the destination "address" of the partner at which our EDI documents (invoices) should be directed to inside the SdI e-invoicing system, much like an IP address. It's not an index, doesn't have much to share with the Public Administration. The correct literal translation of the name should be "Destination Code"
for Codice Destinatario. We have clients opening tickets because they don't recognize this field on the partner form because of the wrong translation.
- Fixes on taxes import
Lines didn't have their taxes cleared, so invoices actually added the taxes in the XML to the default supplier taxes of the product VAT taxes on import search was conflicting with actual withholding / pension fund taxes, so extra conditions are added in the search if withholding / pension fund fields are not specified
Task link: https://www.odoo.com/web#id=3175353&model=project.task
Task-3175353
closes odoo/odoo#114870
Forward-port-of: #111365
Signed-off-by: Josse Colpaert <jco@odoo.com>
Current behavior:
The rescue session are created with a starting balance of 0.00. When the
starting balance should be the end balance of the previous session.
Steps to reproduce:
- Open a POS session on 2 different browsers
- Make an order on the first browser, and close the session
- Make an order on the second browser, and close the session
- The second browser's session will be in rescue mode and the starting
balance will be 0.00 when it should be the end balance of the first
session.
opw-3136236
closesodoo/odoo#115258
X-original-commit: 265817f7d7d096be4a84a7dd710c1dabb93fe402
Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>
Signed-off-by: Engels Robin (roen) <roen@odoo.com>
* The tours are now run by the `MacroEngine` defined in `macro.js`.
* This is accomplished by converting (at runtime) the user-defined tours to
`Macro`s. See `tour_compilers.js` for the step (and tour-to-macro) compilation.
* API is kept the same as much as possible. Basically, declaring tours stayed
the same with some exceptions:
* `allowInvisible` can be provided in a step to allow consuming the trigger
element even if it is invisible.
* `isCheck` can now be used to replace the no operation `run` that is
traditionally signals the runner to only perform a check.
* Before, multiple `run`s can be called simultaneously. Now, each `run` method
is awaited before proceeding to the next step.
* If the trigger element is `disabled`, the tour runner will *not* proceed on
calling the `run` method and the runner will stay on current step until the
trigger element becomes `enabled`.
* However, the tour runner is okay with `disabled` trigger element if the step
has `isCheck = true`. As long as the trigger element is found for `isCheck`
step, the tour runner will happily move to the next step.
* Some tours are adjusted to properly run with this new tour runner.
* When the tour failed:
* The dom string is not logged anymore.
* However, a warning message containing the relative location of the step will
be logged. This is better in helping the author in locating the failed step.
**Some guidelines learned during the development:**
* Each step may trigger a dom mutation. It's a good practice to insert an
intermediate step that *checks* the existence of an element that result from
the action of the previous step.
* Refrain from using the `run` method for assertions. `run`, in principle, is
provided to perform actions that are not offered by the helper. Use the
`trigger` for assertions.
* During dev, find `SHOW_POINTER_DURATION` and set it to `250`. This will show
the pointer (pointing to the trigger element) for 250ms when watching the
tour.
closesodoo/odoo#107618
Task-id: 3082036
Related: odoo/enterprise#37560
Signed-off-by: Géry Debongnie <ged@odoo.com>
Co-authored-by: Julien Mougenot <jum@odoo.com>
Steps to reproduce:
- Install Sales modules (for test purpose)
- Open any quotation
- Click on "Send by Email" button
- Download the attachment (in the bottom of the modal)
- Try to add an other partner to recipients
Issue:
Chrome: The partner is not added (visualy) to the recipients.
Firefox: After downloading the attachment, the page is stuck on
"Loading...".
Cause:
When downloading the attachment, since it's a link, the browser
think at first that we are going to change the page, and therefore
trigger the "beforeunload" event.
Doing so will call the `urgentSave` method that will set the
`_urgentSave` attribute to true, and then notify to render.
When we try to add a partner to the recipients, since the
`_urgentSave` attribute is set to true, it will not trigger the
rendering of the view.
Solution:
Add `download` attribute to the links, so the browser will open the
attachment in a new tab, and therefore will not trigger the
"beforeunload" event.
opw-3176996
closesodoo/odoo#115205
X-original-commit: a6d3fb842c4bb2adc2bab5d65c12ceca352ea2cb
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Nasreddin Boulif (bon) <bon@odoo.com>
To reproduce the problem:
- ensures python-magic is not installed. It is used to guess the mime type of
a file. The code uses an alternate solution if not present and this is that
alternate version that's unable to guess the mime type of an xlsx file.
- in website_slides, open a course
- open a content
- go to the "Additional Resources" tab
- add an xlsx file
- remove the extension of the file in the name
- open the public website and open that content
- click on the link of the file you just have added
- instead of a xlsx, you get a zip file
This fix solves the problem by using the extension of the file uploaded if it
is valid.
Technical note: prior version 16, the mime type stored in the attachment was
used to determine the extension of the file when downloading it. From version
16, if the extension is missing in the file name, the system tries to guess it
using python-magic if installed and a custom implementation if not:
_odoo_guess_mimetype. The custom implementation doesn't support the detection
of xlsx files (and other formats) while python-magic supports it. That's why
the problem described above only appends while python-magic is not installed.
To solve the problem we have added in the download URL the file name as the
the name of the resource with the extension of the file name uploaded
(extension not added if the name had already the same extension as the file
name).
Task-3200998
closesodoo/odoo#115273
X-original-commit: 3a7388a69991d968c349133be4ac52745bbac65b
Signed-off-by: Stéphane Debauche (std) <std@odoo.com>
Steps:
- install hr_timehseet module
- Share any project
- Go to the portal and open the project.
Issue:
currently,timesheet_uom service is not added in project webclient so
service not found.
Fix:
In this commit, we have added timesheet_uom services in project webclient.
closesodoo/odoo#115271
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
In odoo/odoo#112978, it missed the case when 0 is entered (and no
Counted Quantity already set).
On inventory adjustments, when Counted Quantity is 0 and then press
"enter" or "tab", the difference will always set to 0. The compute
function for inventory_diff_quantity is not triggered in this
situation. We manually update the value in this case to trigger the
compute function.
opw-3177578
closesodoo/odoo#115252
X-original-commit: b4b90ff5702d18cc17d74d04e12e3cf11e205e9f
Signed-off-by: Tiffany Chang <tic@odoo.com>
Steps to reproduce:
- Install Discuss and Livechat.
- Open a window without logging in and trigger the Livechat.
- Select the "I have a pricing question" option, and it should tell you
that there are no operators availables.
- When it asks you for your email just type anything, and try to close
the window.
- When you have pressed on the "x" it should ask you to review the
service you had, select any of it and close the window.
- Now log into the database and go to the livechat app and go to the
livechat channel where we did the review, and inside it try to "Go to
Website".
Issue:
Traceback will be raised, caused of the review we have done which is not
asigned to anyone in the support team.
Solution:
When can handle this, and just still take into account the review we
just had (current fix). Or we should not let the user to review if we
don't have an agent to be reviewed.
opw-3143564
closesodoo/odoo#115242
X-original-commit: edc20c1d12225df9a5e169bf13abfb5a796f5236
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Steps to reproduce:
1. Install module Project
2. Enable Sub-Task feature in settings
3. Create a project A and add a task with subtasks with depth level >1.
4. Duplicate project A
Issue:
Duplicated child subtasks (depth >1) are not being mapped with the newly created project(duplicated one).
Cause:
Only mapping parent task due to wrong filter values.
Solution:
If the `display_project_id` of all tasks to duplicate (subtasks
included) are linked to the project to duplicate, then the
'display_project_id' of duplicated tasks for those tasks will be
the newly created project on all child subtasks record sets.
closesodoo/odoo#115261
X-original-commit: 31a966a9a97c28c36b819e7481809f2cf4565fb5
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
When upgrading a database with `l10n_multilang` installed, the
translations kept were not the right ones.
Here is the process that was executed during the upgrade:
* `base` is loaded: registry is loaded with `translate=True`, which
calls `convert_column_translatable`. This has the effect of setting
the value of the field to `{'en_US': name}`, with only that language
installed.
* `l10n_multilang` is loaded: the function `lang_install` is extended to
copy the translations of the templates on the instanciated records.
* `l10n_*` is loaded: the translation values are loaded from the `.po`
files. `lang_install` is called after the loading on the templates,
copying the value on the records. The value on the records is now
something like `{'en_US': name, 'fr_BE': nom, 'nl_BE': naam}`.
* `base/end-migrate` is executed: it copies the values coming from
`ir_translation`, without overriding the values that are already on
the record because of the order of the `||` operator.
This means that any value inputed by the user[^1] will be overriden by
the value in the `.po` files.
opw-3175383
closesodoo/odoo#115254
X-original-commit: 5d46cdee878d752b9a61a74762a8710be0890e9d
Signed-off-by: Christophe Simonis <chs@odoo.com>
Co-authored-by: william-andre <wan@odoo.com>
Co-authored-by: HydrionBurst <cwg@odoo.com>
1. Install [Events]
2. On [Settings], create an admin for Events (uncheck all other rights)
3. Click on Events, enter an event
3. Click on [Communication] tab, and try adding a line
Issue: accessing ir.model is blocked
Solution: Find another way
Impacted versions: 15 - master
opw-3163138, 3103199, 3193659
closesodoo/odoo#115237
X-original-commit: db37a4e230f8cd6ac916fe3a21aea5ff43c61d53
Related: odoo/enterprise#38169
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Lee, Hansun (hale) <hale@odoo.com>
The `afternextrender` helper is meant to be used in some tests that
want to do something after owl has completed all its work following
a specific action. It is useful when the action may cause some
additional renders, so waiting for one nextTick is not enough.
Unfortunately, it has a bug: it waits for Owl scheduler to be empty. But
in some cases, when a component is destroyed because of an error,
the scheduler task list will not be cleared until the next render
completes. It is implemented that way in Owl to reduce the amount of
work it does. But this means that in some testing scenarios, the
afterNextRender promise will simply not be resolved, since there is no
upcoming render to clear the tasklist.
With this commit, we just avoid the issue by ignoring the fibers coming
from destroyed component.
Note that I think that it is not a good semantic for tests, as it is a
little bit too "black-boxy". Ideally, we should rather wait for something
in the DOM. There is a waitUntil helper somewhere that may be useful for
this situation
closesodoo/odoo#115229
X-original-commit: ca8d1e7ea74120dd088c78bb4916aa994e852a0f
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Géry Debongnie <ged@odoo.com>
Mahamadasif Ansari