The /terms page may be disabled/enabled in the company settings, however
the page would always be present in the sitemap whether it is enabled or
not.
This commit adds a method that checks for this settings before adding it
to the sitemap.
TaskId-2820292
closesodoo/odoo#90930
X-original-commit: 729b99a789b52c09be0272cefa3bb0eaccd6803c
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
With this commit, we make sure that all lines are fully reconciled when
reversing a move.
Steps to reproduce:
- Create a Journal Entry, with eg a line with 300$ debit/credit and two others
lines to make the journal entry fully balanced
- Then reverse the move
-> Only one line is marked as fully reconciled, the other one is marked
as partially reconciled.
This is because each line was passed in the reconcile method with
all the counterpart lines, even those which didn't belong to it.
Therefore, all the firsts lines was marked as partially reconciled
until the last one, which passed with the only counterpart line
left.
With this commit, we group the lines and counterpart lines by account,
and reconcile them.
opw-2810392
closesodoo/odoo#90928
X-original-commit: 0a03d029f93f6c0f31f6617c00943aa2dfcd937b
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Guillaume Vanleynseele <guva@odoo.com>
An activity should be posted only when a SO is cancelled, this happens
after _action_cancel as action_cancel doesn't always cancel the order.
sale_purchase was forgotten in commit
7c8f15d4141d4ae130da59d58ee2eaff39e363c4
closesodoo/odoo#81569
Related: odoo/enterprise#26866
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Before this commit, when cancelling a SO, the wizard opened only when
there were draft invoices or delivered picking in the order.
In order to complete the notification flow of the SO and avoid
unexpected cancellation of orders, the user must now confirm
cancellation and gets to possibility to send an email notification.
task-2660895
Part-of: odoo/odoo#81569
Before this commit, when we go to the project kanban view:
the color displayed on the left of the card isn't totally responsive
when zooming in. there is a gap between content and border of kanban card.
This commit fixes the issue by aading the outline to remove white
space between border and content.
task-2720976
closesodoo/odoo#90897
X-original-commit: 89bc3255ef1496a033389e9c6d3c6eeef46115a3
Related: odoo/enterprise#27116
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
Currently, when we go to the project sharing and task chatter in
the portal view the avatar icon of portal chatter
contains more size than the avatar icon size of normal chatter
so this commit fixes the issue by applying a CSS property so that the icon
has the same size in the portal chatter.
task-2720976
X-original-commit: 220565b56493fe13d0c1757da8a0554295ebae19
Part-of: odoo/odoo#90897
Currently, when we go to the planning > config > resource
(editable list view without any record) and create a ersaource
the color picker widget is resized vertically instead of horizontally.
In this commit we have fixed the issue, when there is no record in
the planning_resources list view, the color_picker widget gets 72px width by
default, so we have added a condition that if there is a color_picker widget
in a field, we will calculate the width based on the total fields in the view.
task-2720976
X-original-commit: d047080c18ea4c9314df5f2aefdfb6b7deeef45a
Part-of: odoo/odoo#90897
Before this commit, when we go to the project.task > kanban examples wizard:
small display issue if we zoom in the wizard until we see the scroll bar,
then the left border of the menu disappears.
The commit solve the issue by adding a property height : fit-content that
will adjust content according to the height.
task-2720976
X-original-commit: cabf5bef9c1f0470c171e9f375bb29fc749ad8fa
Part-of: odoo/odoo#90897
Before this commit, when we go to the systray > my profile:
the job title is not correctly aligned with the other fields.
This commit aligns the job title field with the other ones.
task-2720976
X-original-commit: 5f09258c3e8b0cc4a0b283e7ea0a0b4b3fd39c91
Part-of: odoo/odoo#90897
Before this commit, when we go to project.task > kanban examples wizard:
the kanban state icons are missing in the description.
This commit fixes the issue by adding the d-inline-block class.
task-2720976
X-original-commit: 2593fb1e51354096c1aa6107023e05a199b49593
Part-of: odoo/odoo#90897
Since odoo/odoo#85759 we are allowed to use other hashing algorithm
with OGONE's payment acquierer.
The V15 fw-port of this PR missed to unlock the max key size.
The goal of this PR is to fix the issue where 32+ length key
were not accepted in V15 and later.
opw-2766648
closesodoo/odoo#90895
X-original-commit: 534d16a6000c603025897bae225e0955317f411f
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Before this commit, the qunit test with activities in
calendar was relying on the current date to assert code
that show "today" activities.
This was working most of the time, but could fail at some
time of the day, like at midnight.
This commit fixes the issue by ensuring the test executes at
a specific date time, all the time.
closesodoo/odoo#90875
X-original-commit: 77fc727c05b0c9639581a3bc6ec6164d219988bf
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Before this commit, in the qunit tests, the mocked method
of `_systray_get_calendar_event_domain` was taking the current
datetime as date.
This was a problem because all date and datetime comparisons are
done in datetime, and date must start at the ealiest datetime of
the date.
X-original-commit: 6d529008a6854636c78151d19f744417044ef2e7
Part-of: odoo/odoo#90875
Steps to reproduce the bug:
- Config/Settings > "Event Gamification" needs to be enabled >
- Go to an event E > Tracks, select one with a quiz > View on website > Do quiz
- On website > Go to E > click Take the Quizz > Fill the answers
- Check the answers
Bug:
Error was raised saying need to answer all questions instead of showing correct vs incorrect answers
opw:2733275
closesodoo/odoo#90873
X-original-commit: 5f15f76e6a9467c245af1d4804d773cce59d902b
Signed-off-by: Simon Goffin <sig@odoo.com>
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>
William Braeckman