Steps to reproduce the bug:
- create 2 warehouses A & B
- create a new product and add a seller
- Create an Automated replenishment order of the created product for warehouse A
- click on “Automate orders”
- open PO
- in “other information” tab > change the picking type to the “warehouse B” picking type
- confirm order
- click on the receipt
Problem:
The destination location is “Warehouse A” instead of “Warehouse B”
The problem also appears after the duplication.
Solution:
Use the parent_path to check if the location that the user wants to use is below the original warehouse.
opw-2588082
closesodoo/odoo#75501
X-original-commit: bed546486aa667d735df015de8153d42a9af9a41
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
Signed-off-by: Djamel Touati <DjamelTouati@users.noreply.github.com>
Co-authored-by: fmdl <florent.mirieu@gmail.com>
When creating from python or toying around with the onchange in the UI, it is possible that the user tries adding values in tax_tags_ids or tax_line_id that are not consistent with the tax_country of the move. The constraint didn't check that, and it should, as those cases are not legit at all and lead to incorrect amounts in the tax report.
closesodoo/odoo#75407
X-original-commit: a63bd4a033dbb8874c07ce0b30984d04a24e7215
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
Before:
Only the channel name was updatable and needed refactoring.
After:
The description can be updated as well and both edition have the same
code flow.
task id 2620687
closesodoo/odoo#74962
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Before this commit editing a link that was saved with fill styles
did reset it to a different value and even changed the 'type' to 'link'.
After this commit re-editing the link works for each style.
task-2629461
closesodoo/odoo#75512
X-original-commit: 4f6cc912260c5b5689b0e87644ad119ef5a1389c
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Benoit Socias (bso) <bso-odoo@users.noreply.github.com>
The "Message a user" command has been removed because a search with
the @ namespace in the command palette does the same thing.
closesodoo/odoo#75526
Task-id: 2622240
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Two methods on sale.order model had the same signature, i.e. _onchange_commitment_date.
This commit renames one of the two methods to make sure both methods are correctly
called.
This commit proposes a mechanism to manually add a frame before a
blocking c-call and triggers it before calling libsaas.compile.
closesodoo/odoo#75519
X-original-commit: f836ff3a67d446cd8b3ab2cf573fab649153e6da
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Sometimes the profiler provides confusing information. This happens
when calling a C library without releasing the GIL (Python's global
interpreter lock). The time spent in the call will be attributed by the
profiler to the former stack trace, because the collector cannot run
during the call.
This commit adds information on the frame when a given stack frame has
lasted for too long.
X-original-commit: 5e193c5dbcdfbdbab38309ed292131ae1f5d3026
With the module sale_product_configurator, you can add optionnal
products on your product to suggest them during the sale process.
We are now displaying them of the info popup of a product to easily find
them in the POS, and we also allow to automatically open this popup for
products having such optionnal products.
closesodoo/odoo#71203
Task-id: 2518884
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
When you are in the backend, you can't easily retreive the infos related
to your products. You have to go back to the backend to check your
stock, get the cost of your products, ...
So we've add a popup that display all those relevent infos of the
choosen product. This popup can be triggered through the small button on
the product or the button info for the selected order line.
TASK-ID: 2518884
Before this commit, the willStart hook was called twice each time a
popup component was opened.
TThe 'PopupControllerMixin' is a mixin that set the listener to the
'show-popup' event and display the required popup when catching it.
Before only the Chrome widget was extending this mixin, and now it is
extended twice, leading to having two listener.
By avoiding to extend the ChromeAdapter with the popup mixin, there
still only one listener, and it is not triggered two times
Issue
-----
Opening the calendar view may lead to an expected singleton error
because _find_attendee my return a recordset with a len > 1
Solution
--------
Return the first element of the filtered list to match the behavior
described in the doc string
closesodoo/odoo#75277
X-original-commit: b3a17e8c233f0b31c61609fefbc24241c3d12ae4
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Signed-off-by: Arnaud Joset <arj-odoo@users.noreply.github.com>
When an option notifies that it was used, its ancestor SnippetEditor
instances were in charge of asking for an UI update of all their options
(see [1] where this was already fixed). This was inconsistent with the
logic of our UI where the value of one option might affect the value and
visibility of another option which comes *after* it, e.g.:
- the user sets a badge type to 'info'
-> the badge background option (below) is shown as blue
- the user adds a shadow
-> more options are shown afterwards to control it (not above)
After this commit, we now update the whole editor panel (parent and
child options) wherever the updates come from. The only important thing
is to first update the options UI then their visibility as their
visibility may depend on their UI status.
This allows at the same time to fix the source of a race condition, as
enabling a snippet also triggers an UI update whose async parts were not
properly awaited (which thus may lead to inconsistencies if the user
clicked everywhere in the DOM too quickly).
[1]: https://github.com/odoo/odoo/commit/7623a0c771495cd41bf40af37c0d2b6e4beb7cdc
Part of https://github.com/odoo/odoo/pull/74959closesodoo/odoo#74959
X-original-commit: 488b9ae45e728327e0d43b91b7c2d6edf2a33be1
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
The editor panel keeps tracks of the SnippetEditor instances which are
enabled at the current time. When previewing one (by hovering its UI),
that tracking was messed up making onFocus and onBlur calls inconsitent.
Part of https://github.com/odoo/odoo/pull/74959
X-original-commit: 0d7e660d8c0941b1af83b08a90d936933287d681
Somehow, trying to forward-port the work done at [1] makes it impossible
for the link popover tour test to pass (although that test already
existed in the version where that original work was merged). It's
unclear why the test did not fail before but hopefully it did here: this
reveals a race condition in the editor code where the link popover is
fully shown to the user while clicking on some of its button would have
no effect... because those rely on clicking in the editor panel which is
potentially not up-to-date yet.
This commit fixes the problem in a hacky way, waiting for the editor
panel to be updated before showing the popover but it should not be
necessary in a better refactored codebase.
[1]: https://github.com/odoo/odoo/pull/74861
Part of https://github.com/odoo/odoo/pull/74959
Steps to reproduce the bug:
- install l10n_cl
- Create two contacts and for only one of the two fill in the "Identification Number" field
- Go to contact app > select both contacts to edit some of their fields at the same time
- For example, edit “City” > save
Problem:
The "Identification Number" of contact 1 is copied to the second contact,
while normally only the "city" field of the two contacts needs to be changed.
This is due to the fact that we do not check in the write function if the vat or identification_type are in values before changing the vat.
Solution:
check that `vat` or `l10n_latam_identification_type_id` are in values before changing the vat
opw-2587994
closesodoo/odoo#75472
X-original-commit: 11ec94df926db98265d26af1072a0c8bf1843083
Signed-off-by: Florian Gilbert <FlorianGilbert@users.noreply.github.com>
- create a new order
- add payment with payment terminal
- close POS
- Open POS
- Send the payment
When the payment succeed it raise. Because after a refresh this.payment_interface is undefined.
closesodoo/odoo#75373
X-original-commit: 3a822fa56f17e7bb5466507ec57588ab255ccdd6
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
PR #42723 changed the public method context_get on res.users return a
frozendict instead of a classic CPython dict.
Since the default XMLRPC Marshaller does not know how to serialize a
frozendict, this would result in errors when calling the method directly
via the XMLRPC layer.
This commit solves this issue by defining a marshalling procedure for
frozendict objects in our custom OdooMarshaller class, this simply
converts the frozendict into a dict and uses the default dict-to-xml
dump procedure (dump_struct).
Fixes#75412closesodoo/odoo#75478
X-original-commit: e80a299ed910cacac4aa4e64164909af36ce62ad
Signed-off-by: Adrian Torres (adt) <adt@odoo.com>
Since a partner of the type private is created when
the partner is created at message post (see _message_post_after_hook),
most of the hr.applicant are linked to a partner_id of type private
And recruitment officer may not have the access to private address,
those user can get an access error while opening a form view of an
hr.applicant due to get_suggested_recipients called.
They are already able to see the email address and the name of the
applicant directly on the applicant form we can consider they should
be able to call get_suggested_recipients
closesodoo/odoo#75454
Solution: read the partner with sudo
X-original-commit: b916e8fd8347e77f2f2e15bf0473a0b3642436f9
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
For some reason _logger.info with exc_info=True inside a recursive
function generates RecursionErrors, presumably because the logger uses
recursion itself to generate the stack trace that is logged.
A simple solution would be to remove exc_info=True, but I've decided to
move the log out of the delete function and simply call it once per
uninstall process with all undeletable IDs, so it's kind of a fix +
optimization.
closesodoo/odoo#75445
X-original-commit: 3a04de569bca10a1d1a01f719635de6842e747b2
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Signed-off-by: Adrian Torres (adt) <adt@odoo.com>
Co-authored-by: Raphael Collet <rco@odoo.com>
Prior to this commit, we queried the project profitability view in order
to have the total amount of timesheeted time.
With this commit, thanks to the fact that this value was only
retrieved in the view by subquerying analytic.account.line we can only
query the analytic.account.line in order to access information.
This allows us to query the project profitability report only when
required. Otherwise, only the analytic account line table is queried.
This commit was motivated by the performance issue fixed in PR : #72641
task-2555323
closesodoo/odoo#71873
Related: odoo/enterprise#18851
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
This commit add various information in views, like name attribute, to
better handle extension.
It improves also the way the FormViewDialog is rendered in the project
right side panel, we no longer have to call willStart at each insertion
of the Form in the DOM since the form is rerendered automatically by
owl once the state changes.
Some click handlers now prevent propagation to ease the addition of
handlers for further needs.
task-2555323
This merge improves event and website_event in various ways:
* set default event_mail_ids on event.event (one registration, two
reminders) as communication is considered as default behavior;
* improve event creation flow on the frontend by adding fields;
* improve customization on website_event;
* remove name_get in event tags to avoid redundancy in tag category tree
view and remove noise;
* improve cover image of an event (Especially to improve the editor UX);
* various display or testing related fixes;
Task-2488019
closesodoo/odoo#68901
Related: odoo/upgrade#2395
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
This commit improves the event creation flow in frontend. Before, you could
only set the name of an event and remaining values had to be set either via
backend or using editor for some fields.
Now you can set the name, start / end date and the address if needed.
Task-2488019
PR odoo/odoo#68901
In editing mode, a weird "List" placeholder is displayed in the nav bar. This
is due to a t-if badly placed in HTML. This is fixed with this commit.
Task-2488019
PR odoo/odoo#68901
Communication on events is considered as standard: receive a confirmation
at subscribe and receive reminders. We therefore set default event mail
on both template and event models
* event.type has default communication with 3 emails;
* event.event has default communication when no event type is chosen. When
a template (event.type) is chosen its configuration is more important;
Task-2488019
PR odoo/odoo#68901
The purpose of this commit is to change the default values of an event cover
image to improve the UX, especially while using the editor.
Task-2488019
PR odoo/odoo#68901
As most customers do not have events across multiple countries it was decided
to deactivate that filter by default and make it opt-in.
Task-2488019
PR odoo/odoo#68901
This commit cleans the display name of event.tags as there is no need
to repeat the category name. It adds noise without any added value.
Task-2488019
PR odoo/odoo#68901
This commit removes the ability to enable/disable the "filter by tags"
on /event. Not need for it to be customizable, it should be displayed
by default. Indeed this is basics of event management and having options
for that adds noise to configuration.
Also, from now on, only published tag categories will be used to sort
events on the frontend, whatever the ACLs.
Task-2488019
PR odoo/odoo#68901
Oversight of odoo/odoo@d9ffbe9e89 a valid template_id was incorrectly converted
into a reference field, used in event automated communication (which is not
the case when sending badge).
Task-2488019
PR odoo/odoo#68901
Before this commit, with some animations (e.g. Bounce In-Left) the
overlay of the animated element or the overlay of selected element
inside it no longer reappeared after the animation.
task-2630112
closesodoo/odoo#75444
X-original-commit: fb98430b1cdbc63896d152b39bcf23c0f2241cb4
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
