If we had a product as an option to multiple products and we want to stop selling it we'll set sale_ok to `False`. We won't be able to add it to the sale lines but it will keep showing up in the products options popup and we'll be able to add it to the order that way. It must be prevented to keep a coherent behavior.
Description of the issue/feature this PR addresses:
- Add a product as optional product A to several products (B, C, D).
- Set that product to `sale_ok` = False
- Create a sale order
Current behavior before PR:
- Product A can't be selected from the order lines (👍 )
- Add either product B, C or D and the optional products popup shows up allowing us to add Product A to the sale lines.
Desired behavior after PR is merged:
When a product is discarded from sale, we should not be able to add it as an option. Removing it as option in the affected product is not a proper workflow, as the product could be simply temporarily out of sale due to multiple commercial reasons.
cc @Tecnativa TT36178
--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
closesodoo/odoo#90708
Forward-port-of: odoo/odoo#90593
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Current behavior:
When selling a product in PoS that is tracked by lot number and using
the options to shop it latter and 3 steps delivery.
The move lines associted to the different pickings would have wrong
quantity reserved
Steps to reproduce:
- Activate multi-step routes and Lot/SN in inventory
- Operation types Pos Orders tracability check marked
- Activate Ship later options in PoS
- Set 3 steps delivery in the warehouse settings
- Create an item tracked by lot number and set a quantity
- Open POS session
- Select created item
- Do NOT input a lot number
- Set quantity to 1
- Proceed to payment screen
- Select "Ship Later" on the payment screen.
- Finish Sale.
- Close POS session.
- View the picking orders of the session.
- Select the picking order that is "Ready".
- The reserved quanities in the pickings are not correct
opw-2779462
closesodoo/odoo#90699
X-original-commit: b18710a20eb4b1fc0de79c82c885a677b84a7a70
Signed-off-by: Masereel Pierre <pim@odoo.com>
This commit introduces models that define records being 1:1 map with components,
as a step to move further to having essentially all business code in models.
Having code in models is desirable to have very maintainable code, thanks to
robust and declarative code with an ORM-like architecture.
Task-2831082
closesodoo/odoo#90635
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Since #83550, the sale.report model is not a stored SQL view anymore,
but a query generated depending on the context, to show the amounts in
the currency of the current company.
Therefore, the table sale_report does not exist anymore in database, which led
to a traceback when opening the crm.team view in sale (Sales/Orders/Sales Team).
This commit makes sure that the graph content correctly uses the contextual query
instead of trying to read the sale_report table.
closesodoo/odoo#90602
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Now that the method is deprecated, we think it's better to
keep showing it in the doc, but with a clear deprecation notice
in the docstring (instead of hiding it).
closesodoo/odoo#90634
Related: odoo/documentation#1908
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Reproduction:
1. Select an event, then set a certain maximum amount sold on a paid
ticket, set as 2 for simplicity
2. Go to the Event webpage, then buy all paid tickets
3. Fill out information and attempt to confirm the order
4. The shopping cart is cleared
Reason: We check the event ticket availability in function
_cart_update(). In V14 and V15, we added a new step to update the
pricelist when confirming an order, which will trigger _cart_update().
In V13 update_pricelist is False by default. In V14 and V15, it is
always set to True. The change is to make sure the pricelist is not
changed once the customer chooses the pricelist. As a result, for each
SO, it checks the ticket availability twice. First at when click
register or check out. Second at when submit the address information.
When selling the last ticket, the second check fails and leads to an
empty cart because the seats_reaserved is updated already at the first
step
Fix: add new checking conditions increased_quantity = new_qty > old_qty
to function _cart_update. We only check the availability again when
these new conditions are satisfied.
Current issue: This fix will restore the normal workflow for the last
ticket. But the workflow has its original issue, e.g. it doesn’t update
seats_reserved when increasing the number of tickets.
A solution in SaaS-15.3 is to forbid the customer to manually raise the
event ticket amount
For example:
1. Register 1 ticket, fill in the attendee form and click continue
2. Click review order, increase the number of tickets, then continue
3. The seats_reserved is not updated (can refresh the event page,
seats_reserved is the column confirmed)
If first register 2 tickets and then change to 1, seats_reserved will
change from 2 to 1
This is because seats_reserved is computed from the number of
registration. No new registration is needed when increase the ticket
number, but the registration will decrease when decrease the ticket
number. A solution for it is popping new registration form when the
ticket registration increases.
opw-2784720
closesodoo/odoo#90648
X-original-commit: 8e7867371c66fb7500f13157ada84aadad1d46d6
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Liu Jinjiu (jili) <jili@odoo.com>
The route used by the sale portal to update an option qty didn't check that
the modified SOline was effectively an option.
On the portal, only the optional lines were editable through the interface,
but through xmlrpc, a portal user could be able to remove/update the qty
of non optional lines from a quotation.
This is not a true security failure since only the quantity could be modified
through this route, but it makes sense to add a check to ensure this kind
of modification cannot happen.
closesodoo/odoo#88366
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
On the portal, if you 'spamclick' to reduce the quantity of an optional
line on the portal, when the quantity hits 0, the line is removed, but
you might receive a MissingError saying the record doesn't exist anymore
(if you clicked more times than the qty of the optional line).
To avoid showing this error to the customer, we check the existence of
the option before trying to read its content (and checking it belongs to
the right order).
Part-of: odoo/odoo#88366
Currently, when the quantity of an optional SOline is modified on the
portal, only the quantity and order/line amounts are updated.
This raises two problematic situations when the pricelist is
configured to give discount when a certain number of products is
reached:
1) If the pricelist is configured to include the discount in the price,
the price is not refreshed, which means you see a line total which is
not the result of unit price * qty
2) If the pricelist is configured to show the discount, you won't see
it even if there is one (and you won't see the column if there was
no discount in the SO before your qty modification).
This commit makes sure the order details are refreshed when the quantity
of an option is modified. To do so, we simply need to use the previous
code used to refresh the content when an option was added to the order.
Since we now do a full refresh of the order details whenever the quantity
is updated, the old code updating part of the order details (qty & amounts)
is unnecessary and can be safely removed.
While this code & logic is modified, a cleanup & some documentation of
the code was also made.
task-2180180
Part-of: odoo/odoo#88366
Co-authored-by: Victor Feyens <vfe@odoo.com>
When an activity is created with a very long description, the avatar of the
user is squeezed.
Step to reproduce the issue:
1. Install the Sale module
2. Create an activity (e.g.: a To Do) with a long description (e.g.: using
the Lorem Ipsum paragraphs).
You will see that your avatar is squeezed.
Solution: In the refactoring of the SCSS of the activities (commit [1]), the
sidebar (where the avatar is shown) did not had a minimum width and as the
parent `div` is using `flex` the sidebar is squeezed. Previously, the squeeze
was prevented using `flex: 0 0 36px;` on the sidebar.
[1]: https://github.com/odoo/odoo/commit/da5d9e745fbb755745a1005ed91924ab7b79b741
opw-2799603
closesodoo/odoo#90616
X-original-commit: 355b435e688f42f04536ea6ea3f9f774a7e395f6
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Signed-off-by: Desausoi Laurent (lade) <lade@odoo.com>
In a 2-steps configuration, trigger a reordering rule with the vendor
defined will raise an error
To reproduce the issue:
1. In Settings, enable "Multi-Step Routes"
2. Edit the existing warehouse:
- Incoming Shipments: 2 steps
3. Create a product P:
- Type: Storable
- Add a vendor V
- Routes: Buy
4. Create a reordering rule R for P:
- Trigger: Manual
- Min = Max = 1
5. Open the Replenishment page and edit R:
- Preferred Route: Buy
- Vendor: V
6. Trigger the orderpoint
Error: An Odoo Server Error is displayed "AttributeError:
'product.supplierinfo' object has no attribute 'name'"
When triggering the orderpoint, it leads to
https://github.com/odoo/odoo/blob/c75a1a8ac9eef6c7d7c95b7bbbb22d919b952e26/addons/purchase_stock/models/stock_rule.py#L331
However, since [1], the `name` of a `product.supplierinfo` has been
renamed to `partner_id`
[1] f3fe2d50d9
OPW-2780562
closesodoo/odoo#90597
X-original-commit: bda8b0e610f7ec9b0bcb76de3bb52fb6049f62ff
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
*: sms, snailmail, test_mail.
This PR helps reducing the noise in the one introducing the new environment in
the discuss app. Indeed, we won't rely on the bus anymore to listen to do actions,
we will instead use the action service. The diff is awfull because the indentation
has changed as well as the parameter names. Changing the indentation and the parameters
now will ease the review of the main task.
task-2582313
closesodoo/odoo#90581
Related: odoo/enterprise#26970
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Steps to reproduce:
- Create two extra warehouses (B and C):
* Warehouse B: Resupply from San Francisco
* Warehouse C: Resupply from San Francisco
- Create a new Product:
* Storable
* Inventory > Routes: select only Warehouse B and Warehouse C
- Create a new Move:
* From WHC to a Customer
* Confirm the order
Issue:
In replenishment, the defined prefered route will be Warehouse B
Cause:
When the replenishment view is loaded, in
https://github.com/odoo/odoo/blob/5757502a79c920e1aa4c7ca1c581c533907ce674/addons/stock/models/stock_orderpoint.py#L427
The preferred route (route_id) is defined as the first element of the routes defined for the produc which is wrong.
Solution:
Filter the route_ids by selecting the route for which the supplied warehouse is equal to the warehouse selected for the orderpoint.
Note:
1) The test in "test_bom" has been modified because it was using the wrong flow (a route should have been set by default)
2) In Master we only use the _set_default_route method
opw-2815462
closesodoo/odoo#90560
X-original-commit: 15b04d616a5196192a96e6bf2114698b34654348
Signed-off-by: Adrien Widart <awt@odoo.com>
Signed-off-by: yosa-odoo <yosa@odoo.com>
When the user cancels a SO, if there is an associated PO, there won't be
any activity logged on the PO about the SO cancellation.
To reproduce the issue:
1. Unarchive the MTO route
2. Create a product P:
- Type: Storable
- Routes: MTO & Buy
- Add a vendor V
3. Create and confirm a SO with 1 x P
- Note: a PO is generated
4. Cancel the SO
5. Open the PO
Error: There isn't any information about the cancellation of the SO. An
activity should be added to the PO.
Since [1], if the PO is a draft, we no longer log an activity when the
quantity of the related SO is reduced:
https://github.com/odoo/odoo/blob/3bd9b7a77a1e0e05ea479945d5cd8085f6981feb/addons/purchase_stock/models/stock.py#L103-L105
However, when cancelling a SO, we call the activity logger:
https://github.com/odoo/odoo/blob/846ad1f978fe36db892a9902bb4657c2079d1756/addons/sale_stock/models/sale_order.py#L184-L189
So, since the PO is not yet confirmed, we ignore it and do not log any
activity
[1] bda3225c6cc27bb2c2933eda3cc68c6f9708daf3
OPW-2820242
closesodoo/odoo#90553
X-original-commit: de485a39c9ee88aa31f9330a468ad31cc05842bc
Signed-off-by: Steve Van Essche <svs@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
From 450 to 1.5 ms
closesodoo/odoo#90609
X-original-commit: 045d80187c10c74747a3fd35b931cfe0c9862c08
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Since 43463a1 it was not possible anymore to trigger hotkeys
from an editable element excepted through
the hotkey option "bypassEditableProtection".
But there are cases where the editable element may want to always
allow any hotkey: e.g. the command palette search input.
Before This Commit
Impossible to trigger hotkeys from the command palette.
After This Commit
The command palette search input now allows any hotkeys.
closesodoo/odoo#90578
X-original-commit: 72dfe16ec8453ff299c2525431db619ccfdbfdec
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Bruno Boi <boi@odoo.com>
the patchDate function had these issues:
./addons/web/static/tests/helpers/utils.js
29:5 error Read-only global 'Date' should not be modified no-global-assign
58:21 error 'date' is already defined no-redeclare
Part-of: odoo/odoo#90578
This PR helps reducing the noise in the one intorducing the new environment
in the discuss app. Indeed, there won't be widget anymore since createWebClient
will always be used. createXXXComponent methods were relying on widget.el to
mount the components. Let's already replace it by target.
task-2582313
closesodoo/odoo#90526
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
When viewing tasks for a specific project, the "Projects" filter in the
calendar view is useless, since there can only be a single project.
This commit removes the filter in that case.
Task-2741733
Part-of: odoo/odoo#86008
This commit moves the 'Customer Ratings' warning to be right under the
Rating Email Template field in the task stages settings view.
It also slightly reorders other fields and fixes a typo.
Task-2741733
Part-of: odoo/odoo#86008
This commit colors the project filter checkboxes on the right side panel
of the task calendar view with the color of the corresponding project.
It also changes the color of the events in the tasks in the calendar so it
uses the color in the project in the view "All Tasks", and the color of
the tasks in a calendar view of a specific project.
Finally, it adds some colors to tasks in demo data to better showcase
that feature.
Task-2741733
Part-of: odoo/odoo#86008
To make it more clear that the calendar view of the project tasks
only shows the deadline of the tasks, this commits appends
" - Tasks by Deadline" to the title of the view
Task-2741733
Part-of: odoo/odoo#86008
This commit uses params.displayName instead of params.action.name for calendar views titles.
This allows us, among other things, to use the project name as a title
for the project's tasks calendar view, which is more consistent with other views.
Task-2741733
Part-of: odoo/odoo#86008
This commit changes the project status column in list view to copy
the behavior of the kanban status column for tasks, by removing
the column label and show the status text on hover.
Task-2741733
Part-of: odoo/odoo#86008
In the fullcalendar library, you can by default resize events with the mouse
to alter the start and end dates. However, since for project tasks, we use
the calendar to show deadlines, it wouldn't make sense to resize them.
This commit therefore disables the ability to resize tasks.
Task-2741733
Part-of: odoo/odoo#86008
Purpose of this commit to improve generic UX of timesheet app.
So, in this commit:
- make tree view editable bottom.
- ensure that all non private tasks can be selected in timesheet
tree view.
- add job_title non store field to add custom filter on job_title.
- show unit_amount in red in tree view when it's value is less
than 0.
task-2784776
closesodoo/odoo#87630
Related: odoo/enterprise#25762
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
Prior to this commit branded UI components were styled exclusively in
raw SCSS using the '$o-brand-odoo' variable.
This leaded to unnecessary code repetitions since, to achieve the same
visual result, each module defined its own classes.
Visual inconsistencies were frequent too since each module defined its
own variations for interactive states (eg :hover).
This commit injects '$o-brand-odoo' into bootstrap's default
'$theme-color' map, allowing the framework to automatically generate
odoo utility/contextual classes.
These classes can be used to handle text, backgrounds, borders and
buttons wherever needed.
Part of the overall v16 SCSS optimization/restyle, task-2704984.
task-2800721
closesodoo/odoo#87448
Related: odoo/enterprise#25700
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
This commit improves consistency between jQueryUI dropdowns and the
overall UI. It also address inconsistencies between versions allowing
to remove 'dropdown_extra.scss' [1].
Part of the overall v16 SCSS optimization/restyle, task-2704984.
[1] enterprise adaptations: https://github.com/odoo/enterprise/pull/25700
task-2800721
Part-of: odoo/odoo#87448
Review 'o_searchview' menu entries design, improving consistency within
the overall UI.
Part of the overall v16 SCSS optimization/restyle, task-2704984.
task-2800721
Part-of: odoo/odoo#87448
The recordId parameter was not necessary in the _updateComodelRelationalFields method
of the legacy mock_server
closesodoo/odoo#90497
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Before this commit
An open dropdown stays opened if any other element stop a click event
closesodoo/odoo#90363
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
# Preparatory work for the new Knowledge module (part 1)
## Contents
* Add contenteditable as a safe attribute for DOMPurify.sanitize
> Before this change, the function _safeSetAttribute would remove contenteditable
attributes in collaborative mode when it should not have.
* Add failsafe upon CTRL+BACKSPACE
> The /template command creates a block which will contain paragraphs. We don't
want to allow this block to not have children.
>
> This commit prevents the removal of a `<p>` element if it is empty and is the
last child of its parent.
>
> In other cases, allows the removal of the last node, but insert an empty `<p>`
if the parent is a block when it becomes empty because of a CTRL+BACKSPACE.
* Prevent command refocus when unnecessary
> When typing a command in a template block, the caret must stay in the
template.
>
> Since it is CONTENTEDITABLE=FALSE and has a CONTENTEDITABLE=TRUE element, the
editable context changes and calling `this.editable.focus` will force the caret
out. Instead, we only have to call the focus if the activeElement is not a child
of `this.editable`.
* Expand deleterange for uneditables
> In Chrome, it is possible to partially select the contents of a
CONTENTEDITABLE=FALSE element if it has a CONTENTEDITABLE=TRUE child.
>
> This commit prevents breaking such uneditables by expanding the range in a
deleterange to fully contain such elements.
>
> This will prevent removing only the toolbar of a /template block in
Knowledge.
closesodoo/odoo#86489
Task-id: 2794990
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
In Chrome, it is possible to partially select the contents of a
contenteditable=false element if it has a contenteditable=true child.
This commit prevents breaking such uneditables by expanding the range in a
deleterange to fully contain such elements.
It will be useful with the new blocks introduced with the Knowledge module.
Task-id: 2794990
Part-of: odoo/odoo#86489
Currently, the focus is forced on this.editable when using a powerbox command.
Knowledge /template will introduce blocks which are contentEditable=False, but
contains sub-elements with contentEditable=True, which are allowed to use
powerbox commands. Those sub-elements have another editable context as
this.editable. As such, forcing a refocus on this.editable will remove the
caret from the sub-element.
Avoid doing the refocus if the currently focused element is a child of
this.editable and is contentEditable=true.
Task-id: 2794990
Part-of: odoo/odoo#86489
Prevents the user to remove the last child (if it is an empty block) of an
editable, in order to avoid the case where the user can add text nodes directly
in a block where it should not be possible (i.e. directly under this.editable).
Replaces any empty block other than `<P>` by an empty `<P>` which is the default
block for the editor.
Task-id: 2794990
Part-of: odoo/odoo#86489
Add the attribute 'contenteditable' to the frozen list for html elements of
DOMPurify, so that this attribute is not sanitized in collaborative mode when
using _safeSetAttribute.
Task-id: 2794990
Part-of: odoo/odoo#86489
This commit introduces models that define records being 1:1 map with components,
as a step to move further to having essentially all business code in models.
Having code in models is desirable to have very maintainable code, thanks to
robust and declarative code with an ORM-like architecture.
Task-2831082
closesodoo/odoo#90569
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Currently, if a page is loading and someone quickly clicks exactly on
the input checkbox within publish management button of website navbar,
the checkbox (input) is toggled but the string does not change.
This happens because the checkbox is toggled before the click event on
`js_publish_btn` is bound. Ideally, the checkbox should be toggled only
based on the state of the object (whenever it's changed after a
successful RPC call) so that the information we see is correct.
This commit fixes the issue by disabling the input checkbox so that
it is toggled only after the state is changed by RPC call and not
when user simply clicks on the input. Apart from that, now we toggle
`css_published` and `css_unpublished` based on the state of RPC so that
the button strings are always consistent with the checkbox.
task-2819345
closesodoo/odoo#90550
X-original-commit: 86225a7f00ae90463570221e87ace5212fb71dba
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Before this commit, the gap between `$border-radius` and
`$border-radius-lg` was too small and couldn't be differentiated easily.
After this commit, the value of `$border-radius-lg` is higher and can be
used for elements that need larger rounded corners
(e.g. Discuss components).
enterprise: https://github.com/odoo/enterprise/pull/25737
task-2810274
closesodoo/odoo#87521
Related: odoo/enterprise#25737
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
Goal:
Fix the tax details results when interacting with misc entry containing 2
opposite lines with the same tax.
The bug:
Wrong mapping in tax details query results in wrong amount in the global tax
report.
reproduction step pre-requisite:
- a simple sale tax A
- miscellaneous contains 2 lines,
- amount X debit with sale tax A
- amount Y credit with purchase tax A
- 2 tax lines gets automatically created
Before this commit:
The global tax report will display a base amount of 2*(X-Y)
which is wrong.
After this commit:
The global tax report will display a base amount of (X-Y)
which is correct.
Context:
When the tax details was made, it wasn't taken into account that there
could be 2 tax line (account_move_line) for the same tax in the same
account_move if the move is a miscellaneous entry (move_type = 'entry').
As a misc can contain both refund and invoice line at the same time (Due to a
PoS order for example), there could be tax_line created by the
invoice_repartition_line and another one created by the refund_repartition_line.
This results in a mapping in which there are some wrong results that should have
been filtered out.
The wrong results are the following match:
invoice_base_line -> refund_tax_line
refund_base_line -> invoice_tax_line
Solution:
1) To avoid the confusion we just need to filter out the wrong results.
2) In a misc entry, what makes a tax considering the base line as an invoice or
a refund is its balance.
3) In a misc entry, the sign of the tax line balance is the result of a
transformation of the base line sign.
This transformation is just a multiplication by the sign of the tax rate and
the sign of the factor_percent of the tax line repartition line.
This means that we can re apply this transformation to the base_line or the
inverse of it to the tax_line and check if it matches.
If it doesn't, we can confidently discard the match because the tax_line balance
can't be the result of a transformation applied to this base_line balance.
This is only valid for misc entry. In misc entry, negative base_line and
positive base_line are segragated for their tax line creation.
Additional notes:
A test is added to the enterprise repository to check the global tax report
result.
closesodoo/odoo#90563
Ticket: 2832745
Community-pr: https://github.com/odoo/odoo/pull/90399
Enterprise-pr: https://github.com/odoo/enterprise/pull/26827
X-original-commit: 690ef4e526b26911678ca872e7eb481215017f1c
Related: odoo/enterprise#26961
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: Brice Bartoletti <bib@odoo.com>
With this commit, if realpath is not available (for exemple on macos),
the script is directly stopped.
closesodoo/odoo#90522
X-original-commit: 7857c577948d55842a5697ca6d91bb6ea656ef6e
Signed-off-by: Samuel Degueldre <sad@odoo.com>
Signed-off-by: Pierre Rousseau (pro) <pro@odoo.com>
david