When the user is set in another timezone than the context timezone, the first or last work interval retrieved to calculate the number of days
between two dates is starting later or ending earlier depending on the user timezone.
The number of days displayed between two dates is therefore not an integer.
e.g.
A time off taken between 08/06/2021 and 10/06/2021 (timezone in the context is Europe/Brussels) will give:
- Number of days: 3 days if the user is in Europe/Brussels
- Number of days: 2.69 if the user is in Asia/Calcutta (first work interval starting later)
- Number of days: 2.5 if the user is in US/Pacific (last work interval ending earlier)
task-2646655
closesodoo/odoo#77036
Related: odoo/upgrade#3486
Signed-off-by: Kevin Baptiste <kba@odoo.com>
A user should be able to scrap some products thanks to an internal
transfer.
To reproduce the issue:
1. In Settings, enable "Multi-Step Routes"
2. Create a storable product P and update its quantity (> 1)
3. Create a planned and internal transfer T:
- From: WH/Stock
- To: Virtual Locations/YourCompany: Scrap
- With: 1 x P
4. Mark T as done
Error: T is still in draft
The `_compute_state` of a picking should not ignore the scrapped moves.
However, if we include them, we need to think about this use case: a
picking with a cancelled normal move and a done scrapped move -> its
state should be cancelled (see use case and test from [1])
[1] 429b589618e8dc2b0c0ccdec3f6eed88f1c73fc8
OPW-2841190
closesodoo/odoo#90870
X-original-commit: 1c956d49b45e9d3fec2bfa2c2020ea278ea80507
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
Do not require user to type all digits of the document number
Instead, fill the dash-separated numbers with zeroes, as needed
closesodoo/odoo#90865
X-original-commit: 9ed26751bfbe84444f291835de5f47bbac3f7dde
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Stanislas Gueniffey (stgu) <stgu@odoo.com>
Before this commit: if a Microsoft event didn't have body property,
it couldn't get synced with Odoo and raised an error.
The solution is first to check if it contains the body and then gets
its content value.
opw-2765443
closesodoo/odoo#89634
X-original-commit: 13d57ff5e714bee96fb930c1b8050816bf22c268
Signed-off-by: Arnaud Joset <arj@odoo.com>
Signed-off-by: Pedram Bi Ria (pebr) <pebr@odoo.com>
Before this commit, the code of the `add_to_dashboard` method did not go
through the get_view override of the board model. Because of that, it
did not get the arch of the current board, which means that each
add_to_dashboard call was actually a complete reset: it was not possible
to add an action without removing the current board state.
For reference, this was caused recently by a change in commit b03c227e88.
The fix is basically a localized revert of that commit.
closesodoo/odoo#90830
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
Have the taxes:
- [Ftax] any% included in price
- [TAX1] 15% not included price
- [TAX2] 15% included in price
Apply [Ftax] and [TAX1] to a product having product price [PRI]
Have a fiscal position mapping [TAX1] to [TAX2]
Make a SO with the fiscal position, add in a line the product
The unit price will not be [PRI] but will increment. This occur because
when doing the mapping we apply the computation for incl->* mapping
when just one tax is included in price
opw-2797237
closesodoo/odoo#90804
X-original-commit: 290e5a6a411ad193ab5695eba02cc4142b3a48fe
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: Grazioso Andrea (agr) <agr@odoo.com>
Before this commit:
calling `odoo-bin cloc -P <path_to_a_module>` when the manifest of a
module includes an empty string in the demo, demo_xml or cloc_exclude
entries, would result in a crash because an empty string is not an
acceptable pattern for Path.glob
to note: an empty string in those entries is technically wrong and will
cause issue during module install, but that shouldn't prevent the cloc
from giving correct results.
closesodoo/odoo#90650
X-original-commit: 93318b22fc8b7cf6344f789d2c45fc3f5b3269eb
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Thibault Francois <tfr@odoo.com>
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>
Philippe Wauthy