Before this commit, when the current user is in the '/my/projects'
route and selects a project the route becomes '/my/project/<id of
project>'. There is no reason to change the route and then adding the id
of the project. In sales order route, we keep the route and we add the
id of the SO to see the portal form view of the SO selected.
This commit renames the route of project and task form view to keep the
same route and the same logic of SO and quotations routes for instance.
task-2648955
Closes#82379
Before this commit, the portal user can see the parent stat button in
project sharing form view of task if the parent is in the same project.
This button can be clicked and it redirects the user to the parent task
form view in the project sharing.
This commit improves this button and its visibility in project sharing
feature. The button is visible only if the current user has access to
the project of the parent task. That is the privacy visibility of the
project should be set to 'portal'. If the portal user has access to the
project of the parent task and he is not a collaborator of this project,
then the current user will be redirected to the classic portal view of
the parent task. If it is a collaborator then we display the parent task
in the project sharing feature.
task-2648955
Closes#82379
Before this commit, in project sharing feature, when the portal user is
in task form view, he can see the sale order stat button if a sale order
is defined in the task but this button is disabled.
This commit allows the portal user to click on this stat button if he
has access to the sale order of task. If he cannot access then the stat
button will be invisible.
And if the portal user clicks on this button, he will be redirect to
`/my/orders/<id of the sale order>`.
task-2633229
Closes#82379
Steps to Reproduce:
- Install 'account' module
- Go to Settings and set a token for Google Drive
- Activate Google Spreadsheet
- Go to Invoicing -> Invoices
- Under Search bar, click on Favorites -> Add to Google Spreadsheet
Issue:
A spreadsheet does open but with no data (no formula or config).
Cause:
The V3 API we were using was turned down in August 2021 and therefore
not able to use the api to write on the spreadsheet.
https://cloud.google.com/blog/products/g-suite/migrate-your-apps-use-latest-sheets-api)
Note: In case that the system parameters `google_drive_client_id` and
`google_drive_client_secret` has been changed (and therefore also the
default templates), it must be ensured that the `client` has the
Google Sheet API (v4) activated and the scope
`https://www.googleapis.com/auth/spreadsheets` set.
API activation and configuration available here :
https://console.developers.google.com/apis/dashboard?project=[PROJECT]https://console.developers.google.com/apis/credentials/consent/edit?project=[PROJECT]
**[PROJECT]** : Google project that will be linked to `google_drive_client_id`.
opw-2633951
closesodoo/odoo#84488
X-original-commit: 3268530a071d9351ca86776fe85289ee5feece3d
Signed-off-by: Nasreddin Boulif (bon) <bon@odoo.com>
Chart.js did badly compute the graph canvas container height (width) by
using clientHeight (resp. clientWidth) that may be rounded up by the
browser. This leads to the appearence of a useless scrollbar in the
graph view and makes it flicker on some update.
closesodoo/odoo#84476
X-original-commit: 6bceae94619da9f4943cbc1e58844fdbe0215802
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
The es-check help specify that the `--module` optional argument as to be
given at the end of the cli. After an update to version `6.2.1` it led
to errors on runbot's where the Dockerfile was updated. The error was
like if the `--module` cli argument was not given at all. e.g.: `error:
SyntaxError: 'import' and 'export' may appear only with 'sourceType:
module'`
With this commit, the argument is given at the end of the cli as
expected.
closesodoo/odoo#84416
X-original-commit: dc74fd866d63003d987fc365a8137ff0e1c2d017
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
In big databases, the number of tags becomes rapidly huge. This makes
it very hard to find revelant tags. In practice, the same few tags are
usually used in a given project.
This commit:
- Limits the search of tags to the project's tags of the task as well
as to the tasks' tags of the task's project.
- Prevents creating case sensitive variants of existing tags.
- Reuse existing tags from other projects and other projects' tasks
when the user `creates` (or at least thinks creating as the
_name_search would not return the searched tag) a new tag in his project.
task-2735833
closesodoo/odoo#82925
Related: odoo/enterprise#23814
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
Reduces load_menus answer size by 32% (between 20kb and 200kb savings
for the initial loading of the backend, depending on the number of apps
installed). Support for SVG icons in the web client for menus/apps.
Reduced PNG icons for apps list (8 bits PNG instead of 24 as our icons
don't need more colors as they are flat designs)
closesodoo/odoo#84280
Related: odoo/enterprise#24200
Signed-off-by: Fabien Pinckaers <fp@odoo.com>
Before this commit, when a form view was re-rendered (e.g. when
switching to "edit" or "readonly" modes, when using the pager...),
the chatter briefly disappeared and then reappeared, which produced
a flickering. This has been introduced by the adaptation of the JS
codebase to owl 2 [1]: when the form view had to be re-rendered,
we reused the DOM element containing the chatter in the new
rendering (done in memory), which was thus detached from the DOM.
That element was re-inserted into the DOM later on, alongside the
rest of the newly rendered elements.
This commit fixes the issue by using a specific "hook" element when
rendering the form view, and replacing that hook by the actual
(unchanged) chatter container element when the rendering is done
and the DOM is patched.
This commit also removes unnecessary overrides in project:
- _renderNode was dead code, classname "oe_project_sharing_chatter"
no longer exists in the codebase since [2]
- _makeChatterContainerTarget replicated what was originally
already done in the mail FormRenderer (for appearently no valid
reason), so obviously, that override wasn't synchronized with
this fix.
[1] edd79ff560
[2] a28cc6333aclosesodoo/odoo#84429
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Steps to reproduce the bug:
- Go to any Contact > Sales and Purchase tab
- Edit > Change the barcode, and click Save
- Then click Edit, and try to erase (empty) the barcode > save
Problem:
A validation error is triggered, the constraint will check if other partners do not have the same barcode
but as it is empty there will be several other partners
Solution:
When the barcode is empty, no need to check if other partners have the same
opw-2753291
closesodoo/odoo#84450
X-original-commit: 32754ebc6f5f1b3c739d0a39ef209822fa4ed3a1
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
The `loading="lazy"` attribute was set by default on all images but this
affected the `mass_mailing` module as well while that attribute doesn't
work in emails and can cause some issues in edition.
One known such issue this addresses is to be reproduced as follows:
1. Create a new mail
2. Drop the "cover" snippet
It has height 0 so it won't load until another snippet (with a non-zero
height) is dropped.
task-2761074
closesodoo/odoo#84415
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
The shadow option needs to create a div on the fly to be able to
retrieve the default shadow value. This commit makes sure these divs
are also removed when no longer needed.
This also simplifies the code and actually avoids that div creation when
it is not needed.
task-2752326
closesodoo/odoo#84324
X-original-commit: 309f03c011fc8e5e0bec9882af54a8147025118f
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
The function `_compute_amount` on `account.tax` returns None if the value of
`amount_type` is not a standard Odoo value. During normal use, this will never
be the case, and if the value is modified by a custom module the method is
overriden in its code to account for that case.
During an upgrade, however, custom modules are not available. During the tests,
if a field needs to be computed using that function, it will break with
`TypeError: unsupported operand type(s) for /: 'NoneType' and 'float'`
Adding a default return to the function in case the `amount_type` is not
recognisef will help prevent this.
closesodoo/odoo#84432
X-original-commit: 8489da59c7f30a978023c5c56824d9398b8590b4
Signed-off-by: Olivier Colson <oco@odoo.com>
Problem occurs when we try to export report data and click
'I want to update data (import-compatible export)'.
We might end up exporting data when only field to export
is - External ID (id).
To reproduce an issue (for example):
Go to Time Off/Reporting/by Type; Remove filters from search.
Select couple records, then Action/Export.
On the wizard, click on 'I want to update data (import-compatible export)'.
Click on External ID from 'Available fields' to add it to 'Fields to export'.
Click export.
It gives traceback -
File "/data/build/odoo/addons/web/controllers/main.py", line 710,
in write_header self.worksheet.set_column(0, i, 30) # around 220 pixels
UnboundLocalError: local variable 'i' referenced before assignment
task - 2687370
closesodoo/odoo#84191
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
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>
Xavier BOL (xbo)