Prior to this commit, `oi` icons were not adapted when RTL was defined
in frontend.
This is because RTL adaptations were defined in the backend bundle.
This commit moves the RTL adaptations to be used wherever `oi` icons can
be defined.
Steps to reproduce :
- Enter in edit mode
- Drag and drop an image gallery and a carousel snippet
- Navigate to the theme tab
- Add an RTL language (Arabic, for instance)
Bugs :
- The image gallery displays inverted chevrons
- The carousel's chevrons are correct, but clicking on "previous"
displays the next picture, and vice versa.
Also, some icons a bit everywhere in the apps were not rotated either.
For instance, the back button a forum post to go back to the forum.
Note that task-3714335 will replace FA icons by BS icons, and will
triple check Odoo icons at the same time, to ensure all Odoo icons are
available in the frontend and correctly imported. For instance,
`oi-spin` and `oi-pulse` could make sense in the frontend too.
opw-3747848
task-3794966
closesodoo/odoo#159150
X-original-commit: fc105130551cf9897c7a0a78baf4458e6d5e6fd8
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
**Current behavior:**
In the jobs/ directory on the website, if a position has a
location set in its configuration, the 'Location' label will
display the name of the company rather than the city where it is
located.
**Expected behavior:**
The city will be displayed under the 'Location' label.
**Steps to reproduce:**
1. In the Recruitment app, give a job a location value
2. On the website, go to the jobs/ directory and navigate to the
position from step 1
3. Click 'Apply Now!' and look at the location label on the
right side of the page
**Cause of the issue:**
This field was missing the "contact" widget type in its
t-options.
**Fix:**
Add the widget type and additionally display "Remote" for the
location when there is no location set.
opw-3761348
closesodoo/odoo#159149
X-original-commit: fdb07fa0e67cacbcaee9ef99bbb3b315cd6baaf5
Signed-off-by: Vincent Ethan <etvi@odoo.com>
Signed-off-by: Bertrand Dossogne (bedo) <bedo@odoo.com>
This commit adapts `base_import`'s background that was too dark
compared to other modules. This was caused by the use of a `bg-white`
class that is not very "dark-mode friendly" as it will display as a
pure black, which is not visually appealing and not wanted.
This commit also adapts the background color of the sidebar to make it
more consistent with other modules.
We also add a `bg-view` class to the table, so it stands out more in
light mode and stays the same in dark mode.
task-3814508
closesodoo/odoo#158822
X-original-commit: 57131926a3d2a20d2deb64a4a4f30b31cb6251e4
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
Steps to reproduce:
-------------------
- be in a UTC+08:00 (or more) timezone
- go to Time Off dashboard
- click on a day (to request a leave)
Issue:
------
Default request dates are on 2 days instead of 1.
Cause:
------
Default request dates are determined during an onchange.
The datetimes (`default_date_from/to`) are set in the context in UTC
calculated in relation to the client's timezone.
Consequently, these datetimes can be set over several days.
In the backend, we will use these datetimes and take only the day
(because the `request_date_from/to` fields are of type date).
Solution:
---------
Put the values back into the client's timezone before they are truncated.
opw-3789265
closesodoo/odoo#158042
Signed-off-by: Bertrand Dossogne (bedo) <bedo@odoo.com>
Show a loading spinner and disable sign button on orders
to indicate that the request is processing avoiding users
clicking multiple times and getting an error,
that the order does not require signing
opw-3709064
closesodoo/odoo#157836
Signed-off-by: Valentin Chevalier <vcr@odoo.com>
Prior to this commit, the "hatched" event style in Planning wasn't
displayed in Day and Week views.
This commit adjusts the css selector to fix this issue.
task-3617329
Part of task-3575827
closesodoo/odoo#154964
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
Prior to this commit, some of the main styles related to event elements
in calendars were set in the Calendar module.
This created layout issues when we installed independent modules without
installing the Calendar module (eg. `planning` or `hr_payroll`).
To fix that, this commit moves the necessary styles into `web`.
task-3617329
Part of task-3575827
Part-of: odoo/odoo#154964
The underlying `odoo.tools.email_send` was removed in
82de620424 (merged in 14.5) but this
callsite was missed, this method has been broken ever since.
I really want to remove this method directly, but technically it's an
expensive no-op if called on a recordset of partners without emails
set (or an empty recordset), so instead make it trigger a warning &
remove in master.
closesodoo/odoo#159177
X-original-commit: 457a4be9d6bb1e15b996a5a14468f9b0d88e0b0f
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Bug
===
1. login as demo user
2. add a review on a course and upload an attachment
3. click on the attachment link
=> You get a 404 error
For some reason, we do not return the access token if the user is
internal. The generation is not a heavy process, and might be needed
depending on the <ir.rule>.
Task-3693072
closesodoo/odoo#159126
X-original-commit: 74b0f88c6b15feb8d3453edf20acda81b37df66c
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: Stéphane Debauche (std) <std@odoo.com>
The fields in analytic have a group which is defined in account.
We hide them in analytic module and show them in account with the right group.
We also show balance now, even if you don't have the group 'readonly',
because it's an information that is independent of credit/debit notion.
Linked to runbot error 59222 (will need to remove the group in the test)
closesodoo/odoo#159085
X-original-commit: e7e3ec8cb5e4f71ce1dbbd24485c3377c694e5eb
Signed-off-by: John Laterre (jol) <jol@odoo.com>
Signed-off-by: Wala Gauthier (gawa) <gawa@odoo.com>
Currently, an analytic account is created when confirming a quotation for a product created as follow:
1. Enable `Can be Expensed`
2. Select `At cost` for Re-invoice expenses
3. Disable `Can be expensed`
Steps to reproduce:
-------------------
* Install **sale_management** and **hr_expense**
* Go to **Settings**
* Under `Customer Invoices`, enable `Intrastat` -> Save
* Under `Analytics`, enable `Analytic Accounting`
* Go to **Sales**
* Create 3 products
* Product 1: Default
* Product 2:
* Enable `Can be Expensed`
* Select `At cost` for Re-invoice expenses
* Product 3:
* Enable `Can be Expensed`
* Select `At cost` for Re-invoice expenses
* Disable `Can be expensed`
* For each product, repeat:
* Create a quotation, select a customer
* Add the product
* Confirm
* Select tab `Other Info`
* Check the analytic account
**Observations:**
* Product 1: No analytic account created
* Product 2: Analytic account created
* Product 3: Analytic account created
Why the fix:
------------
The creation of the analytic account depends on the value of `expense_policy`. When the value is `no`, no analytic account is created. Whereas when the value is `cost`, an analytic account is created.
https://github.com/odoo/odoo/blob/57ad9c05014ca0219d7892c1ff8a2e949fab3c49/addons/sale/models/sale_order.py#L853-L856
In this workflow, `expense_policy` is visible only when `Can be expensed` is enabled. If you select an `expense_policy` then disable `Can be expensed`, the value for the `expense_policy` stays as previously selected.
https://github.com/odoo/odoo/blob/3e320ffe0ff4d1c6bb7d0314f36dd13ad1cf23f4/addons/sale_expense/models/product_template.py#L33-L41
opw-3706305
closesodoo/odoo#159084
X-original-commit: 4b8e0559248d75ef27f47903041e5cca2059fa80
Signed-off-by: de Wouters de Bouchout Jean-Benoît (jbw) <jbw@odoo.com>
Signed-off-by: Sarah Bellefroid (sbel) <sbel@odoo.com>
Before this commit:
When attempting to copy a button that is a direct child of a div tag, the div
was unintentionally copied along with the button, leading to additional space
upon pasting, along with the background color.
After this commit:
Now, only the button will be copied and pasted
task-3764652
closesodoo/odoo#158975
X-original-commit: b27b9ca18da9b1c39906f8a374418105c2e9c487
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Steps to reproduce:
- Install Accounting and Purchase
- Install a localization that supports electronic invoice (e.g. l10n_it_edi)
- Switch to a company with that localization
- Go to Purchase and create a PO:
* Vendor: Vendor X
* Product: Product X
* Unit Price: 50.00
- Create an electronic bill in XML format with:
* a reference to PO name
* the same partner than the PO
* the same line than the PO, except for the price (e.g. 200.00)
- Go to "Accounting / Vendors / Bills"
- Upload the XML bill
Issue:
The bill is generated and linked to the PO, but the price and subtotal on
the bill line is the one coming from the PO instead of the one coming from
the XML.
Values coming from an imported XML should not be overridden by values found
in matching PO.
Cause:
"timeout" parameter is wrongly passed as "prefer_purchase_line" parameter in
a call to "_find_and_set_purchase_orders" method.
opw-3707731
closesodoo/odoo#159139
X-original-commit: fc6b71c649c17c7534cdc9b9853d75b58076a823
Signed-off-by: Claire Bretton (clbr) <clbr@odoo.com>
Signed-off-by: Anh Thao Pham (pta) <pta@odoo.com>
If you're on Linux, make sure `inotify` is uninstalled:
pip uninstall inotify
Install `watchdog` to its latest release, 4.0.0, and start odoo in
dev-reload mode. This mode restart the application everytime a file is
modified in one of the addons.
pip install watchdog==4.0.0 -U
odoo-bin ... --dev=reload # replace ... with your arguments
Modify a file, save it. The server doesn't reload while it should.
Before gorakhargosh/watchdog@41fca1eb, only the `FileSystemMovedEvent`
class had a `dest_path` attribute (actually a property). In our code, we
used a `getattr` approach to fallback on `src_path` (which is set on all
three event classes) in case `dest_path` was not set.
Since that commit, the attribute has been moved to the base abstract
class `FileSystemEvent` which all three `FileCreatedEvent`,
`FileModifiedEvent`, and `FileMovedEvent` inherit. Hence the attribute
is always set (sometime to an empty string) and the getattr must be
adapted.
The new code supports both watchdog==3.0.0 and watchdog==4.0.0.
closesodoo/odoo#159102
X-original-commit: 9dd441858fa26d1fb6f13c7cd59076e8898aceb3
Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>
When we use the `|` (or) version of this rule the ORM generates two
sub-queries when checking the company. This causes sub-optimal and in
some cases really bad planning for the queries and thus PG takes hours
to complete them.
Example (formatted):
```sql
SELECT "mrp_routing_workcenter".id
FROM "mrp_routing_workcenter"
LEFT JOIN "mrp_bom" AS "mrp_routing_workcenter__bom_id"
ON "mrp_routing_workcenter"."bom_id" = "mrp_routing_workcenter__bom_id"."id"
WHERE "mrp_routing_workcenter"."workcenter_id" in (1)
AND ( ("mrp_routing_workcenter"."bom_id" in (
SELECT "mrp_bom".id
FROM "mrp_bom"
WHERE ("mrp_bom"."company_id" in (1))
)
)
OR ("mrp_routing_workcenter"."bom_id" in (
SELECT "mrp_bom".id
FROM "mrp_bom"
WHERE "mrp_bom"."company_id" IS NULL
)
)
)
ORDER BY "mrp_routing_workcenter__bom_id"."sequence",
"mrp_routing_workcenter__bom_id"."id",
"mrp_routing_workcenter"."sequence",
"mrp_routing_workcenter"."id"
```
If we use the single term version the generated query has only one
sub-query:
```sql
SELECT "mrp_routing_workcenter".id
FROM "mrp_routing_workcenter"
LEFT JOIN "mrp_bom" AS "mrp_routing_workcenter__bom_id"
ON "mrp_routing_workcenter"."bom_id" = "mrp_routing_workcenter__bom_id"."id"
WHERE "mrp_routing_workcenter"."workcenter_id" in (1)
AND ( ("mrp_routing_workcenter"."bom_id" in (
SELECT "mrp_bom".id
FROM "mrp_bom"
WHERE (("mrp_bom"."company_id" in (1))
OR ("mrp_bom"."company_id" IS NULL))
)
)
)
ORDER BY "mrp_routing_workcenter__bom_id"."sequence",
"mrp_routing_workcenter__bom_id"."id",
"mrp_routing_workcenter"."sequence",
"mrp_routing_workcenter"."id"
```
In this version PG is able to produce a better query plan resulting in
better execution times.
Also, the `company_id` field is required on some models, so the "= False" comparison is useless.
closesodoo/odoo#159123
X-original-commit: 1b5c41f36801fb886ec591f29dba42787d698526
Related: odoo/enterprise#59378
Signed-off-by: Christophe Simonis (chs) <chs@odoo.com>
Co-authored-by: Christophe Simonis <chs@odoo.com>
Prior to this commit, the rounding setting could be modified while
a session was open. This could potentially cause accounting
discrepancies and lead to unbalanced account moves.
opw-3677480
closesodoo/odoo#158625
X-original-commit: 021302a270028373ab519ea1d5409ffb73ee8424
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Signed-off-by: Pedram Bi Ria (pebr) <pebr@odoo.com>
Prior to this commit, if a "Buy X get Y" promotion was in place, with
a free product reward associated with a specific tag, the computation
of the free product reward could be incorrect in the Point of Sale
when combined with products carrying the tag.
opw-3753994
closesodoo/odoo#158618
X-original-commit: 5f3c8017c5cf255e3b3fa53631a243d2f61c9f60
Signed-off-by: Vlad Stroia (vlst) <vlst@odoo.com>
Signed-off-by: Pedram Bi Ria (pebr) <pebr@odoo.com>
When applying a format in an unbreakable inline (without a class), the
format was immediately rolled back as we tried to remove split the
unbreakable in order to remove its style.
task-3768157
closesodoo/odoo#159110
X-original-commit: 78e809c18db7bd520ccf706b2504139248fbd0ff
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Signed-off-by: Antoine Guenet (age) <age@odoo.com>
Issue:
======
resizing columns doesn't work properly in rtl direction.
Steps to reproduce the issue:
=============================
- Install arabic
- Go to notes
- insert a table
- Try to resize columns
Solution:
=========
We will handle the cases one by one:
Start: We need to update the `marginRight` prop instead of `marginLeft`
and calculate `sizeDelta` correctly which `clientX - (rect.x +
rec.width)`.
Middle: We will handle this the same as ltr direction, since it's the
reverse direction, we swap `previous` with `next` and `next` with
`previous`. Columns are sorted from right to left so we need to swap
columns when we recalculate them from the columns array so `item` will
be the one on the left and `neighbor` the one on the right.
last: We calculate correctly `sizeDelta` which is `rect.x - clientX`
task-3721794
closesodoo/odoo#159087
X-original-commit: 87f8bcd99a4b1049deed7bccbc5b85812ebc4674
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Issue:
======
The icons does match the direction of the move but it doesn't match the
label in the ltr language.
Steps to reproduce the issue:
=============================
- Install arabic
- Go to notes and insert a table
- write something in a column in the middle
- Click on the top of the column on the 3 points.
- The first item of the dropdown have the label in arabic meaning `Move
to left` but the direction of the icon and clicking on it will move it
to the right.
Origin of the issue:
====================
- The icon is being flipped because we are in rtl but in realtity left
is the same for rtl or ltr direction.
- We need to call `_onTableMoveLeftClick` when we are moving to the
right in rtl because the left of rtl direction is the visible right.
task-3721794
X-original-commit: 58cdfb8c80ecfb305ecdb84398508bd2fc180fb3
Part-of: odoo/odoo#159087
In Inventory Settings activate packages and storage locations.
Create a storable product [TEST] with tracking by lot
Create a PO for [TEST] with a [QTY] larger than one.
Receive the products (lot [A]) and put them in a package [PKG].
Create and process an internal transfer of the whole package [PKG]
from the input location to any location.
Unpack [PKG].
Go to Stock > Reporting > Locations
Locate the received product, hit 'History'
Issue: traceability is empty.
This occurs because the 'unpack' operation clean the information
relative to the package from the stock quant.
When accessing the history, the system lookup for move lines having the
same package (none in this case), so nothing is found
opw-3769752
closesodoo/odoo#158949
X-original-commit: 314d44b400717f392bfbb70f66ef9605c1f31041
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Andrea Grazioso (agr) <agr@odoo.com>
Before this commit, when creating a many2one field from an xml, with an
impossible combination "`required=True` - `on_delete='set null'`", the
column was not created in the database without any notice to the user.
This commit adds a constraint checking that any attempt to create a field
with this configuration would raise a ValidationError. This constraint
replaces the previous onchange method.
closesodoo/odoo#158778
Signed-off-by: Rémy Voet (ryv) <ryv@odoo.com>
*: web_editor, website
Commit [1] introduced new image settings for the product page.
When those settings were introduced, the editor was reloaded after the
RPC to properly reflect when the settings were changed. While this was
done, a data-reload was also added in the XML template of the options.
This was not necessary as the data-reload only works for some methods
which are not used in the image settings. Therefore, the data-reload
did nothing.
However, with commit [2], the settings were moved and combined with
page options. So the image settings automatically inherited the page
options behavior, which is to save and reload the page when a method
with data-reload is called. This caused the editor to ask for a reload
twice.
This could cause the page to reload before the RPC was finished:
- Add a 10 seconds sleep at the start of /shop/config/website controller
- Go to products page
- Enter edit mode
- Change the number of products per row
=> Nothing happens
Indeed, the page is reloaded immediately, before the 10 seconds rpc is
actually done.
This is also needed by the conversion of the SnippetsMenu to OWL:
It seems like the race condition introduces a traceback.
This commit fixes the issue by ignoring any save request from an option
that will reload anyway. It also awaits the RPC to finish before
reloading the page.
[1]: https://github.com/odoo/odoo/commit/54c6d36cfbea31fe60b888bbb903b0c6f22216b3
[2]: https://github.com/odoo/odoo/commit/b274cf2427951761e59eb357fb796b54be375507#diff-754f6c793d6a168d006d2a9da108142b889036031ac1a2e62060c225d060f858closesodoo/odoo#158468
X-original-commit: 556ae457b02e9c077d09fa9c3f9f1e6c6e26b345
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Before this commit, when a user of in chat posted a message and
deleted it, all other users kept the chat as unread.
Steps to reproduce:
- Connect as Admin and March Demo
- Send a message to Admin as Demo in DM chat
- Demo deletes this message
- Marc opens the chat
=> the unread counter is 1 and cannot be removed
This happens because when a message is deleted, there's still a
trace of it but the message is empty. However, empty messages could
not be candidate of setting the last message being seing by a member,
thus members were unable to mark the chat as read until someone else
posted a newer message (and did not delete it).
This commit fixes the issue by taking empty messages into account for
setting last message message of member, which allow to mark thread as
read even when newer messages have been deleted.
opw-3764410
closesodoo/odoo#158943
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Current behavior:
When printing a ZPL label for a product without barcode, the label was
printed with a barcode containing the "False" value
Steps to reproduce:
- Install the stock module
- Create a product without barcode
- Print a ZPL label for this product
- The label contains a barcode with the "False" value (You can check the
rendering on labelary.com)
opw-3797462
closesodoo/odoo#158939
X-original-commit: e392027afa245a708a906b484250ed46200e13be
Signed-off-by: Quentin Wolfs (quwo) <quwo@odoo.com>
Signed-off-by: Robin Engels (roen) <roen@odoo.com>
Steps to reproduce:
- Go to website in "Edit" mode (on a blog post page).
- Select one of the default images in the blog content.
- Click on the "Animation" option and select "On Hover" > Traceback!
Starting from [1], the "On hover" image animation was implemented to be
able to pick an animation that triggers when hovering an image.
This feature is setting a default "Square" shape (required for the
hover effects to work) on the target. Which means that an error can
always occur if the "On Hover" animation option is available while the
targeted image is not linked to an attachment and can't support image
shapes (which is the case here).
The goal of this commit is to fix this issue by only allowing the
"On Hover" animations when it's possible to apply shapes to the image.
[1]: https://github.com/odoo/odoo/commit/7f730f81ec541cc7791fc6b3fded17c838433f85
opw-3795599
closesodoo/odoo#158433
Signed-off-by: Benoit Socias (bso) <bso@odoo.com>
Since [this other commit], the style indicating the active nav item
stopped working if the user added record pages to the navbar. This was
due to the cache system not being invalidated when switching from one
record page to another.
This commit fixes the issue by disabling the cache for the navbar if
there is a record page in the menu.
Other potential solutions were considered but ultimately rejected:
1. Using the record as a t-cache key. However, this would mean that if
you have 60,000 visible forum posts, you would end up with 60,000
different caches.
2. Activate the correct element using JavaScript. This would lead to a
duplicate logic in the JavaScript and the Python code, and it would
introduces a slight lag to add the active class on the correct nav item
(due to the time it takes to load and execute the JavaScript).
The chosen solution is the best compromise, as it maintains the cache
for most cases (website menu without records page links in it), nothing
change with this commit. For problematic cases (record pages in the
website menu), this commit disables the cache, which is a reasonable
trade-off.
Steps to reproduce the bug fixed by this commit:
- Edit a website's menu
- Add a link to a product page (e.g., customizable-desk)
- Add a link to another product (e.g., chair-floor-protection)
- Save the menu
- Click on the menu link to go to customizable-desk
=> At this point, the active menu element is correct
- Click on the menu link to go to chair-floor-protection
=> The active menu element does not update
This commit fixes the issue (a update of the website module is needed)
and adds a test to prevent regressions.
Notes:
- To see the issue locally, remove the --dev xml or --dev all arguments.
- The same issue was occurring with other record pages (blog posts, ..).
- We will introduce back the groups on menu and benefit from this new
method to also disable the menu cache if one of the menu is linked to
a group. See task-3800830
[this other commit]: https://github.com/odoo/odoo/commit/b0a2a41d78292cb8b9e53788d40c6dc5915a466d
opw-3694651
opw-3750925
opw-3781668
closesodoo/odoo#159006
X-original-commit: 43576cd424b6d0fc7da01142b5e6550e371ad1ff
Related: odoo/enterprise#59321
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Guillaume Dieleman (gdi) <gdi@odoo.com>
Resequencing entries that come from payment and non payment
raise a UserError, even if the journal has `payment_sequence`
set to False
Steps to reproduce:
1) Go to "Accounting / Configuration / Accounting / Journals" and create a new
journal with type "Bank" and "Dedicated Payment Sequence" in False.
2) Create a "Bank Statement Line" in the journal created in step "1".
3) Create and confirm a customer payment using the journal created in step "1".
4) Go to "Accounting / Accounting / Journals / Journal Entries".
Select journal entries created on step "2" and "3" and then click on Action --> Resequence.
Then a User Error is being show "The sequences of this journal are different for Payments
and non-Payments but you selected some of both types." it is not correct as the journal
created on step "1" has the field "Dedicated Payment Sequence" set to "False".
opw-3763500
closesodoo/odoo#159003
X-original-commit: 11d71cf1b244174c12c0094eb2f0f072894aecc6
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
Signed-off-by: Guillaume Vanleynseele (guva) <guva@odoo.com>
A traceback was spotted when `unserializeNode` was called as a result of
a call to `resetContent`. That traceback could lead to other tracebacks
(including one when trying to read a history step's ID in
`_historyMakeSnapshot`). A traceback at that moment could remove all the
content of the editor before saving.
This commit ensures the argument passed to `unserializeNode` is defined,
that `unserializeNode` returns `undefined` if it couldn't return
anything valid, and that when such is the case the caller handles that
undefined return value properly.
task-3677431
closesodoo/odoo#158957
X-original-commit: bf062140877dabcb6db93d2a4bea2aa36f4b2601
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
This data is used in the chart of account definition and could put
the end user into a bad situation.
Related ticket: 3790614
closesodoo/odoo#158875
X-original-commit: f48c30181e1335ef72c60ca9e7d14b7f4aa42359
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Context:
During the refactor 68fbdc9640,
expense rights were improved but two cases were forgotten.
Before this commit:
1. sudo would not work as the rights were checking the groups
2. system admins were considered as being expense admins too, which may
not be the case if the system admin user changes
and the correct group `group_hr_expense_manager` is not given.
System admins should always be able to edit expenses
when it make sense.
After this commit:
Sudoed and group_system users are considered as expense admins
closesodoo/odoo#158583
Signed-off-by: Julien Van Roy (juvr) <juvr@odoo.com>
How to reproduce:
- Install hr_skills_survey with demo data
- As admin, in "Survey", create a simple certification with one question
- Click on share and send it to Marc demo
- As a public user, do the certification through the received link
- As admin, go to "Employee" and got to "Reporting -> Certifications"
- You will see the certification in red under "Marc Demo"
This means that the certification is already expired and should not.
When completing a certification (survey), a hr_resume_line is inserted in the
database with a start_date and an end_date set to the completion date, causing
the certification to be expired right away.
We only do "cosmetic" correction here as the real fix will be done in master to
avoid multiple upgrade:
- to avoid existing certification to be displayed in red in the reporting view,
we correct the display (by avoiding adding danger decoration to the line if the
date_start equals the date_end). That correction won't avoid to find those
certifications as expired as we can't correct the computed field as it is
stored. Also, if the expiration_status column is shown (hidden by default), it
will display expired on those certifications.
- We do a similar correction in the display of the employee resume.
Note: the end_date problem is anterior to v17 but the resume line expiration
has been introduced in v17.
Task-3389395
closesodoo/odoo#158047
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
When typing in Japanese with Romaji input, a traceback occurred when
hitting backspace to remove the only character in the editable while the
Japanese character selection menu was open. This is because that case
triggers an `insertCompositionText` input event with an empty string,
and tries to delete the editable, which is unremovable. Since we called
`_applyRawCommand` without wrapping it in `_protect`, the unremovable
error caused a traceback instead of a rollback. When fixing that, an
other bug appeared, which was the insertion of a `#` character. This was
due to the fact that `insertText` was called with empty content, and
`insertText` defaulted to the character `#` for no particular reason
since the early proof of concept of the editor.
task-3134566
closesodoo/odoo#159005
X-original-commit: cb75212d4fe302b54097fbc90da6d6ef8b38205b
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Signed-off-by: Antoine Guenet (age) <age@odoo.com>
That is how states are (might be?) exported, so it should be possible
to find them the same way.
closesodoo/odoo#158984
Task-id: 3644762
X-original-commit: 26df8e2858d8bcaa11dfae68be328388b1983745
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Purpose
=======
Tremendous amount of support tickets (ex: 3800405) are opened because the user_admin
has been removed and is referenced everywhere, leading to tracebacks or
the impossibility to install a new application as res.group configurations
all relies on this, like:
<record id="group_helpdesk_manager" model="res.groups">
<field name="name">Administrator</field>
<field name="category_id" ref="base.module_category_services_helpdesk"/>
<field name="implied_ids" eval="[(4, ref('group_helpdesk_user'))]"/>
<field name="users" eval="[(4, ref('base.user_root')), (4, ref('base.user_admin'))]"/>
</record>
We could adapt all the occurences (severeal hundreds) to ensure robustness
but this won't prevent developer from introducing new use cases + the user
can be archived instead if we want to remove him from the pricing.
closesodoo/odoo#158885
Taskid: 3802440
X-original-commit: b55994b4c5e737aae593eb0419f96347ad90bebb
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Purpose
=======
Lots of tickets (e.g. 3775298) are created because the default menu has been deleted,
leading to the impossibility to install a new module, as the parent_id
for new menus like /shop or /event are directly referencing the
website.main_menu record, or to the impossibility to create a new
website.
Task-3802440
closesodoo/odoo#158879
X-original-commit: adb1dcfd0a150ab4706a09a29ae8921fb94fa463
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Bug:
When an irish company without VAT invoices a Norvegian company with a 0%
tax, the category of the tax is "K" in the Bis 3 xml, which will raise:
"[BR-IC-02]-An Invoice that contains an Invoice line (BG-25) where the
Invoiced item VAT category code (BT-151) is "Intra-community supply"
shall contain the Seller VAT Identifier (BT-31) or the Seller tax
representative VAT identifier (BT-63) and the Buyer VAT identifier
(BT-48)."
Using code "G" would also raise: "[BR-G-02]-An Invoice that contains an
Invoice line (BG-25) where the Invoiced item VAT category code (BT-151)
is "Export outside the EU" shall contain the Seller VAT Identifier
(BT-31) or the Seller tax representative VAT identifier (BT-63)."
Fix:
We should only use "G" or "K" when the supplier has a VAT. If a supplier
without a VAT invoices with a 0% tax, we should use the tax category "E"
(Exempted).
opw-3785810
closesodoo/odoo#158670
X-original-commit: 357f1aec4bfa12fe476a207f2acfc1bf4a6232d5
Signed-off-by: Laurent Smet (las) <las@odoo.com>
Signed-off-by: Julien Van Roy (juvr) <juvr@odoo.com>
Steps to reproduce:
-------------------
- install calendar, project and documents;
- create an activity for a task (project.task) with meeting type;
- change attendee to the meeting;
- save;
Issue:
------
The activity is not linked to the right task.
Cause:
------
When we create a `calendar.event`, when the event is at a future date,
we send an email to the attendees.
This email must include an attachment corresponding to the ICS file.
Depending on the `no_document` context key, we may or may not create a document.
When we create the document, we have a value for the `activity_ids` field (one2many)
which is the ORM command for linking the newly created document.
This will result in the document id being written to the `res_id` field
of the `mail.activity` record.
Unfortunately, the activity contains a `res_model` which is not `documents.document`.
The result is that the activity is linked to a `res_id` which is not
that of the model previously set for it (i.e. `project.task`).
Solution:
---------
Add context key `no_document` when creating an attachment for ICS files.
opw-3746857
closesodoo/odoo#158570
X-original-commit: 17ac8d3f25bad2c4f37793e06edca40793a4f3d5
Signed-off-by: Arnaud Joset (arj) <arj@odoo.com>
Signed-off-by: Thomas Lefebvre (thle) <thle@odoo.com>
Before this commit sol field wasn't editable when user
don't have any sales access and it was editable for
timesheet page and project form view.
This commit make SOL field in task form editable to
be consistant with project form and timesheet page
of tast form.
task-3764793
closesodoo/odoo#158547
X-original-commit: 1d25d6f92d4ecf658bbbc9d39983808fa0fc9c87
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Signed-off-by: Kartik Chavda (kcv) <kcv@odoo.com>
Versions
--------
- 16.0+
Steps
-----
1. Set tax rounding method to global;
2. create a loyalty program offering 100% discount on orders;
3. create a SO with the following line subtotals & 15% tax:
1. $5.60
2. $8.92
3. $44.91
4. $217.26
5. $2400.00
4. apply the 100% discount program.
Issue
-----
Total comes down to $0.01 instead of $0.00.
Cause
-----
To calculate the `discountable` amount, any non-fixed tax is mostly
ignored, instead only looking at price totals and fixed taxes. As global
tax rounding is achieved by using increased precision in intermediary
calculations, rounding errors are introduced by only looking at totals.
Solution
--------
Use the `compute_all` method instead, to retrieve precise tax data, and
add/subtract taxes depending on `amount_type`.
opw-3710365
closesodoo/odoo#158387
X-original-commit: 09f31597163a3251e58bb7b08939301574e1f65a
Signed-off-by: Levi Siuzdak <sile@odoo.com>
The attribute cache is mainly used from the Environment class. The
ormcache attribute using the same name leads to confusion.
Related task:
task-3818968
closesodoo/odoo#155264
Signed-off-by: Rémy Voet (ryv) <ryv@odoo.com>
Before this commit, when using a shipping method with the variable
weight*volume for price computation, the price was growing with the
square of the ordered quantities. This is because both volume and
weight were multiplied by the quantity, before being multiplied with
each other in the next step.
This commit fixes the issue by introducing the variable weight*volume
at the beginning of the computation.
In order not to break anything in stable, the new variable is added as a
kwarg to the useful methods.
OPW-3802315
closesodoo/odoo#159007
X-original-commit: 0a8db0fa14bb63abd0b2a8f0234d86700b6c1e2e
Signed-off-by: Vallaeys Valentin (vava) <vava@odoo.com>
Commit [1] was introduced to fix an issue where the website menu cache
is incompatible with having a slug url in one of its menu.
But in the enterprise build, since the website_helpdesk module is adding
one menu containing a slug url, it would disable the menu cache.
Unfortunately, the website_blog perf tests (at_install) are executed
after website_helpdesk is installed, meaning that in enterprise, the
perf test of website_blog would fail since it would require some more
SQL Queries (1 or 2 depending of the test) to render a blog post as it
would have to query the website.menu table.
It's still unclear how commit [1] was merged in the codebase since the
enterprise staging should have failed.
runbot-60466
runbot-60467
[1]: https://github.com/odoo/odoo/commit/948235079f002794f9837d3cf91e2d20e3254e20closesodoo/odoo#158666
X-original-commit: 11acdfc7d8dd0dfe146b6f7547123af94e2a0baf
Signed-off-by: Guillaume Dieleman (gdi) <gdi@odoo.com>
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
This commit introduces an update to the Font Awesome library,
specifically replacing the X/Twitter icon with its new design. It also
involves adjustments to a few images and SVG files to incorporate the
updated X/Twitter logo.
Technical note: It updates an existing file, originally modified for the
addition of the TikTok icon, which was not available in Font Awesome 4.
task-3463530
closesodoo/odoo#158586
X-original-commit: 34cba04a452f2da21f3418d6fc48a484da8ecd27
Related: odoo/enterprise#59147
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Steps to reproduce:
* Activate multi-currency (Company currency `USD`, another currency activated 'EUR')
* Create invoice/bill in `EUR` and post it
* Archive `EUR'
* Open Invoice/Bill
Issue:
* Alert for inactivated currency is always displayed
Fix:
* Alert for inactivated currency should be displayed in draft state only
closesodoo/odoo#158802
X-original-commit: 72a0058ec748a03351ab3ad7536ff7089f84262e
Signed-off-by: Habib Ayob (ayh) <ayh@odoo.com>
As we imported invoices from the IAP proxy we refused files when the
same filename was already present in the database.
Import invoices sent by Company A to Company B on the same Odoo database
was therefore impeded. The CRON would try to import the Company B's
vendor bill with the same attachment's filename as the Company A's
invoice and reject the file.
Now we fill in the `company_id` field on the attachment and we search
for attachments which belong to the company we're importing for, so the
case is covered.
An import test has been added.
opw-3673508
closesodoo/odoo#157755
Signed-off-by: Habib Ayob (ayh) <ayh@odoo.com>
Brieuc-brd