Steps to reproduce:
- Install timesheet
- Archive an employee
- Create a timesheet
Current behavior:
You can select the archived employee
Expected behavior:
You can not select the archived employee
Explanation:
In commit 17b2b07 the employee_id
field of the timesheet was set to have context active_test to false.
To fix this issue we reset the context for this field in every
timesheet form and we add user errors if the employee is not active
while the timesheet is created or edited.
opw-2887727
opw-2870739
X-original-commit: f034ca05b9602592a5ed140849e20738470ee292
Part-of: odoo/odoo#95644
Previously, the test runner would evaluate an expression to check if the
browser test that is about to be run is ready, but before the test is
ready, this expression may be invalid as the variables used in the
expression may not be defined yet, causing a ReferenceError to be thrown
by Chrome.
In Chrome >=102, errors that are thrown when writing code in the console
or by using Runtime.evaluate over CDP are thrown in the context of the
current tab, which means that they trip registered error handlers in
that tab. In Odoo, this means that we show error dialogs with the
traceback.
In the tour manager, when we are looking for an element to trigger, we
only look for that element inside dialogs if there are any dialogs open
(unless the in_dialog option is false on that specific step). This means
that if an error dialog is open, most tours will fail (which is actually
what we want).
In order to avoid opening a bunch of error dialogs while waiting for the
tour to be ready, we simply wrap the ready expression in a try catch so
that it doesn't throw an error, and simply returns a undefined until the
tour is ready instead of throwing a ReferenceError.
closesodoo/odoo#95635
X-original-commit: 3872dbd63233d4c6d961a3cd896b84e4301a1f84
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Signed-off-by: Samuel Degueldre <sad@odoo.com>
Before this commit, a class was missing when the monetary field was on
edit mode. This results in a non-alignment between the monetary symbol
and the value.
closesodoo/odoo#95620
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
The default order of the picking moves generated from a purchase order should be the same order as the purchase order lines.
Steps to reproduce:
- Create a purchase order with several purchase lines.
- Change the order of the purchase lines.
- Confirm the purchase order.
=> The moves of the picking don't maintain same order as set before.
closesodoo/odoo#95582
X-original-commit: c18b2ce767dd5a5b4dbe766b849b56243dffb723
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Due to business decisions knowledge is moved to enterprise repository. As
some other moves are planned, notably coupon or the complete responsible UI
and support that are coming to community Odoo feels like knowledge belongs
to enterprise applications.
Planned move from enterprise to community are
* mass mailing themes;
* mobile UI;
* complete coupon and loyalty cards support;
* spreadsheet library;
For any questions please refer to decision makers.
Task-2900765
X-original-commit: 9ba76621dc66fcf672ce514a47cc933bd9462f38
Part-of: odoo/odoo#95556
The deprecated exists check(located in getFieldValue (ModelManager)) is removed,
but a lot of tests will fail after removing this check because it will try to
read fields after records are deleted. So added some missing exists checks.
Task-2871062
closesodoo/odoo#95415
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Before this commit, field command was returning incorrect value if the
channel_partner was a guest. At the very least we have to return a `clear`
command.
closesodoo/odoo#95411
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Before this commit, the record was given to `field.extractProps`
so it could return props based on the record.
Now, only the attrs and field is given so it can be called
only once when parsing the arch (except for kanban).
closesodoo/odoo#95389
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
In the web client, in a real use case, it's not possible
to write on fields which are invisible,
as it's not possible to write on fields which are readonly.
This is a first step in the goal to change the behavior
of the `groups=` attribute in the back-end views,
to remove them for the view instead of making them invisible.
This is mainly to reduce the diff of the revision that will introduce
the mentioned above behavior change.
As nodes with `groups=` will be removed from the view
when the user doesn't have the group, it's no longer possible
to set a value on a field having a `groups=` the user doesn't have
in the `Form` test class, as the field will no longer be at all in the
view.
However, these unit tests shouldn't have been able to set values
on invisible fields in the first place.
This revision therefore aims to correct the unit tests setting value
on fields which were invisible because the user executing the
test was not part of the required group(s) for these fields
to be visible in the view.
closesodoo/odoo#94337
Related: odoo/enterprise#28936
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
* website_forum
Portal users cannot insert images in the WYSIWYG, eg in a forum post.
Steps to reproduce:
- Install website_forum
- Connect as portal
- Go to the forum and create a new post
- Type '/image' and try to insert an image
- An Access Error is raised preventing the portal user from inserting an
image
History:
- It was possible in version earlier than 15.0 before the new editor, as
it was using a base64 inplace image upload to bypass the access rights
and avoid creating an attachment.
- It was broken in 15.0 with the new editor which doesn't have such a
mechanism. The image upload was then disabled for those users in 15.0
with [1] to avoid that bad UX with those errors/tracebacks.
- It was decided to implement a clean solution in master and see from
there was will be done with 15.0 (as being able to upload an image on
a forum seems quite critical).
Solution here in master to be able to use the media dialog:
- First issue, about opening the media dialog:
It fetches attachments, which is raising some access errors. We now
catch the error silently and return an empty list.
- Second issue, about upload an image (and thus creating an attachment):
We now create attachments with sudo to allow access to portal users,
but only if he has write access on the model.
[1]: https://github.com/odoo/odoo/commit/e453d4c119a69f285d9a014babe485492bbe9c40
opw-2648770
task-2811325
closesodoo/odoo#82612
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Co-authored-by: Merlin (megu) <megu@odoo.com>
Before this commit, all radio buttons were on horizontal style,
the o_vertical class was not taken into account.
closesodoo/odoo#95553
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Use the dutch fields 'l10n_nl_oin' and 'l10n_nl_kvk' after checking
for their presence. Otherwise, we could get traceback like:
'AttributeError: 'res.partner' object has no attribute 'l10n_nl_oin''
closesodoo/odoo#95595
X-original-commit: 9623e29ede99eeff90eab1178560eb673ed1c3c9
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Julien Van Roy <juvr@odoo.com>
Before this commit: if one of the orders is corrupted, it will print an empty report.
The solution is to print corrupted orders in the report.
opw-2867770
closesodoo/odoo#95590
X-original-commit: 2acc2e7294997836e071cd3f3de4653125ca306c
Signed-off-by: Masereel Pierre <pim@odoo.com>
Signed-off-by: Pedram Bi Ria (pebr) <pebr@odoo.com>
Since Odoo v15, user can rename invoice to a custom value. Odoo automatically
detects `sequence_number` for the new name. If no number is detected, the
`sequence_number` is set to zero. In this edge case, method
`_is_end_of_seq_chain` doesn't work and raises an exception, because `last_rec` is
empty, while `_get_last_sequence` has constrain `self.ensure_one()`.
Fix it by allowing `last_rec` with zero `sequence_number`.
STEPS:
* Create invoice
* Confirm
* Reset to Draft
* Rename invoice to "Test"
* Save
* Try to delete the invoice
BEFORE: ensure_one error
Once it's fixed, we face another problem: User Error *You cannot delete this entry, as it
has already consumed a sequence number and is not the last one in the chain. You
should probably revert it instead.*
It happens because `sequence_prefix` is computed as empty string, while
`_get_last_sequence` method ignores empty values. Fix it by allowing search by
empty string too.
AFTER the two changes user can delete draft invoice
opw-2861841
closesodoo/odoo#95614
X-original-commit: 301b499b9d0ce189dc5d0433e55ce654d212927b
Signed-off-by: William André (wan) <wan@odoo.com>
Before this commit:
Changing header style with triple click selection bring changes to the next
line, which it should not.
After this commit:
Now even after triple click selection the change stays with the selected part.
Task-2810134
closesodoo/odoo#95613
X-original-commit: dd64fc7730ef34d715cfb2146a7ef8a7ba98f34e
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Search count on large tables can be very slow (it takes 4s to
search_count the list counter of res.partner on our production DB)
This will allow to display a 10000+ counter for large DBs.
closesodoo/odoo#95589
Signed-off-by: Fabien Pinckaers <fp@odoo.com>
3-steps delivery. A user confirms a SO with a storable product, it
generates 3 pickings (pick, pack, ship). On the Forecasted Report of P,
there is a line for that SO. A button is available (Reserve) but if the
user clicks on that button, it won't do anything (even if there are some
P in stock).
The Reserve button is linked to the ship SM, so trying to assign it is
useless, we first need to process the pick/pack steps.
In such situation, displaying the button is confusing.
OPW-2784998
closesodoo/odoo#95578
X-original-commit: 71769d536118da8e35dd18672b5d6c74a2180310
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Before this commit, when a new domain is created with a list of rules
and in one of those rules contains a PyDate/PyDatetime object in a
right leaf, this leaf will be converted into a plain object instead of
keeping the initial object.
For instance:
```js
a = new Domain([['date', '=', PyDate.create({day: 1, month: 1, year: 1970})]])
a.toList() // result: `[['date', '=', {day: 1, month: 1, year: 1970}]]`
```
Since it is a plain object, when the result will be passed to the
server, the final result will be an object in a string instead of giving
the utc date formatted.
This commit fixes this issue by checking if the object instances of the
`PyDate` or `PyDatetime`. If it is the case, then the ast type will be a
string and the value will stay the same instead of creating a plain
object and the ast type which determines a JSON.
closesodoo/odoo#95570
X-original-commit: be5c8d0fc340b3e2ad9721d21ef1133870d8a774
Signed-off-by: Géry Debongnie <ged@odoo.com>
Signed-off-by: Xavier <xbo@odoo.com>
Currently, when a BOM is archived via the ECO mechanism, its operations are
still selectable via the `copy existing operation` action on the BOM.
In this commit, we have added domain in `copy existing operation` action.
TaskID - 2845022
closesodoo/odoo#95548
X-original-commit: 272cd5358e8b78bc273d4aa72b8c42649f1f5171
Signed-off-by: Tiffany Chang <tic@odoo.com>
PURPOSE
Fix flows involving moving articles (with or without parent) as well as setting
articles as private or archiving articles. Members are not always correctly
synchronized, detached or managed.
SPECIFICATIONS
1/ Fix move to private section
The issue can be reproduced by doing the following:
* Create an article in the workspace section
* Invite an internal user with write access (e.g: "Marc Demo")
* Drag and drop it to the private section
* Stack trace
Two separate issues:
* the _check method in the article model should not be based on a SQL request
* the move to an private section should check member integrity after all members
are updated;
2/ Fix archive mechanism
The issue can be reproduced by doing the following:
* login as "admin"
* Create an article in the workspace section
* Invite an external user on this main article (does not matter, e.g: Azure Interior)
* Create a child article to this article
* On this child article, set Marc Demo as permission "none"
* login as "demo"
* Archive the main article
* login as "admin" again
* The child article should be moved as root
* The child article should have the invited external customer copied onto it
3/ Fix private propagation
The issue can be reproduced by doing the following:
* Create an article in the workspace section
* Create a child article to this article
* Invite any user on this child article (does not matter, e.g: Marc Demo)
* Move the main article to the private section
-> The child article still has its internal permission set to "write"
instead of inheriting from its parent ("No access")
-> The child article should not have "Marc Demo" as member anymore
In addition, the same logic as the archiving on point 2 applies. If you don't
have access to a child article, it should NOT be moved to private (and instead
made root).
4/ Various fixes spotted when working on previous fixes
See commits of this PR for more details about fixes and code improvements.
Task-2859616 (members permissions management)
Task-2901990 (sorting)
closesodoo/odoo#95471
Forward-port-of: odoo/odoo#94836
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Co-authored-by: Aurélien Warnon <awa@odoo.com>
In this commit we add some explicit checks in methods managing members when
they are intended to be used directly. Some internal methods do not check
for ACLs / access, in which case a note is added in docstring to be clear
about it.
Task-2859616
X-original-commit: odoo/odoo@b2b1aeb099
Part-of: odoo/odoo#95471
Surprisingly ``_filter_access_rules_python`` returns a sudo-ed recordset. We
do not want to call super in a write as sudo, even if the recordset has been
filtered based on current user's ACLs.
In this commit we reset the recordset environment to the current user's one.
Task-2859616
X-original-commit: odoo/odoo@a41d4b9ce1
Part-of: odoo/odoo#95471
Co-authored-by: Aurélien Warnon <awa@odoo.com>
Currently, when archiving or moving an article to private, we "detach" children
of that article to which the current user does not have (write) access to.
This essentially means that these unreachable articles are detached from their
parent and set as root articles. See ``_detach_unwritable_descendants' for
more details.
However, during that process, we incorrectly considered only the direct
children of the archived / moved article.
This commit fixes it by taking into account the whole hierarchy that is going
to be modified, as archiving and making private actually propagates to all the
(reachable) article children.
Task-2859616
X-original-commit: odoo/odoo@a31f48dfa4
Part-of: odoo/odoo#95471
This commit fixes the case when we have desynchronized children for which the
current user does not have write access and we move the parent to the private
section (or archive the parent).
In that case, children that are desynchronized should not have the members from
their parents copied onto them when detaching.
See '_detach_unwritable_descendants' and associated tests for more details.
Task-2859616
X-original-commit: odoo/odoo@348740fa9f
Part-of: odoo/odoo#95471
Currently, when moving an article to the private section, its children are
untouched and keep their access rights.
This is incorrect: when making an article private, all (accessible) children
should be made private as well.
See 'knowledge.article#_make_private' for details.
An exception is made for children articles to which the user does not have a
write access to.
Those are handled as the following (same as archiving flow):
- They become independent from the parent
- They are moved as "root articles"
- The potential specific member access from their parent(s) are copied
To avoid loosing access if specific members where configured on the parent(s)
of those articles, since they will no-longer inherit from them.
Tests were added to enforce this behavior.
Task-2859616
X-original-commit: odoo/odoo@82af404c5b
Part-of: odoo/odoo#95471
Currently, when archiving an article, if you don't have write access to some of
the children of the article, we do not archive them and do some extra
post-processing.
Meaning:
- They become independent from the archived parent
- They are moved as "root articles"
- The potential specific member access from their parent(s) are copied
To avoid loosing access if specific members where configured on the parent(s)
of those articles, since they will no-longer inherit from them.
This last part was not working properly and has been fixed.
Existing tests have been adapted to ensure the behavior is kept.
Task-2859616
X-original-commit: odoo/odoo@b35f2ace22
Part-of: odoo/odoo#95471
This commit fixes the check that verifies that the article always has a member
with write access on the article.
Indeed, the current code was using a database request to check for members with
write access in a "api.constrains" check, where the data being updated is not
flushed into database yet.
It now correctly uses fields access directly, as stated by the method docstring.
For convenience, we extracted the "_has_writer_member" method to be re-usable.
An additional test case has been added to enforce the behavior.
Task-2859616
X-original-commit: odoo/odoo@ccdfb791f8
Part-of: odoo/odoo#95471
Purpose of this commit is to have less check on "is writable" constraint from
member model. With a new context key we can now bypass the constraint from
member model when we are sure it is globally verified. As in some cases we
modify members from an article, the constraint will be checked at article
level with all members being updated. In some cases doing specific checks
might lead to issues when the constraint is evaluated in a transient state
e.g. when a member is removed while new write members are not yet added.
Task-2859616
X-original-commit: odoo/odoo@a4aa856902
Part-of: odoo/odoo#95471
Co-authored-by: Aurélien Warnon <awa@odoo.com>
Co-authored-by: Thibault Delavallee <tde@odoo.com>
Reading is_user_favorite requires access on intermediate favorite model. It
is however not accessible to public users. Reading the field therefore raises
an error which is not necessary.
We can simply set the field to False as public users can not set articles as
favorite and skip the whole computation.
Task-2859616
X-original-commit: odoo/odoo@fe854b3636
Part-of: odoo/odoo#95471
Correctly set write access rule to write (and create) instead of being global.
Read rule for internals and portal users is based on has_access field. Also
add some additional details in rules name to make their name explicit and
understand the rule purpose at a glance.
Task-2859616
X-original-commit: odoo/odoo@ba05b7a87c
Part-of: odoo/odoo#95471
Improve performance of search on favorite articles by using _search. This
allows to have less specific queries and use ORM capabilities.
Task-2901990
X-original-commit: odoo/odoo@ed72a92be3
Part-of: odoo/odoo#95471
Co-authored-by: Aurélien Warnon <awa@odoo.com>
Several issues with article model ordering have been found and are fixed
in this commit:
* default order of model as ``favorite_count`` currently ascending while
we actually want most favorite articles to be on top;
* when searching sorted articles per user, we use the sequence on favorite
model. When ordering on this field we therefore have to fetch all favorite
articles and then order them based on user's sequence. Otherwise when
having more favorite articles than asked the user's sequence is not
taken into account;
* specify order in various searches to make it explicit;
Task-2901990
X-original-commit: odoo/odoo@bbabb2fdb6
Part-of: odoo/odoo#95471
Purpose: remove custom data in tests when possible, try to re-use existing
data. Improve default data to cover most use cases without being too much
complex to handle.
Add information to clearly explain hierarchy and better understand tests
impact, in common classes or specific tests generating their own test
structure.
Check tests effectively test what they intend to.
Task-2859616
X-original-commit: odoo/odoo@de92822ac4
Part-of: odoo/odoo#95471
This commit contains some post-merge cleanup in knowledge tests before adding
some new tests
* remove an unused common file, holding unused data;
* some rephrasing and cleanup in comments;
* move fields specific test into an "internal" file that holds tests for
computed fields notably;
Task-2859616
X-original-commit: odoo/odoo@bad3ee069e
Part-of: odoo/odoo#95471
This commit extracts logic necessary to make an article private from move_to
into its own method. This helps understanding what is done and allow to be
called in other flows. Indeed moving under another parent and making private
are actually quite different flows.
This is a preliminary work to introduce the next fixes that will add changes
necessary to correctly handle private articles update.
Task-2859616
X-original-commit: odoo/odoo@6a3f07e384
Part-of: odoo/odoo#95471
This commit extracts the logic in "action_archive" that detaches children
articles to which the current user does not have access to into a separate
method. See 'KnowledgeArticle._detach_unwritable_descendants()' for details.
This is a preliminary work to introduce the next fixes that will apply that
logic when making an article private as well. There should be no functional
change with this commit.
Task-2859616
X-original-commit: odoo/odoo@94ed05d6e8
Part-of: odoo/odoo#95471
We hide all pos-related config options when no pos is selected to
unblock users from saving the general settings.
closesodoo/odoo#95464
Signed-off-by: Masereel Pierre <pim@odoo.com>
This allows to create a repair.order record without
the need to call the onchanges to set the uom and locations
or to set them manually during the `create` call.
For instance, this makes easier to create repair orders
using XMLRPC when you do not use multiple UOMs or multiple locations.
closesodoo/odoo#95321
Signed-off-by: Raphael Collet <rco@odoo.com>
Sometime Paypal took 3 or 4 days for some payment verification due to
weekend. This raises the retry limit days for 4 days instead of 2 to
solve the issue
closesodoo/odoo#95522
X-original-commit: 5aaaaf8f072b3f8ab66a269bb3dba02714b593ad
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
When replacing an image by a pictogram, the classes of the previous
media are copied to the new icon's `<span>`. This potentially includes
the `w-100` class which prevents the alignment from behaving correctly.
This commit removes the `w-100` class if it exists.
Steps to reproduce:
- Drop a "Media List" block
- Replace first image by pictogram.
- Align icon to the right.
=> Icon was displayed aligned to the left.
task-2829971 (was task-2729177)
closesodoo/odoo#95287
X-original-commit: https://github.com/odoo/odoo/commit/8f71a3c55dcaae738fbb673266aa400b4c4a1fa4
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Since [1] when the media dialog was refactored to owl, some of the
classes clean up when switching across media types were lost.
This commit restores the clean up for each media type - as they were
before [1].
Steps to reproduce:
(Just one example - there are many scenarios)
- Drop a "Text - Image" block.
- Apply a rounded circle on the image.
- Replace the image by a video.
=> The rounded circle effect remains but cannot be removed.
[1]: https://github.com/odoo/odoo/commit/7fd0698cf765a79959566b51e33cb76bff83d344
task-2829971
Part-of: odoo/odoo#95287
Each cookie binds to a domain name, multiple cookies can be set for the
same name if they are for different domain name. In this case, two
`session_id` cookies were set: (1) the first set right on the opener at
`opener.cookies[...] = ...`, (2) the second set upon inside of
`http.Request._save_session` because the session was rotated upon login.
The problem is that the former cookie (the one set on the opener, the
one *not* rotated) was used instead of the second cookie (the one
holding the registered user) in the subsequent queries. There is a long
comment explaining the same problem inside of
`odoo.tests.common.HttpCase.authenticate`, we used the same solution as
they did inside of `authenticate`: we diched the previous opener.
closesodoo/odoo#94773
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
Due to an oversight, the "Save my payment details" checkbox was shown on
the inline payment form of SEPA Direct Debit acquirers, which should
never happen because the transaction is *always* tokenized with those.
With this commit, the `_is_tokenization_required` method is slightly
refactored to read the provider from the current `payment.acquirer`
record rather than from the kwargs. This conveniently fixes the issue
and prevents it from happening again elsewhere.
closesodoo/odoo#95519
X-original-commit: ebeebd87ed6d687b96dda3006b81356dfa76d0a0
Related: odoo/enterprise#29237
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Steps to follow:
On a runbot,
- Login as Mitchell Admin
- Set the Administration permission of Marc Demo to Access Rights
- Login as Mark Demo
- Go to the Discuss App
- Edit a message from someone else by clicking on the pencil
-> A Traceback occurs
Cause of the issue:
- The pencil button is only displayed for another user if the logged in user
is admin. This is done by checking if the user is superUser or if he
has the group `base.group_erp_manager`
This is the case here
- When editing the message, the `base.group_system` is checked.
In this case, it is not present.
Solution:
Check the `base.group_erp_manager` in both cases
opw-2892740
closesodoo/odoo#95502
X-original-commit: bd8ed439d1d9342b24926eee332e8c26c6f0cd7c
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Signed-off-by: Hubert Van De Walle <huvw@odoo.com>
Since the new kanban view [1], the kanban card layout of the channels
had a weird alignment of its inner elements.
This is due to the fact that now the "kanban-box" defined in the arch
is wrapped inside the div.o_kanban_card instead of being merged with it.
[1] 3d6c13ff3fclosesodoo/odoo#95493
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
mafo-odoo