This will allow to reduce overrides in enterprise, and we want to display the
feature in community soon as well.
Part of task-2871070
closesodoo/odoo#95085
Related: odoo/enterprise#29036
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
After the payment apocalypse, `payment_test` was cleaned and stripped of
all useless parts. It was a very basic testing acquirer that allowed to
enter fake arbitrary payment details, choose whether they should be
tokenized, and then pay. It was intended to test the payment flow of
various applications (Sales, Subscriptions, Invoicing, ...) for a single
scenario: successful payments with immediate capture.
In order to extensively test an app's payment flow (explore other
scenarios), we need `payment_test` to have additional features.
Now, `payment_test` will allow profound testing of these features:
- separate authorization and capture
- customer fees computation
- tokenization
- refunds
- on the /pay page, users will be able to select the status of the
payment
- on the payment transaction form view, users can change the status of
a payment 'pending' to either succeed or fail
- on the payment token form view, users can change the state of future
transactions made with that token
task-2512196
closesodoo/odoo#78083
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Co-authored-by: xlu-odoo <xlu@odoo.com>
In some cases, replanning a work order does not change anything.
To reproduce the issue:
(Use demo data):
1. In Settings, enable "Work Orders"
2. Create two manufacturing orders (MO01, MO02) with 1 x [FURN_8522]
Table Top
3. Confirm MO01 and MO02
4. Set the same Scheduled Start Date (SSD) on the WO of each MO
- A warning should be displayed on the work order line because of
the conflict
5. Open the warning and click on "Replan"
Error: Nothing happens, the warning is still displayed and the scheduled
start date does not change.
For the warning symbol to be displayed, we check (through
`_compute_json_popover`) if two work orders are in conflict:
https://github.com/odoo/odoo/blob/8cb5aad6126e3f63ee4ef91115c8b4a6be571828/addons/mrp/models/mrp_workorder.py#L719-L722
So, we base this information on the `mrp.workorder`
However, the planning logic is based on another model:
`resource.calendar.leaves`. When planning a WO, we create a
`resource.calendar.leaves` and we link this slot to the WO thanks to the
field `leave_id`:
https://github.com/odoo/odoo/blob/4870606b00a758e63713e6e82c0cba9b1e7dd4aa/addons/mrp/models/mrp_production.py#L1238-L1248
Therefore, when replanning a WO, we ensure that the new slot does not
overlap any existing slot in the same workcenter. But, here is the
issue: when writing the start date (step 4), we try to replan the WO of
the MO only if this MO is already planned:
https://github.com/odoo/odoo/blob/4870606b00a758e63713e6e82c0cba9b1e7dd4aa/addons/mrp/models/mrp_production.py#L723-L724
Wich is not the case in the above steps. So, we don't (re)plan anything
=> we don't create any slot.
As a result: the warnings are displayed, which is correct, but when
trying to replan one of the WO (step 5, viathanks to
`_plan_workorders`): There isn't any slot starting from WO's start date
(there isn't any slot at all!), so we can create a new slot -> the start
time of the WO does not change -> considering their start times, there
is still a conflict between both WOs.
Comment: if after the step 5, the user tries to replan the other WO, it
will work: the first replanning fails but a slot has still been created.
Therefore, when replanning the second WO, the newly-created slot will be
detected, a second slot will be created after the first one and the
start date of the second WO will be postpone (according to the second
slot).
(!) Note that nothing creates any slot if we directly define the start
time of the WO during the MO creation (step 2). So this use case will
fail too.
We should ensure a perfect coherence between both models
`resource.calendar.leaves` and `mrp.workorder`.
OPW-2887413
closesodoo/odoo#95087
X-original-commit: 9d4d8d24792933e53a4ca422ccedde8ddc93cdf4
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
Purpose
=======
Properly display and resequence articles based on sequence field. Articles are
currently not sorted based on sequence, and when moving articles outside of a
parent resequencing is not applied.
Specifications
==============
Properly resequence articles not only if the parent_id value is non-false but
also if it's in the vals and set to False (when moving an article to the root).
Task-2883368
closesodoo/odoo#95078
X-original-commit: 6dde05e8779feb2ad6f8828e1bc2945fcf403248
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Overriding method has_group() in some extension of model 'res.users' is
not possible because of code invoking model.has_group.clear_cache().
As clear_cache() is no longer invoked on ormcached methods, we can
simply replace the code by a global cache invalidation. In this case,
it is not even necessary, since method call_cache_clearing_methods()
does it already.
closesodoo/odoo#95071
X-original-commit: 2dc80fe49ec2cb11e65465d4616b9bbb136bf6ab
Signed-off-by: Raphael Collet <rco@odoo.com>
Before this commit: If a fixed tax is used for a product with the price
of zero, the tax line sign would be positive and lead to an unbalanced
move. The solution is to use its sign in its context for correct
calculation.
Also, in the PoS front-end, when you want to return a zero amount
product with a fixed tax, its sign would be positive, which is
incorrect.
Steps to reproduce the first issue:
- Install 'Point of Sale' module
- Create a new 'Tax' X with a fixed price (e.g.: 1 $)
- Create a new 'Product' with zero Sales Price
- Create a PoS session
- Add the product to the order
- Close the session
It creates a line for the "Difference at closing PoS session," and
doesn't prevent closing. But the problem is that the tax capture as
debit is incorrect. The tax for the invoice must be credit.
Steps to reproduce the second issue:
- Install 'Point of Sale' module
- Create a new 'Tax' X with a fixed price (e.g.: 1 $)
- Create a new 'Product' with zero Sales Price
- Create a PoS session
- Add the product to the order
- Change the quantity to -1 (refund)
The final amount is positive, while it should be negative.
Solution
The sign must be sent in the context, and for the PoS front-end, it
should consider zero amount cases.
opw-2833590
closesodoo/odoo#95067
X-original-commit: c5fb4f778db95fb33845b9a5e0c2190d4d9037ee
Signed-off-by: Masereel Pierre <pim@odoo.com>
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Currently, in demo data (or data) of some surveys, there are records of
'survey.question' having 'is_page' field value as true and 'question_type'
is not defined. When question type is not defined, default value
'simple_choice' is assigned to the 'question_type' field. Now when we
create a live session of that survey and goes to the page, it tries to read
the data for bar chart but data is not available (undefined) and throws the
traceback. This happens because question types 'simple_choice' and
'multiple_choice') are expected to load a bar chart.
It used to work before commit[1] where default 'question_type' value was
being set to 'text_box' (so attempt to load bar chart was not made).
As a safest fix in stable, this commit adds condition in JS and in template
to make sure that bar chart will be instantiated only if the data needed by
(checked with JS) and when the question is not a 'page' (checked with
template).
commit[1] - https://github.com/odoo/odoo/commit/1fb99d7#diff-cf2aadbf6a252dfca6d3450a0ce6ad280b1924afe9a8fc22f7077c998d080009R52
taskID-2841582
closesodoo/odoo#95055
X-original-commit: d7c485e0b0791b6d3d127fedf867b9664df05463
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
The populate JS class has been removed in #94554 but was still
referenced in the view.
closesodoo/odoo#95050
Signed-off-by: Kevin Baptiste <kba@odoo.com>
This commit fix 3 problem
Don't count studio field
------------------------
the commit https://github.com/odoo/odoo/commit/75b8c4eb1ed6e44f427886eea06ad216995e16c8
was supposed to stop counting count field generate by addins a smart
button with studio.
It works fine when base import module is not installed which is never
the case.
When base_import_module the field is counted as a field that belong
to a imported module installed : studio_customization
studio_customization should not be counted as an imported module
installed
Count Field with standard xml_id
--------------------------------
With https://github.com/odoo/odoo/commit/9afce4805fc8bac45fdba817488aa867fddff69b
Each manual can end up with an xml_id from a standard module:
the original module of the model
A standard module should never create a manual field so we can consider
they should be counted unless they match the criteria of the first
problem
If a field has a standard module xml_id and no other the module
should be odoo/studio and not the name of the standard module
Make possible to exclude some db record from cloc
-------------------------------------------------
It's possible to exclude some file in python module
but it's not possible to exclude some field or SA in
the database from the count
Make it possible if they are link to an xml_id
from the module __cloc_exclude__
The exclude record will be shown in cloc report with
the verbose mode
closesodoo/odoo#95028
X-original-commit: db52fb174461107e26b066147801f54a89d0dbf9
Related: odoo/enterprise#29007
Signed-off-by: Christophe Simonis <chs@odoo.com>
Since https://github.com/odoo/odoo/pull/85176, following a conflict resolution in a forward-bot,
the domain used to show the "Recurrent" option in the form view
of tasks is wrong, and the option is shown for all unarchived tasks,
regardless of whether the setting is enabled.
This commit fixes this domain.
closesodoo/odoo#95015
X-original-commit: f26d864da52a3543d9f9733b2833a3210d5449f6
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
Signed-off-by: Larcin Vincent (vila) <vila@odoo.com>
The test was randomly failing on nightly builds as the timeoff was
considered as started, thus preventing the user from modifying it.
closesodoo/odoo#95010
X-original-commit: 95f84086d15ed0a139e4e145dc2422a949f1ae95
Signed-off-by: Kevin Baptiste <kba@odoo.com>
1f7c83cc3e renamed _notify_compute_recipients to
_notify_get_recipients. This function was not renamed with it so
members of the hr_recruitment.group_hr_recruitment_interviewer group
were receiving chatter they shouldn't be receiving.
The test didn't catch this because:
- the interviewer was not subscribed and thus never received email,
- MockEmail._filter_mail got passed status=False instead of None,
which always made it return an empty mail.mail recordset.
opw-2898730
closesodoo/odoo#95004
X-original-commit: 4dd9d3ee6fb261fd856036ced35bfb15b302b0b7
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
This will allow to remove AND/OR mix in identifying fields of composer
suggestion view.
Part of task-2741982
closesodoo/odoo#94999
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Before this commit, subtemplates in kanban did not share the same
ViewCompiler instance, thus losing the aggregation of the dropdowns.
Now, a single ViewCompiler is used for each KanbanRecord, properly
taking into account dropdowns declared in subtemplates.
closesodoo/odoo#94977
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
In the new Kanban view, clicking on a BooleanToggle field (on any card)
always toggles the field of the first card. We would like to toggle the
field of the card that is clicked on.
This is because the same id (fieldName) is used for all Checkbox
in the BooleanToggle. If you click on a label, its native behaviour is
to click on the input with the same id. In our case, this will always
create a click on the first ToggleBoolean (the first card).
The solution is to make the id passed to the field unique. To do this,
we will add the datapointID to it.
Before:
Card 1: id = fieldName
Card 2: id = fieldName
After
Card 1: id = fieldName_datapoint_1
Card 2: id = fieldName_datapoint_2
closesodoo/odoo#94966
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
This allows to remove the AND/OR mix from message view identifying fields.
Part of task-2741982
closesodoo/odoo#94948
Related: odoo/enterprise#28988
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Clean (demo-)data to be fully editor-friendly (i.e. use `<p><br><p>` instead of
`<br>` between paragraphs), fix some (grammar) typos.
Task-2893398
closesodoo/odoo#94943
X-original-commit: 87b4bc6d19fef947f7bf5d15835f17b9c2019902
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
The fix 1b80fe9 removed the behavior that made `.o_not_editable`
`contenteditable=false`. Without this behavior, other issues could
arises.
closesodoo/odoo#94889
X-original-commit: 4e7d6e1a70e44df3476c2602119fbcedc7c04199
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Purpose
=======
Currenlty an error is raise saying that a leave cannot be set accross
overlapping contracts.
But in this special case we could split the time off and allow this simple
action.
Taskid: 2836901
X-original-commit: 1012a7ea8033675b6ebab96922e124b04e5ed884
Part-of: odoo/odoo#94885
Purpose
=======
We currently prevent leaves overlapping several contracts to avoid messing
with the generated resource.calendar.leave.
In case the contracts are on the same resource calendar, this shouldn't be
an issue actually.
Taskid: 2836901
X-original-commit: 4e87c30bb136083153091e67e6dd9d9f64fa94c2
Part-of: odoo/odoo#94885
A forum tag is always linked to a forum.
But some flows are not considering that part and are returning/using
tags from other forum too.
Step to reproduce, having 2 forum `Cats` and `Dogs`:
- Create a `Food` tag on the `Dogs` forum
- On the `Cats` forum, type `Food` in the tag input
- First error: the `Food` from `Dogs` incorrectly shows up
It means that the user can't create a new one from the `Cats` forum
but will actually have to select (without know it) the one from the
`Dogs` forum.
- Select that tag anyway
- Second error: The tags displayed on the post is redirecting to the
wrong other forum, ultimately not showing the post from all forums
(and the one you just came from).
- Third error: The /tags page won't list the `Food` tag on the `Cats`
forum.
Note that there is probably some access traceback involved in a multi
website and/or multi company setup.
After this commit:
- only the tags from the current forum will show up and be selectable
when creating a post.
- it will be possible to create a new tag for a forum is another forum
already has a tag of that name
- the tag on the post (next to its title) will not redirect to the
incorrect (and possibly not accessible) forum
Note that the method was already reading multiple properties of `self`,
it was already not an `api.model` method anymore.
closesodoo/odoo#94917
X-original-commit: 4ff52d0b9a71d3072f5973d8e900d802e6b129c0
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Co-authored-by: hoangtiendung <hoangtiendung070797@gmail.com>
Probably introduced in PR changing rendering of chatter in form renderer that
changed timers in unfortunate situations.
Open form view utils was missing an await on (chatter container) render, but the
issue was not perceptible before.
closesodoo/odoo#95003
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Some payment tests were unexpectedly relying on the 'transfer' payment acquirer
to work because of a multi-company issue in the core payment tests setup.
This commit fixes the problem and adds an additional check in the tests to
make sure they rely correctly on the 'dummy' acquirer created in the payment
tests common.
closesodoo/odoo#94972
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
The _parse function of sanitize used to be recursive both along the
length and depth of the DOM tree, making it exceed maximum stack size
limit for long documents. This updated version is now only recursive in
the depth of the tree, not its length. It would be possible to write a
fully non-recursive version of this function but it is out of scope of
this task and is unlikely to happen anyway as DOM trees are way more
unlikely to exceed stack limits in depth rather than length.
task-2895671
closesodoo/odoo#94967
X-original-commit: c711a2c4106da0c2d5c35ee7a367ba86a9dcbdb7
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
"All" is capitalized but not "records".
It should be consistent: either all capitalized, none, or only the first word
closesodoo/odoo#94963
Related: odoo/enterprise#28990
Signed-off-by: Pierre Rousseau (pro) <pro@odoo.com>
Using `./odoo-bin` to start Odoo, the addons path can contain a `~`, eg
`~/Documents/whatever`.
Those `~` are accepted and work both with the `--addons-path` passed as
the command argument, or in the `.odoorc` config file.
The `@standalone` tests (launched with `./test_module_operations.py`)
however did not work with that `~` as the path was not "normalized".
Neither a `~` in the config file or in the `--addons-path` argument were
working.
While it is not very critical, it is a nice to have to have the same
behavior as the `./odoo-bin` as this made me lose quite some time
figuring why I couldn't use my usual `design-themes` repo addons path.
closesodoo/odoo#94953
X-original-commit: e633092a5932f24eda840e1decca92ed238a3a29
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
Co-authored-by: Xavier-Do <xdo@odoo.com>
Revert of
https://github.com/odoo/odoo/pull/92794
If you install pos_restaurant and open a PoS sale session, issue will start to appear after a certain time (about 1 minute):
For V15:
Javascript console logs will log errors:
`TypeError: Cannot read properties of undefined (reading 'id') Chrome.js:97`
For V15.2:
The products button will become unresponsive (so the PoS is unusable).
With error in the JS console as well:
`TypeError: Cannot read properties of undefined (reading '0') Chrome.js`
OPW-2889985
closesodoo/odoo#94938
X-original-commit: 965b797772becba0dbd7b978b5c422ba1474663a
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Commit [1] moved the edition of the website in the backend and
introduced an iframe as the editable. In doing so, some tour
actions became unstable.
The issue is that previously, when an action reloaded the page, the tour
service would reload as well. This is no longer the case and the tour
service stays active when the page is reloaded (e.g. when saving a
page). This can lead to a tour clicking on an item before it is ready to
be clicked.
Specifically in this case, the tour saved and clicked on edit as the
next step.
Clicking on edit before the page is properly reloaded leads to the click
being ignored.
This commit uses the util function `clickOnSave` which ensures we're out
of edit mode and the page is reloaded before doing anything else.
[1]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3b
runbot-4074
closesodoo/odoo#94932
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
A CSS comment in webclient_templates was written as a JS comment and
appeared as an invalid CSS rule in the devtools. This commit converts
that comment to use the proper syntax.
closesodoo/odoo#94925
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
In some cases, empty messages can be displayed in the portal chatter.
For instance, if a customer sends a message with no body and just
an attachment, and the attachment then gets deleted, it will still
be displayed as an empty message in the portal chatter.
To solve this, this commit filters out empty messages from the portal chatter.
Task-2833919
closesodoo/odoo#94828
X-original-commit: 10d2a3e01a0fb62860e502cc67e5311b9420a684
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
The website architecture has been refactored for the internal users and
admins with [1].
Now, they can access the website in the backend inside the website app.
Long story short, the website will be displayed in an iframe in a client
action. The URL of the browser will be tweaked to reflect the iframe one
instead of the real one (which is something like /web#action=..).
It had a few drawbacks:
- On page refresh (F5 or browser button), the user would land on the
frontend version of the website instead of remaining in the backend.
- When the user edited the URL (Like removing `/shop` and typing `/jobs`
instead, he would land on the frontend version too.
- Impossible to directly go to the backend version of the website.
Those are improved with this commit by using a slightly different URL
when we are in the backend. A `/@/` will prefix the iframe URL.
If logged in, the user will land on the backend. If not, it will simply
redirect to the frontend version of the website.
[1]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3b
task-2687506
closesodoo/odoo#94580
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Fix some uncommon nightly error on the runbot where a race condition
happened when the tour finished too soon. The test is successful but
during the browser cleanup, things are still happening.
task-2832564
closesodoo/odoo#91920
Related: odoo/enterprise#27600
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Sébastien Theys