On huge DB, unlinking an account_move can take a lot of time.
Most of this time is wasted checking for foreign key constraint.
closesodoo/odoo#84817
Signed-off-by: William André (wan) <wan@odoo.com>
Schedule date was hide in the view for a back to basic task in order to
simplify the view.
But it was at the time, the optional parameter did not exist, we could
readd it under the hide option
opw-2842963
closesodoo/odoo#90790
X-original-commit: b21a960ca925ea03e32d71c5d69098f98dfde239
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Arnold Moyaux <arm@odoo.com>
on invoice, all round is default to half_up
but on efaktur export is half_down
ref #89793
X-original-commit: bd21e88ab041bf38132e7bd1502ca6e21a34ff0e
Part-of: odoo/odoo#90456
Steps :
Go to a Project's settings.
In your 'Following' preferences, uncheck 'Task Rating'.
Create a new Task in this Project and see your preferences.
Issue :
Task Rating is checked.
Cause :
The default value of project's task rating notification is True.
The value of its task's is supposed to be inheritted from there.
Yet, this inherittance only happen when default is False.
Fix :
Set default to False.
opw-282497
closesodoo/odoo#90816
X-original-commit: acb3b4dc9d93dad5850fe4bfa00770b0b8026d22
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
In a MTO case, when a salesman decreases the ordered quantity, it can
lead to an access error
To reproduce the issue:
(Use demo data)
1. In Users, edit Marc Demo:
- Invoicing: None
- Purchase: None
2. Create a product P:
- Type: Storable
- Add a vendor V
- Routes:
- MTO
- Buy
3. Log in as Marc Demo
4. Create a sale order SO with 2 x P
5. Confirm SO
6. Edit SO:
- Set the qty of P to 1
- ignore the warning
7. Save the SO
Error: There is an access error ("create" on "Activity" (mail.activity))
Because the user decreases the quantity, we want to log this decreasing
on the related documents:
https://github.com/odoo/odoo/blob/ee9ea35ad218be87564de484470f1c4e9c433977/addons/sale_stock/models/sale_order.py#L91-L94
In the above case, it leads to a write operation on the generated
purchase order. However, Marc Demo hasn't any right to perform such an
operation.
We should bypass the rights checking in such situation.
Note: in `/sale_stock:SaleOrder.write`: we need to specify what kind of
precision we are using.
OPW-2745317
closesodoo/odoo#90782
X-original-commit: 525d3e2a7e6679a73de1b1a16f666d015543e5bd
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
Current behavior :
When a workorder is marked as done, the returned view is inconsistent between
"control panel" and work orders' list view.
- "Control panel" : we correctly land back to workorders from this workcenter
- List : we land back to an empty list view
Steps :
- Install Manufacturing
- Get or create a manufactured product
- For this product, plan some orders in a work center
*Control Panel view*
- Proccess to a workorder and mark it as done
-> Correctly redirected to a kanban view with remaining workorder linked to
this work center
*List view*
- Proccess to a workorder and mark it as done
-> Redirected to an empty list view
OPW-2767737
closesodoo/odoo#90805
X-original-commit: 4d231c226fb118b8ebd9f4f896f4ec04d705d210
Related: odoo/enterprise#27077
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Claude Thibault (thcl) <thcl@odoo.com>
Before this commit, the animations were never launched in a mega menu
with the navbar option "sub menus = on hover" enabled.
Indeed the animations are launched when the element to be animated
appears in the viewport according to the scroll. But in the case of a
mega menu we just want the animation to start when the mega menu is
opened. For that we don't need all the code that checks the scroll, etc.
The animation starts by itself when the element inside the mega menu is
made visible in CSS.
A first attempt to fix this was made by this commit [1], but this fix
was wrong. Indeed, as explained above, animations in a dropdown do not
need to be triggered on scroll. And moreover, it didn't work properly
because the animations were never reset when the dropdown was closed.
[1]: https://github.com/odoo/odoo/commit/7a96557b839a69a9d44aac4242af2d21bc7f0e38
opw-2764895
closesodoo/odoo#90826
X-original-commit: bae04041a528e1a1fe97387ca5b75943c1d0fe97
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Before this commit, when the user adds an employee mapping into a
project for an Employee A, the cost does not equal to the timesheet
cost set on this employee. The reason is the `cost` field is
considered as manually edited because of the compute of
`is_cost_changed` field set the `is_cost_changed` to true when the
user changes `employee_id` field in the mapping since the cost (by
default set to 0) is different than the timesheet cost. In fact,
the compute of the cost needs value of `is_cost_changed` field
before setting a value to `cost` field since this compute should
only change the cost if it is not manually edited, that's why the
cost is never equal to the timesheet cost of the employee set on
the mapping.
This commit fixes the issue by removing the compute of
`is_cost_changed` field in the list of recompute fields when we are
in the compute of the `cost` field, because when the `cost` is
recomputed, it means the user has changed or set the employee into
the mapping and so you could avoid computing the `is_cost_changed`
fields. With this change, the compute of `is_cost_changed` will only
trigger when the user manually changes the `cost` field in the
mapping.
Also, the `is_cost_changed` field is added into the view as
invisible to avoid recomputing the field each time we need it, we
could use the cache to avoid recomputing it when it is not
necessarily.
Steps to reproduce:
------------------
1. Go to a billable project
2. Add employee mapping for an employee A
Expected Behavior:
-----------------
The cost of this mapping should be equal to the timesheet cost
set on the employee A.
Actual Behavior:
---------------
The cost of the mapping is equal to 0 because the cost is
considered as manually edited even if it is not the case.
Related PR: #70527closesodoo/odoo#90788
X-original-commit: c05b6bdba5e580f30975829cd6b42429527698a5
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
Signed-off-by: Xavier <xbo@odoo.com>
When this popup appears, it is not obvious that there is an on_change
on the 'Contents' field, and unless the user starts typing in it the
user will not know if 'Reject' will notify the sender or not.
closesodoo/odoo#90785
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Following odoo/odoo#87522,
the use of `fields_view_get` is deprecated.
All calls to it should be replaced by a call to `get_views`.
The fact it has not been in the above pull request is an oversight.
closesodoo/odoo#90750
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
On a `sale.order`, when hitting the `View Forecast` button,
a traceback occurred:
```
Traceback (most recent call last):
File "/home/odoo/src/odoo/master/odoo/http.py", line 1381, in _serve_db
return service_model.retrying(self._serve_ir_http, self.env)
File "/home/odoo/src/odoo/master/odoo/service/model.py", line 136, in retrying
result = func()
File "/home/odoo/src/odoo/master/odoo/http.py", line 1410, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
File "/home/odoo/src/odoo/master/odoo/http.py", line 1607, in dispatch
result = self.request.registry['ir.http']._dispatch(endpoint)
File "/home/odoo/src/odoo/master/addons/website/models/ir_http.py", line 220, in _dispatch
response = super()._dispatch(endpoint)
File "/home/odoo/src/odoo/master/addons/utm/models/ir_http.py", line 27, in _dispatch
return super()._dispatch(endpoint)
File "/home/odoo/src/odoo/master/odoo/addons/base/models/ir_http.py", line 137, in _dispatch
result = endpoint(**request.params)
File "/home/odoo/src/odoo/master/odoo/http.py", line 541, in route_wrapper
result = endpoint(self, *args, **params_ok)
File "/home/odoo/src/odoo/master/addons/web/controllers/dataset.py", line 42, in call_kw
return self._call_kw(model, method, args, kwargs)
File "/home/odoo/src/odoo/master/addons/web/controllers/dataset.py", line 33, in _call_kw
return call_kw(request.env[model], method, args, kwargs)
File "/home/odoo/src/odoo/master/odoo/api.py", line 457, in call_kw
result = _call_kw_model(method, model, args, kwargs)
File "/home/odoo/src/odoo/master/odoo/api.py", line 430, in _call_kw_model
result = method(recs, *args, **kwargs)
File "/home/odoo/src/odoo/master/odoo/models.py", line 1808, in fields_view_get
view = self.env['ir.ui.view'].sudo(result.pop('id'))
File "/home/odoo/src/odoo/master/odoo/models.py", line 5381, in sudo
assert isinstance(flag, bool)
AssertionError
```
This follows the `load_views` refactor odoo/odoo#87522.
`fields_view_get` has been deprecated. All calls to it must be replaced
by calls to `get_views`.
Leaving it there is an oversight:
https://github.com/odoo/odoo/blob/fc26cc1789b1309e54473cccbc545145ccbaee31/addons/stock/static/src/js/report_stock_forecasted.js#L116
However, this demonstrated an issue in the compatibility layer added
server-side to keep `fields_view_get`.
This revisions solves the compatibility layer bug.
In the next commit, the call to `fields_view_get` is replaced to
a call to `get_views`
Part-of: odoo/odoo#90750
When we had a traceback because of a server action, we used to have no
information in the traceback about which server action it was.
With this commit, we will be able to see the server action id in the
traceback. This will help the investigation as we will be able to check
the server action that causes the issue.
Example:
Previous traceback for a server action that executes bad python code:
```
Traceback (most recent call last):
File "/home/odoo/src/version/15.0/odoo/odoo/tools/safe_eval.py", line 330, in safe_eval
return unsafe_eval(c, globals_dict, locals_dict)
File "", line 1, in <module>
NameError: name 'i' is not defined
```
Now:
```
Traceback (most recent call last):
File "/home/odoo/src/version/15.0/odoo/odoo/tools/safe_eval.py", line 330, in safe_eval
return unsafe_eval(c, globals_dict, locals_dict)
File "ir.actions.server(152,)", line 1, in <module>
NameError: name 'i' is not defined
```
closesodoo/odoo#87086
Signed-off-by: Olivia Fantinel (ofa) <ofa@odoo.com>
Steps to reproduce:
1) Create a product with 0 on hand qty and under Sales tab,
"Continue Selling" if Out of Stock unchecked.
2) Navigate to the website's shop.
Customize -> Add Feature -> enable Add to Cart.
Current behavior:
From the Shop's screen, the button to add to cart for this product
is clickable and the animation plays, but no item is added (because
out of stock).
Expected behavior:
There is no animation when an out-of-stock product is added to the cart
Solution:
The rpc call for /shop/cart/update_json will return a dictionary with a
cart_quantity value. If this value is different from the current cart quantity
shown in the navbar then a product was added and the animation should
be applied as usual otherwise it means no product was added and nothing
should happen.
opw-2745305
closesodoo/odoo#90734
X-original-commit: 4f6a4465a48fb9b3cac9c54b042b4ac97db45bae
Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>
When updating the MO quantity, the reservation of the components doesn't
respect the reservation method of the operation type.
To reproduce the issue:
(Use demo data)
1. Edit the operation type "Manufacturing":
- Reservation Method: Manually
2. Create and confirm a MO for 1 x [FURN_8855] Drawer
- Note: the components are not reserved, as expected
3. Update the quantity to produce (2 x Drawer)
Error: The components are reserved
The new conditions are directly based on the conditions to reserve a SM
when confirming it:
https://github.com/odoo/odoo/blob/e55988fc4d8090f84157a026b7ecc7ea0dc146a7/addons/stock/models/stock_move.py#L1242-L1248
OPW-2822205
closesodoo/odoo#90728
X-original-commit: 76168d0f95203c97e60955c2df396b3bb81aa4f3
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
When the wizard (new dialog) is opened on the burger menu item, the burger menu does
not close. The burger menu appears on the wizard. It is fixed.
Reproduction Steps
-Installed project application
-Reporting -> Burndown Chart
task-2739646
closesodoo/odoo#90721
X-original-commit: 69821a67ca04d9aa5bb040d93e491c7f75b67232
Related: odoo/enterprise#27027
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
Usecase to reproduce:
- Install mrp_subcontracting
- Create a user with inventory access but not mrp access
- Validate a receipt for a product
Current behavior:
Access error on `mrp.production`
Expected behavior:
The receipt and the linked subcontracting order are validated
The stock user only receipt the products from the subcontractor so
he doesn't need to know the `mrp.production` behind that's why he
doesn't need access right. However he should be able to validate the
transfer since he receipts the goods. And it should update the quantity
on the subcontractor side by validating the subcontract order, so
we pick the sudo solution.
closesodoo/odoo#90301
X-original-commit: f1660b2254460abe10ce1d0a1fa7639d5c3e2b33
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Arnold Moyaux <arm@odoo.com>
This could lead to a traceback in case the user's priviledge is not
sufficient to make the name_search
closesodoo/odoo#90687
X-original-commit: 28ad95df0807c117d3865a899a96939d0ac36e84
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Do not exclude the current partner from the partner search so that you
can easily start a chat with yourself.
Task-2844917
closesodoo/odoo#90663
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
+ Rename the CSS class `o-mobile` to `isDeviceSmall` in order to match the name
of the field tested to conditionnaly add or remove the class.
+ Remove unused classes (o-downloadable and o-isMobile).
+ Rename CSS class `o-has-multiple-action` to `o-hasMultipleActions` and
introduce a new field on AttachmentCard to express more declaratively the
condition used to add or remove the class
closesodoo/odoo#90643
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
This commit introduce a macro system, to allow code to automate user
actions. For now, this is useful for the knowledge application. But in
general, this may be used by any code that want to interact "as a user"
with the web client. For example, we may consider rewriting the tour
system using macros.
Sample macros:
```js
const testMacro = {
name: "test_macro",
onStep: (el, step) => {
console.log("macro step activated", el, step);
},
timeout: 5000,
steps: [
{
trigger: '.dropdown-toggle[title="Home Menu"]',
action: "click",
},
{
trigger: ".wrong-selector",
action: "click",
},
],
};
const testMacro2 = {
name: "test_macro2",
interval: 1000,
steps: [
{
// Open contact application
trigger: '.dropdown-toggle[title="Home Menu"]',
action: "click",
},
{
trigger: '.dropdown-item:contains("Contacts")',
action: "click",
},
{
// click on create button
trigger: () => document.querySelector('button[title="Create record"]'),
action: "click",
},
{
action: () => console.log("we are here..."),
},
{
// input name
trigger: 'div[name="name"] input',
action: "text",
value: "Aaron B.",
},
{
// save
trigger: 'button[title="Save record"]',
action: "click",
},
],
};
/**
* Infinite macro! This also illustrates that macros can be used to do non
* linear sequence of steps.
*/
const testMacro3 = {
name: "test_macro3",
steps: [
{
// Open contact application
trigger: "button.o_form_button_cancel",
action: "click",
},
{
action: () => activateMacro(testMacro3),
},
],
};
const testMacro4 = {
name: "test_macro4",
onError: (error, step, index) => {
console.log(`an error occured at step ${index}`);
console.log(step, error);
},
steps: [
{
// Open contact application
trigger: '.dropdown-toggle[title="Home Menu"]',
action: "click",
},
{
action: () => {
throw new Error("boom");
},
},
],
};
```
closesodoo/odoo#88994
Related: odoo/enterprise#27010
Signed-off-by: Samuel Degueldre <sad@odoo.com>
When triggering an inter-warehouses reordering rule, the partner of the
receipt is incorrect. When triggering several inter-warehouses
reordering rules, it will remove the partner of both receipt and
delivery
To reproduce the issue:
(Let C be the current company)
1. In Settings, enable "Multi-Step Routes"
2. Let WH01 be the existing warehouse. Edit WH01:
- Set a new address ADD01:
- Type: Individual
- Company: C
- Address Type: Delivery Address
3. Create a new warehouse WH02:
- Set a new address ADD02:
- Type: Individual
- Company: C
- Address Type: Delivery Address
4. Edit WH02:
- Resupply From: WH01
5. Create 2 products PA, PB:
- Type: Storable
- Routes:
- WH02: Supply product from WH01
6. For product PA:
- Update the quantity:
- 10 in WH01/Stock
- Add a reordering rule:
- Location: WH02/Stock
- Trigger: Manual
- Min = Max = 1
7. Run the scheduler
- It generates a delivery D and a receipt R
8. Open R
- Error 01: the field "Receive From" is incorrect (ADD02 instead of
ADD01)
9. Repeat step 6 for PB and run the scheduler again
- Error 02: R and D have no more partner
Error 01: see diff
Error 02: we have two SM (one for PA, one for PB) that have a different
origin (one per reordering rule). Therefore, we remove the origin of the
pickings. However, we also remove the partners while we shouldn't
OPW-2733989
closesodoo/odoo#90706
X-original-commit: 20e0ad13afa2a0ff85d555ab57a6800d3db30341
Signed-off-by: Tiffany Chang <tic@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
Current behavior:
When authorized employees is activated is activated for a PoS if you
go back to the login screen and do nothing for like 1 minutes you would
go back to the PoS logged as the previous employee
Steps to reproduce:
- Have PoS installed, create a PoS restaurant wiht authorized employee
- Start a PoS session
- Click on the lock button to go back to the login screen
- Wait for 1 minute
- The screen go back to the PoS
opw-2792531
closesodoo/odoo#90698
X-original-commit: e1741d904f5ae206dff767ff215e0568a7ef008e
Signed-off-by: Masereel Pierre <pim@odoo.com>
Currently we can not add Manufacturing orders Report (graph view) to the
board because of missing context keys (`allowed_company_ids`)
We just have to add the key in the context of `mrp_production_report`
opw-2813295
closesodoo/odoo#90688
X-original-commit: ef789170ce2f1553b325b379aac4452e473de1e9
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Achraf <abz@odoo.com>
`res.users` has virtual fields which are emulation of the real fields.
It requires extra check to ignore such fields. BEFORE there was the following
error:
```
undefined is not an object (evaluating 'fieldInfo.depends.length')
```
STEPS: Go to a User record and use the Dev settings to 'Set Defaults'
---
opw-2731081
closesodoo/odoo#90677
X-original-commit: 6320f38332345ca61d472cae87d1e512b95b84c3
Signed-off-by: Simon Genin (ges@odoo) <ges@odoo.com>
Signed-off-by: Ivan Elizaryev (iel) <iel@odoo.com>
Steps to follow:
- Switch the current lang to mongolian
- Go to a list view
- Add a custom filter on a date type field
-> locale() locale mn-MN is not loaded from moment locales!
Cause of the issue
- moment.js tries to use the mongalian locale but it is not present
Solution
Add the mongolian locale (from moment 2.29.2)
opw-2829233
closesodoo/odoo#90704
X-original-commit: 179a4b2f31d8e2e0e2be308917725a05c5b78058
Signed-off-by: Hubert Van De Walle <huvw@odoo.com>
Steps to reproduce the issue:
1)Inventory > Configuration > Settings > Activate "Reception Report"
> Activate "Show reception report"
2)Choose a non english language
3)Sales > Choose SO > Delivery > Allocation
4)Click on the Assign/Unassign equivalent in the new language
Current behavior:
The word in the Assign/Unassign button is in english
Expected behavior:
The word in the Assign/Unassign button is in the new language
Explanation:
When clicked the button starts a function in js that changes the
button text context without translating the new text. We also modify
the text in javascript and the problem is solved.
Issue 2:
The button had fixed size specific to the english language, if a longer
translation in another language was used it was cut leading to make it
unuderstanble in some languages (e.g. german).
opw-2827247
closesodoo/odoo#90705
X-original-commit: 260f433f5600e568db59c82a9c2fc807c1204b5f
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Fockedey Martin (mafo) <mafo@odoo.com>
PURPOSE:
This commit adds a min-height property to event pages so that
the footer does not take the entirety of the screen when a page
has little content.
To not have a strange empty space on the booth event page when no booth
is set or when the event is finished, the related error messages are
now displayed below the cover instead of inside it.
It also removes the default grey background on some templates,
so that the theme background color is used instead.
Task-2831951
closesodoo/odoo#89602
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
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>
Brice bib Bartoletti