Before this commit, on Chrome browser, the page url input and the
visiblity password input were autocompleted with the user's login and
password in the page properties options.
After this commit, they are no longer.
Regarding the url input page, it seems to be because Chrome considers
that the first text input located before a password input in the DOM is
a login input.
task-2502747
closesodoo/odoo#84393
X-original-commit: 7f45822919f8ef5f070a40a4dd41d22757a9da76
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
To reproduce:
1) Create a survey and open it with a portal user with its /survey/start/*** link
2) In a private window, connect as the admin and remove the answer in 'Not started yet' state that step 1 created.
3) Go back to your portal user window and re-enter the same /survey/start/*** URL.
==> The portal user is brought back to the home page. He has no way to access the survey anymore, the link will always redirect him there.
This is because of cookies. The first time the user opens the survey, it creates a cookie in his browser allowing him to reload the answer he was working on. In our example, this answer has been deleted for some reason (maybe some cleaning of too old 'not started' or 'in progress' stuff); so the token stored in the cookie does not correspond to anything anymore. Instead of crashing and redirecting to home page, this commit makes it so that we now ignore the cookie in that case, so that the user directly has access to the survey to build a new answer.
Task-2729738
closesodoo/odoo#84390
X-original-commit: c642be8e1bc682af2919c1cfadfdc267f005272e
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: Olivier Colson <oco@odoo.com>
To reproduce the issue:
1) Create a survey requiring user login, with multiple pages
2) Create portal user A and B
3) With user A, go to URL /survey/start/****, where **** is the access token of your test survey. Fill in the first pages of the survey, but don't finish your submission (so: the answer has to stay 'in progress').
4) Logout from user A.
5) From the same browser window (or without cleaning cookies, at least), directly login with user B, and go to the same /survey/start/**** link
====> The 'in progress' answer from A is loaded, even though we are connected with B and should hence not have access to it. Instead, we should have created a new blank answer for B.
This is due to our cookie management. When a cookie is kept in the browser with the token of a previously entered answer, we reload it without checking its owner.
Task-2729738
X-original-commit: 0be94b7f0bcb370bb8e8dea5febbc1c4a0b0cf86
Part-of: odoo/odoo#84390
To reproduce the issue:
1. Produce a SN product P with lot L
2. Unbuild it
3. Produce 1xP with lot L
Error: When setting the lot, an error is displayed. When marking the MO
as done, a second error is displayed
Both domains in `_onchange_lot_producing` and in the beginning of
`_check_sn_uniqueness` are incorrect. We should centralize the
uniqueness checking thanks to all existing computations in
`_check_sn_uniqueness`. This way, unbuilt/scrapped moves will be
considered
OPW-2721205
closesodoo/odoo#84374
X-original-commit: 2540104e95cea7baaa22ccfce97759771dbbaf34
Signed-off-by: Tiffany Chang <tic@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
We bring two changes to the API of useAutofocus:
- it takes no parameter, the element focused is the one that is the
target of a t-ref="autofocus".
- it returns the element reference instead of a function to call if
one wants to force the focus on a next patch.
Indeed, having access to the element reference makes it easy to focus
that element but also allow to remove an eventual useRef that would
target the same element. This in turn permits the use of t-ref="autofocus"
alone.
closesodoo/odoo#84306
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
In 6d13271aac, the API of useAutofocus was chanded but the calls to
useAutofocus in the module point_of_sale were not adapted accordingly.
We adapt them in this commit.
Part-of: odoo/odoo#84306
Purpose
=======
The existing resource.calendar.leaves are unlinked when refusing the
time off, but it could still be the case with python code changing
states without calling "action_refuse".
Make sure that the resource calendar leaves are always unlinked
on stage change for validated time off.
closesodoo/odoo#84269
X-original-commit: 83c283cb4256195975ec6dfb6096172d38393217
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Purpose
=======
The existing timesheets linked to a time off are unlinked once the
time off is refused (which is the only action on the interface for
validated time off).
But nothing prevents to set in a python code a time off directly
in draft to validate it afterward.
In that case, the timesheet is duplicated and is impossible to unlink
as this is forbidden for timesheets linked to a time off.
Specification
=============
Make sure before creating timesheets linked to a time off that there
is not remaining linked timesheets.
On the other hand, modify the method to generate the timesheets in batch.
X-original-commit: 46a3394b960ba344d49a4e99ae5a6a7d7392dbf6
Part-of: odoo/odoo#84269
Filtering stock_pickings by selecting the product in the dropdown menu doesn't return anything
Steps to reproduce:
1. Install Inventory
2. Go to Inventory > Operations > Transfers
3. In the search field, begin typing the name of a product for which there is a transfer (e.g. Large Cabinet)
4. Click on the small arrow to the left of `Search Product for:` in the dropdown menu
5. Select the product you were typing
6. There is no result to the search even though there are transfers containing the product
Solution:
Remove `filter_domain`
The filter will be handled in the backend by `_name_search` of `product.product`, which already covers the same criteria (`default_code`, `name` and `barcode`)
Problem:
The display name (e.g. "[E-COM07] Large Cabinet") wasn't matched by the `filter_domain` because the domain sent in the RPC was:
```
"domain": [
"|",
"|",
[
"product_id.default_code",
"ilike",
"[E-COM07] Large Cabinet"
],
[
"product_id.name",
"ilike",
"[E-COM07] Large Cabinet"
],
[
"product_id.barcode",
"ilike",
"[E-COM07] Large Cabinet"
]
]
```
OPW-2732804
closesodoo/odoo#84388
X-original-commit: abd951b084422f8083764db3ec4441954cccfad1
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Signed-off-by: Guillaume Merlin (megu) <megu@odoo.com>
A modification made by Amazon on October 1st restricts the allowed
values for the carrier name. Since it now expects it in a formatted
state, this commit will allow Odoo to send the delivery type of the
carrier rather than its name, which can be customized by the user.
opw-2665099
closesodoo/odoo#84291
X-original-commit: 0b4530b124d4ac86dad34907c6d6b6e9ea69c7b6
Related: odoo/enterprise#24204
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Signed-off-by: Morgane Demesmaeker <edm@odoo.com>
Before this, running Chrome was only supported on POSIX-type OS.
This commit adds support for running Chrome on Windows, by swapping
fork()/exec() with `subprocess.Popen`, which is
cross-platform. Linux-specific fixups are implemented via a
`preexec_fn`.
Also fixes the JSON path generation: the url path separator is `/`,
not `os.path.sep`.
closesodoo/odoo#83209
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Since Owl 2 changes in compatibility layer, destroy hook is called from the
compatibility layer on a component already destroyed (from the documents mixin
in this case).
There is probably a fix to do in the compatibility layer, but the current PR is
an easy fix to avoid the crash on the documents app in the meantime.
task-2761082
closesodoo/odoo#84364
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Step to reproduce:
- Create a event in outlook with a long description
- Load the event in Odoo
Current Behaviour:
- Odoo use the body preview to get the event description
If the body is longer then, the description in Odoo is incomplete.
Behaviour after PR:
- Change fetch option to get description as text
- Use body['content'] as description which is the full body.
opw-2746358
closesodoo/odoo#84362
X-original-commit: c2b545fd8d91b7d24380ada07adee02f24623ecf
Signed-off-by: Arnaud Joset <arj@odoo.com>
In mass_mailing:
1. Click CREATE
2. As soon as it appears, click "DISCARD"
3. Wait a little bit
-> A traceback appeared.
That is because wysiwyg was still busy starting and, in that process,
requested the window object of the iframe that was already removed.
closesodoo/odoo#84358
X-original-commit: 48ce4f0f834b55692e32868194a635b817c6ed13
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
When choosing the empty template for mass_mailing, it was confusing to
face a blank page with a tiny dropzone. With this we adopt the website
builder's solution, which is to include a message when the page is
empty. That message functions as a bigger dropzone.
task-2734469
closesodoo/odoo#84356
X-original-commit: fbe048c202ff7878984adf26bef0651a45851f0a
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
When saving a mailing with the link tools open, link tools' destroy
is called after OdooEditor's destroy, causing a traceback when link
tools tries to set a history step.
task-2733825
closesodoo/odoo#84354
X-original-commit: f565f965fdc15d744efd38cfca9b098e24181e7e
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Previous versions of backorder mechanism would trigger reordering rules
for components of backorder MOs. This could lead to a procurement_group
mismatch (see original commit for details).
Backorders no longer trigger reordering rule, but it is still safer if
we clean the default_mo_ids when making backorders just in case. One
rare use case would be: if a user deletes multiple MOs'
procurement_groups, then creating backorders for those MOs at the same
time (i.e. via list view > multi-select + action > Mark As Done) can
result in incorrect procurement_group assignment due to default value
(same reason as explained in original commit).
closesodoo/odoo#84351Fixes: odoo/odoo#83742
X-original-commit: e3af56520fc3397f24c05b64d991f28a3227262b
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Signed-off-by: Tiffany Chang <tic@odoo.com>
Steps :
- Make sure the Admin is notified by mail;
- Set an Alias Domain for the company.
- Create a Project with an Alias e-mail address.
- Send an e-mail to this alias.
Issues :
In the admin mailbox, see the signature is: `<p>-- <br/>False</p>`, which means two issues.
- It is not unescaped from Html.
- The content of the signature is 'False'.
Cause :
When no user is related to the sender of the mail, we manually set a signature.
- It was written between html tags, so it should be sanitized.
- Its content was author.name, yet author is a partner, so if there is
no partner, name is False.
Fix :
- Sanitize the html code of the signature.
- If there is no partner for this sender, use email_from, or else ''.
opw-2728483
closesodoo/odoo#84329
X-original-commit: a1ac9c8171742c5622e5f310cec2fe4ab53c2717
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: Onockx Audric (auon) <auon@odoo.com>
The PR #44537 changed the method _createVideoNode to be async while
the wysiwyg still called the method as if being sync.
This commit adapt the code to be asynchronous.
Task-2727906
closesodoo/odoo#84327
X-original-commit: 683de2b41c2e3699c39126852c82f1bb988bd3e9
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
This commit improves two things:
1) Avoid filtering on the whole sale.order.line recordset every time,
just to check if the products is in the order.
2) Use += instead of |= to build the result. += is much more efficient
and we can trust the result is not going to have duplicates anyway,
since we're looping through the recordset.
closesodoo/odoo#84217
X-original-commit: 0d1f8ae6e983e0f8aec459513c3d386e9e4908bd
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Before this commit* the flex parent of the discuss element
was no longer in the `column` direction, which caused an overflow in
some of its children elements, like the topBar and the composer.
This commit fixes this issue by setting the `flex-direction` of the
discuss parent to its former value.
* since https://github.com/odoo/odoo/commit/cbe1bc809538f690115e1632448258663e1f52e4closesodoo/odoo#84290
X-original-commit: f902efa94baed8d0bf5aae6f4314891c5c2b57a1
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Step to reproduce:
1) create a product with, the "Product Type" as
"Storable Product" + A "Product Category" with a "Costing Method"
set in "FIFO" mode and the Inventory Valuation in "Automated".
2) create a Purchase Order for 1 unit of that product and set the unit
price to 10.00. Confirm Order -> Receive Products -> Validate
(the delivery) -> Apply
3) create a second Purchase Order for 1 unit of the same product but
set the unit price to a different price, like 20.00. Confirm Order ->
Receive Products -> Validate (the delivery) -> Apply
4) create a Sales Orders for 1 unit -> Confirm -> Smart button
Delivery -> Validate -> Apply
5) check the cost on the product form of that product.
On the V13 it will be $10, so its the last unit that left the stock
On V14 and upper, it will be $20, so the next product that will leave
the stock.
The help popup for the field "standard_price" doesn't reflect the
correct behavior. It's the standard price for the next unit instead
of the last one.
closesodoo/odoo#84289
X-original-commit: 9e0a529b603302653dac2a8fb692472fc500c147
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Bruno-brsy <brsy@odoo.com>
Before this commit, in the BoM Structure & Cost report, the By-Products
line quantity, product cost and BoM cost were misaligned.
The issue happens once the `mrp_mpl` module is installed because then,
the number of columns changes.
closesodoo/odoo#84278
Signed-off-by: Tiffany Chang <tic@odoo.com>
Steps to reproduce the bug:
- Login as Marc Demo
- Go to any product and try to print labels
Problem:
An access error is triggered, the basic user needs to have the access rights "Administration / Settings" to be able to print product labels
Solution:
Administrators and basic users should be able to print product labels
opw-2746963
closesodoo/odoo#84285
X-original-commit: 03442d92d6f95cbb4d6e0b69dde36272f6b6dbcd
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
Before this commit, when the current user is in project sharing and see
the form view of a task with at least a subtask. He cannot create
another one because of an error in the `_compute_portal_user_names`
method. Indeed, it is because we want to update the cache to get the
user_ids of the task related since the portal user cannot see the
users assigned to the task since he cannot access an internal user. This
update cache is made by calling the `_read` method but this method
checks after having fetching the data if the self is equal to the
recordset fetched. If the `self` contained newIds, then the method will
raise an error because a Task with newId != Task with id in db.
This commit fixes the compute method to call the _read method only on a
self with no NewIds to avoid this issue and correctly updates the cache
to get the name of the users assigned to a task in project sharing for
the portal user.
Fix found by Florian Damhaut <flda@odoo.com>
Co-authored-by Florian Damhaut <flda@odoo.com>
opw-2745857
closesodoo/odoo#84298
X-original-commit: f61c4f43365d38a955c497e022f0e8f18f50a6b2
Forward-port-of: #84189
Related: odoo/enterprise#24207
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
Before this commit, the portal user is assigned to the subtask if he
creates a subtask via the project sharing feature. We recently hides the
`Assign to me` button to those users.
This commit removes the `default_user_ids` in the context used when we
create a subtask in the project sharing feature to not assign the user
to that new subtask.
Related PR: #84006
X-original-commit: f3a241e97f80007f6d7ce2567dd22784cb35de26
Forward-port-of: #84189
Part-of: odoo/odoo#84298
1. Create a SO in Sales App.
2. Open POS session.
3. Load the SO in POS.
4. Select "Apply a Down Payment". Insert any percentage (eg: 50%). Pay
5. Go back to SO in Sales App.
6. Deliver the product.
7. Create an Invoice and apply the down payment.
8. Open the draft invoice and delete it.
Downpayment made on POS is unlinked and cannot be reinvoiced.
This change will avoid deleting the downpayment if it is coming from the
POS. As that the order is validated in the process, it should
be not possible to modify/delete it anymore
opw-2744281
closesodoo/odoo#84140
X-original-commit: 0b1e2be9b6d41c53fdec718b576ba794b9c020ac
Signed-off-by: Grazioso Andrea (agr) <agr@odoo.com>
- Open any record with a chatter (i.e. a SO)
- Log a note with a mention to any res.partner
- Edit note and save
The mention is not a link anymore, but just plain text.
During edition the list of mentioned partners is not retrieved correctly,
preventing function that generates links from mentions to work properly.
On client-side, a variable named MentionedPartners is used to generate
mention links when posting a message.
It should contain the id and name (to match the mention text) of each
mentioned partners.
During edition, MentionedPartners is empty, leading to this issue.
As the list of mentioned partners is stored in message model in partner_ids
field, "id" and "name" of partner_ids will be retrieved and added to messages
data when requested by client side.
This will allowed to populate MentionedPartners with all required data.
Note that retrieving "name" from partner_ids will add an extra query,
as seen in the modified test.
opw-2739665
closesodoo/odoo#84152
X-original-commit: 510764730057b20a1706ae20d50549e280f7f9a7
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Steps to reproduce the bug:
- Install pos_sale
- Connect as Admin
- Create a SO with qty > 1
- Create a new user and give him:
- “Administrator” access to inventory
- no access to POS
- Connect with this user
- Go to the SO created by the admin > delivery
- Try to validate a partial delivery and create a backorder
Problem:
Traceback is triggered, because we are trying to read the `pos_order_line_ids` field while the user does not have access to POS
opw-2746938
closesodoo/odoo#84248
X-original-commit: bdd20fa37a73436788c470190d7fbf5e4c83f913
Signed-off-by: Masereel Pierre <pim@odoo.com>
Due to floating poing imprecisions, the position hook
overflow computations may be off under some hard to
predict circumstances.
This commit ceil all the compared parts in order
to have the same base of comparison.
closesodoo/odoo#82434
Related: odoo/enterprise#23337
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
Prior to this commit the 'disabled' state (eg. studio icon in a
not-editable view) and the 'no-notification' state (eg. messaging icon
without badge) shared the same design.
While the disabled state should be used for not-clickable elements only,
available systray items should always appear clickable, even
when there are no new notifications.
This commit moves the `o_disabled` class outside the burger_menu
component, making it generic and available for other components too.
Systray items without notification are now styled normally.
The simple presence of the badge communicates the user that a new
notification has been sent.
This commit is part of v16 overall restyle (task-2704984).
task-2712151
Part-of: odoo/odoo#82434
This commit fixes the profiling menu item design, simplify the css and
removes several lines of vendor-prefix animations no longer necessary.
This commit is part of v16 overall restyle (task-2704984).
task-2712151
Part-of: odoo/odoo#82434
Benjamin Vray