Before this commit, im status icon for "away" was brown
in white mode.
This comes from MILK redesign change changes the color of
`text-warning`, from yellow to brown in white mode.
This commit fixes the issue by explicitly using yellow color,
regardless of theme. Dark mode kept the yellow color, so this
is unchanged.
closesodoo/odoo#123188
X-original-commit: d500608c01370ffb712ea45ce3f6b58e706ed760
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Two issues solved in 1 commit; as their solutions depend on one another.
** ISSUE 1 **
To reproduce the issue, on a l10n with a tax report:
- Create a misc operation with a tax on it in the same form as a sales invoice ; post it.
- Reverse that move, and post the reverse.
=> Open the tax report: the amounts of the original move (for both tax lines and base lines) are doubled.
That's not what we want ; instead, the reverse should have entirely canceled the original move.
This is due to the fact the is_refund field of account.move.line is badly computed on the reverse: both tax and base lines are considered refund. Because of that, tax_tag_invert gets inverted, and ends up doubling the amount in the report instead of cancelling it. While made on a reverse move, those lines should not be considered as refunds, since they must both use the original repartition of the reversed move , unlike invoices, which would make use of the refund repartition in this case.
** ISSUE 2 **
To reproduce, on a l10n with a tax report:
- Create a cash basis tax, and set tags on its repartition lines so that it should be taken into account by the report. Make sure the refund repartition cancels the invoice repartition.
- Create an invoice using that tax, post it
- Click the "Add Credit Note" button, select "partial refund", and post the generated refund (which will cover the full amount of the original invoice)
- Reconcile the refund with the invoice
=> Because it's a partial refund, cash basis entries will still be generated. Open the tax report to ensure they sum up to 0... And the tax lines don't !
This happens because the computation of tax_tag_invert field inverts the sign of tag on cash basis entry tax lines when they have a negative tax_base_amount. In our case, when going through the "reverse" button and making a partial refund, we actually do get a negative amount in the credit note's tax_base_amount. This is inconsistent with what a refund generated from scratch does (then, you'll get a positive tax_base_amount in our case), and should only be legit when the document contains a negative line explicitly (so, a line with a negative quantity, hence inverting the meaning of debit/credit).
The root of the issue is that the tax_base_amount of the tax line uses the tax_tag_invert of the base line to define its sign. And tax_tag_invert was omitting to set copy=False. When reversing a move, the first step is to copy it. Because of the missing copy=False, tax_tag_invert was copied, and never recomputed (since it's a computed editable field) on the base line, giving it an inconsistent value, and ending up inverting the sign of tax_base_amount on the tax line. In turn, the tax line got a wrong tax_tag_invert because of that, and would propagate that to the cash basis entry when generating it.
This commit adds the missing copy=False to tax_tag_invert, but also fixes the computation of tax_tag_invert so that in does not rely on tax_base_amount anymore. This way, existing data will also benefit from the fix without having to recompute the field. Additionnally, there are currently plans to remove tax_base_amount in master, so this would have had to be done eventually anyway.
======
Forward-port note:
In 16.2, https://github.com/odoo/odoo/commit/84d7aab94e2984a81923f0546e24caf54cd53033 actually wrongly inverted the sign of the Mexican withholding tag in repartition lines. Those taxes are negative, so a tag needing to get the retention amount in positive must be negative itself. The bugs fixed in this commit shadowed the problem, and this fix reveals it. A fix of the tags's signs was added into this forward-port.
OPW 3255511
closesodoo/odoo#123187
X-original-commit: 688ab4d6688ccd2377ea9702c00b1ec16f99527a
Related: odoo/enterprise#41748
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
In a Kanban View, the container in which elements are dragged is a `d-flex`
element, and as such it has the `overflow: visible` css property by default.
This means that if there are more groups than the current dimensions of the
viewport allows for, those groups will overflow outside the dimensions of the
container, preventing elements from being dragged outside.
Therefore the dimensions of the draggable area should consider the container
`scrollWidth` and `scrollHeight`, as these values take into account the
dimension of overflowing elements.
task-3339978
closesodoo/odoo#123167
X-original-commit: b14f195a426183894dcd37d9776807114e8e05ef
Signed-off-by: Julien Mougenot (jum) <jum@odoo.com>
Signed-off-by: Abeloos Damien (abd) <abd@odoo.com>
The issue occurred when a loyalty program's rule was set to be
based on money spent, and the reward was a free product with a
sale price of zero. This caused a zero division error in the code,
resulting in the remaining points becoming NaN after the reward
was obtained in the point of sale.
opw-3253366
closesodoo/odoo#123123
X-original-commit: 1eaca074741157e42c12da22e945a1817e7ceec3
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Signed-off-by: Pedram Bi Ria (pebr) <pebr@odoo.com>
This commit enables precompute of product_qty in MO so that the
product_qty is correctly set when a bom exists for the created MO.
it also corrects the values of `picking_type_use` fields to be used
in the barcode app for MOs.
Enterprise PR: odoo/enterprise#38096
Taskid: 3052744
Part-of: odoo/odoo#114708
This commit adds `workcenter_id` as the workcenter search field used to
have the same name as the `name` search field in the `mrp.production`
search view.
Part-of: odoo/odoo#114708
Steps to reproduce:
- Install industry_fsm_report, website
- Create Project P, add column/stage PC.
- Edit stage, Email Template = Task: Intervention Schduled.
- Edit the template > Advanced Settings > Optional report to print and
attach = Worksheet Report (PDF). Save everything.
- Go to website, "contact us" page > Edit the form, Action = Create a
task, Project = P > Save
Issue:
When you first submit the form, it will fail, but the task will be
created and visible in project P. By instinct, the user will submit the
form again, so the task will be duplicated. The second form submit will
return a success message.
When submitting a form, we first generate a savepoint (added in
commit [1]).
Since this is the first interaction with the report system, during the
handling of the form, the assetsbundle will be generated (see keyword
'commit_assetsbundle'), which will cause a commit.
Finally, assuming no other error is raised, we try to delete the
savepoint.
However, since a commit was executed, then the savepoint will no longer
exist, which will cause an error status to be returned.
Solution:
When submitting a form, pass `commit_assetsbundle=False` to the record
creation, which prevents the commit from happening.
This solution has a downside; creating the record also sends an email
and the report attached to that email will have broken styling. This is
still an improvement to the current behaviour, which doesn't send the
first email at all.
[1]: https://github.com/odoo-dev/odoo/commit/5a499ecf113f08c11d2b33b47680dd00ec1b297b
opw-3183912
closesodoo/odoo#123198
X-original-commit: 26031c452a7d92f35270cb04a4f37b26ff6bcc99
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Stefan-Calin Crainiciuc (stcc) <stcc@odoo.com>
The function `strftimeToLuxonFormat` used brackets as escape character,
which was the escape character of moment.
This commit changes the escape character to be quotes, which is the
correct escape character for luxon.
https://moment.github.io/luxon/#/formatting?id=escapingclosesodoo/odoo#123192
X-original-commit: d69201a6fe78dc22baed1cede04092aa2ed0bf0b
Signed-off-by: Lucas Lefèvre (lul) <lul@odoo.com>
On Firefox only: some SVG shapes either disappear when flipped or are
not properly flipped.
This is due to the way Firefox parses SVGs and the way Odoo applies
transformations on them. It happens when the main `<svg>` contains other
nested `<svg>`, and the flip transformation is applied to each of them,
causing unexpected behaviors.
When the parent contains a direct `<svg>` child and both of them are
then applied a transformation, the whole shape disappears. When the
parent contains some `<svg>` inside a `<defs>`, and the children are
then included with `<use>`, each element is flipped individually, which
means the flip is not processed as we would expect.
This commit makes sure the flip is only applied to the main `<svg>`.
Steps to reproduce:
(A) >= 14.0:
- On Firefox, drag & drop the image-text snippet
- Add a background shape and choose "Origins 07"
- Flip it: it isn't flipped
(B) >= 15.2:
- On Firefox, drag & drop any block snippet
- Add a background shape and choose "Float 13"
- Flip it: the shape is hidden
task-3264851
closesodoo/odoo#123175
X-original-commit: 784b4dd1a7c0a75d301466a83a2894418ff8eaa2
Signed-off-by: Bojabza Soukéina (sobo) <sobo@odoo.com>
In this commit,
1. Adding a safeguard to ensure date_from is not empty before calculating the
time delta in the wizard.date_to.
2. Both classes disabled="1" and disabled="true" are not working so we add
a disabled class on the button. I don't know why disabled="1" is not working.
task-3328601
closesodoo/odoo#123148
X-original-commit: 97b8d59a88e78afbeae1dc6447a3d9629635524f
Signed-off-by: Kevin Baptiste <kba@odoo.com>
*website
Steps to reproduce the bug:
- Add a Cover and a Picture snippet on the website.
- Change their visibility to "Conditionally".
- Change the order of the two snippets on the page either with the drag
and drop tool or with the "move up" or "move down" option.
=> Their order on the "Invisible Elements" panel has not been updated.
The problem is fixed by calling `_updateInvisibleDOM()` at the end of
`moveSnippet()` and `_onSnippetDragAndDropStop()`. Note that before this
commit, all the snippets with a conditional visibility were hidden at
the call of `_onSnippetDragAndDropStop()`. This is due to the call of
`cleanForSave()` from `_destroyEditors()`. `_onSnippetDragAndDropStop()`
has been adapted in order to, as for the "move" option, do not change
the visibility of those elements.
task-3203914
closesodoo/odoo#123027
X-original-commit: 3a023cf00812cfbbef7f3b406fbd01b74f07b7c8
Signed-off-by: Dieleman Guillaume (gdi) <gdi@odoo.com>
Signed-off-by: Colin Louis (loco) <loco@odoo.com>
*web_editor, website
Steps to reproduce the bug:
- Add a Text-Image snippet.
- Change its visibility to "Conditionally".
- Save.
- Edit again.
=> The eye icon indicates that the snippet is not visible but the
snippet is displayed.
Note that [1] introduced a mechanism to solve this problem (the
`cleanForSave()` of the `ConditionalVisibility` option) but the code was
not working correctly since [2].
Let's first remember that when calling `toggleTargetVisibility()`, two
main actions are performed:
- The addition or suppression of the `data-invisible` attribute from the
dataset of an invisible element. This attribute is responsible for the
crossed or not of the eye icon in the "Invisible Elements" panel.
- The call to `onTargetHide()` or `onTargetShow()` that performs among
other things the addition or the suppression of the
`o_conditional_hidden` class on an invisible element. This class is
responsible for the visibility of the element on the page in edit mode.
This being said, here is what happened at the "Save" before this commit:
- `cleanForSave()` of `snippetEditor` is called. If the related element
has the `o_snippet_invisible` class, `toggleTargetVisibility(false)` is
called (meaning that the `o_conditional_hidden` class and the
`data-invisible` attribute are added to the element).
- `cleanForSave()` of the `ConditionalVisibility` option is called and
before [2], the `data-invisible` attribute was removed from the
corresponding element.
- At the `DOMContentLoaded`, the `o_conditional_hidden` class is removed
from all the elements that have a conditional visibility. The visibility
of those elements on the page now depends on the rule set by the user.
The goal of this commit is to restore the mechansim of the remove of the
`data-invisible` attribute from the conditionnal elements at the
`cleanForSave()`.
[1]: https://github.com/odoo/odoo/commit/1c442782f887a8c16bae05a43fae13a310ac05df
[2]: https://github.com/odoo/odoo/commit/de3c29fab2bc5349da8a9418f9d0086d76e6f7de
task-3203914
X-original-commit: b10d6cbf78235acd170716d556578227cccfbc14
Part-of: odoo/odoo#123027
Steps to reproduce the bug:
- Add a form snippet on the footer of the website page.
- Change the visibility of the form snippet to "conditionally".
- On the footer settings, deactivate the "Page Visibility".
=> The form snippet is still present on the "Invisible Elements" panel
but clicking on it has no effects. Indeed, it is inside the footer which
is hidden.
The goal of this commit is to reorganize the "Invisible Elements" panel
in order to better visualize the hierarchy between the different
invisible elements. To do so, the list of the invisible snippet elements
(`[...$invisibleSnippets]`) is scanned. Each invisible snippet that is
the descendant of another is discarded of the list (to only keep the
"root" ones) and a map is created with its `keys` set to invisible
snippets that have invisible descendants. The `value` corresponding to
an invisible snippet element is a list filled with all its descendant
invisible snippets except those that have a closer invisible snippet
ancestor. The list of the root snippets is then scanned. Each root
snippet is inserted in the DOM as well as their descendant snippets
found thanks to the newly created map.
Note that thanks to this commit, another problem is solved:
- Add a cookie bar on the website.
- Add a Text-Image snippet and change its visibility to "conditionally".
- Save and edit again. Note that the "Cookies Bar" is above the "Text-
Image" on the "Invisible Elements" panel.
- Click to display the cookie bar.
=> The order of the "Cookies Bar" and the "Text-Image" is switched on
the "Invisible Elements" panel.
Indeed, before this commit, the order of the snippets was influenced by
the order of their snippet editor creation. Because this order was not
always the same from one call to `_updateInvisibleDOM()` to another, a
glitch could happen when toggling a snippet visibility.
This is now fixed as the order of the invisible snippets in the
"Invisible Elements" panel is determined either by their order in the
list `rootInvisibleSnippetEls` or their order in the lists contained as
value in the map `descendantPerSnippet`.
task-3203914
X-original-commit: 548e95b3dc9bf642c5eea3fc43b83f7ce282be0b
Part-of: odoo/odoo#123027
Steps to reproduce the bug:
- Create a storable product with BoM:
- add any product as component
- save
- Click on the BoM overview widget
- Change the quantity of a BOM with a number that has a decimal
value.
Problem:
The quantity is converted to an integer because this input does not
accept a decimal value.
opw-3288403
closesodoo/odoo#123024
X-original-commit: de5087df501bffdaa14ca6a8b7a19da802f4e016
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
When the value of fields is getting None. And no value is assigned to the
`field`. So the traceback will be generated.
In this commit, we will assign a default value to the field if the field gets a
None value. So that it won't get a None value in any case.
sentry-4211843089
closesodoo/odoo#123193
X-original-commit: 3e652808305d3ef4674963195f3c7cdf91b37654
Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>
Signed-off-by: Archana Vaghasiya (arva) <arva@odoo.com>
The missing 15A tax report line was added in odoo/odoo#90369 but it was not included in the VAT Payable/ Refundable Total line.
With this commit, we add codes to TotalA and TotalB and modify the final total to use these codes instead.
Bug report directly to me
closesodoo/odoo#123190
X-original-commit: d813d807c6454dd6cd0b613e9df386eb0ddfd619
Signed-off-by: John Laterre (jol) <jol@odoo.com>
Signed-off-by: Ayob Habib (ayh) <ayh@odoo.com>
Before this commit, the columns in the "contact" footer template were
aligned at the bottom, which looked bad and served no purpose.
This commit aligns the columns towards the top, like the other footer
templates.
Steps to reproduce the bug:
- Choose the "contact" footer for the homepage of a website.
- Add multiple lines in one of the columns of the footer.
- The columns are aligned at the bottom, and it looks quite ugly.
task-3321445
task-3241256
closesodoo/odoo#122274
Signed-off-by: Outagant Mehdi (mou) <mou@odoo.com>
Previously, a performance improvement landed on 5a2efd2.
It totally makes sense, but there's a corner case that's actually hurt by that
commit: there are cases where the heavy computation of employee_quantity_available
is simply not used by the following loop.
This commit solves it.
It also improves the readability of the code by unpacking and properly naming
some variables.
closesodoo/odoo#123122
X-original-commit: 902305908780336050a0d5b778727a6c06c7a2fd
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Before this commit, the attachment button had icon and label on
different lines in mobile, which made the chatter topbar bigger
in height than it should.
closesodoo/odoo#123098
X-original-commit: 1afe20789fcf197ccc0a240d39d57d10e1f1454a
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
The adapted tests passed on runbot but failed (at least) on chrome
113.
closesodoo/odoo#123097
X-original-commit: ac1a158b5f6c04f94573a2fb6c7c94d9506e39aa
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
Before [1], chat windows were not shown on the website preview.
Showing them was not intended and those chat windows overlap
with the one of the livechat.
This PR restores the previous behavior by preventing chat
windows to be shown on the website.
[1]: odoo#110188
closesodoo/odoo#123096
X-original-commit: 3e74f5c1f4ea045725edcd945276e524529ffd97
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Signed-off-by: Stockbauer Matthieu (tsm) <tsm@odoo.com>
This commit removes the css that was creating two layout issues :
[1] When the chatter was rendered under the form view with the
`isInFormSheetBg` class, it added an unwanted background and border.
[2] When an attachment was uploaded and created a preview (eg. in
approvals), it created an unwanted border.
This commit fixes these issues.
task-3334866
Part of task-3326263
closesodoo/odoo#123095
X-original-commit: 5171b0bb2054f4755d0ba70b6820806c5253774d
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Steps to reproduce:
- install l10n_be (company B)
- stay on Company A and create a cash rounding
- Go to Company B and create an invoice
- In Other Infos > Cash Rouding Method, set it to the earlier created one
- Save
Issue:
You won't be able to save. But the message is too generic to know what is the cause of it
"Missing required account on accountable invoice line."
Cause:
The field `profit_account_id` is company_dependent. Therefore, the same cash rounding record will be accessible in both companies but in Company B the `profit_account_id` won't be set.
When Saving, we compute a cash difference (rounding) and try to create a new line for it. But since there is no account set, the sql constraint will be raised.
Solution:
The less dirty solution is to have an onchange that check that whenever we want to set a cash rounding method, it has all the required fields set
opw-3185950
closesodoo/odoo#123072
X-original-commit: e0df7cafefa3c2956105bd35c5bedc0c5bcdffaa
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Yolann Sabaux (yosa) <yosa@odoo.com>
This fix is a followup to the changes made in 5d951d9
where `format_currency` is replaced with `formatCurrency` which is based
on a more standard way offormatting monetary values.
closesodoo/odoo#122420
X-original-commit: b56a5d1
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Signed-off-by: Heinz Robin (rhe) <rhe@odoo.com>
When moving a package, the quant at source location is not
automatically removed
To reproduce the issue:
1. In Settings, enable
- Packages
- Storage Locations
2. Create a storable product P
3. Update the on hand quantity
- 1 x P at WH/Stock in package PK
4. Create a planned delivery D with 1 x P
5. Confirm and reserve D
- PK should be reserved
6. Validate
7. Open the package
- Its location is "Partner Locations/Customers", which make sense
8. Inventory > Configuration > ... > Locations, open WH/Stock
9. Current Stock
Error: There is a line with PK. The quantity is 0 but still, it
create some confusion for the user who could believe that the package
is still in WH/Stock
This issue does not occur if the user goes through the product form
and click on the on hand quantity. The "incorrect" quant will not be
there. This is because, when loading the action, we call
`_quant_tasks`:
https://github.com/odoo/odoo/blob/05a7f5c04804423cfc3a833a1b3f0b5eec3fc147/addons/stock/models/stock_quant.py#L296-L300
This method will clean the quants (merge & unlink)
However, in the above case (step 9), the action is defined on XML side:
https://github.com/odoo/odoo/blob/7d4dfeb0e26b387dee312897264a68963f90267f/addons/stock/views/stock_location_views.xml#L24-L26https://github.com/odoo/odoo/blob/d956e719d43c68abe6210e3136db576aaa6f60b8/addons/stock/views/stock_quant_views.xml#L190-L196
So, we can't make it behave as it does from the product form,
unfortunatly.
As alternative, we can try to call `_unlink_zero_quants` when we are
moving a package (and not `_quant_tasks` for perf matters as, so far,
we will not have any quant to merge)
OPW-3292238
closesodoo/odoo#123071
X-original-commit: 30cbfdc79e54a7e7a260051da321837cd224792c
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Adrien Widart (awt) <awt@odoo.com>
Before this commit, when clicking on a category in emoji picker
when using Firefox, sometimes the previous category was selected.
This come from Firefox selecting the previous sticky section with
`getBoundingRect()` and `elementFromPoint` on grid top coordinate.
This commit fixes the issue by rounding to the integer, so that
the previous hidden and sticky section is not selected in Firefox.
closesodoo/odoo#123068
X-original-commit: ecae83ef9bd93a55e296023bc8c735f04d5e73f8
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Prior to this commit, the svg icon of `board` had duplicate `viewBox`
that breaks the svg.
This commit fixes this issue.
task-3343278
Part of task-3326263
closesodoo/odoo#123067
X-original-commit: 48c8c6b32951e6393e41f2705dbdd9020dae971b
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
A recent refactoring of discuss app unintentionally removed the
feature to automatically notify and open chat window with new user
when they log in for the 1st time.
closesodoo/odoo#123044
X-original-commit: 9132dacbf9b4b9d000b6d0be23938b46db1035a1
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Expected singleton: res.currency() when currency not provided
also when remove company in invoice.
Steps to Produce:-
- While go to invoice and click on `REGISTER PAYMENT`
- Remove currency from wizard
Traceback will be generated.
Applying this changes will resolve this issue.
sentry - 4149615534
closesodoo/odoo#123031
X-original-commit: 3e2bbb3c6d84688ab628a7559f1f5329d2172339
Signed-off-by: William André (wan) <wan@odoo.com>
Before 16.0 and https://github.com/odoo/odoo/pull/78857 the session
cookie duration was set to 3 months, but the server-side garbage
collection of inactive session was reaping them after 7 days of
inactivity. The cookie lifetime was essentially superseded by the
server-side GC.
After https://github.com/odoo/odoo/pull/78857 these limits were made
consistent with each other, but the lifetime value was kept at 3 months,
which is a bit too long as a default.
This commit changes the default SESSION_LIFETIME back to 7 days for both
limits.
In addition, since the server-side GC is now implemented by a
database-specific cron job, this commit introduces an optional system
parameter `sessions.max_inactivity_seconds` that can be set to override
the default server-side GC threshold, to make it shorter.
Note 1: the ICP does not modify the cookie lifetime which will remain set
to the default 7 days. This means normal browser sessions won't stay
alive for longer than 7 days of inactivity. So `sessions.max_inactivity_seconds`
can't be effectively set to a longer expiration time.
This seems like a reasonably safe default.
Note 2: the session GC happens during the execution of the autovacuum
cron job ("Base: Auto-vacuum internal data") which is scheduled once per
day by default. When setting a small `sessions.max_inactivity_seconds`
value, it may be necessary to increase the frequency of that cron job
accordingly.
closesodoo/odoo#122964
X-original-commit: 05ff9a2db32c2fb1afa107ac005423218f452290
Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>
Currently when a server action causes an error it raises an Exception
which will be caught by sentry and causes unnecessary traffic.
So, we stop catching exceptoins from server actions which are supposed
to be generated by User's Mistakes.
sentry-4169384356
closesodoo/odoo#121707
Signed-off-by: Adrien Widart (awt) <awt@odoo.com>
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Before this commit, the name and description of resume lines
were not translatable.
task-3323624
closesodoo/odoo#121166
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Employee presence is not a sensitive data and should be available for all db users
this commit moves the computations from attendance, holidays and hr_presence to the
employee_base model, which is how it was originaly made in the hr module. This way
the presence marker does not depend on the user's hr rights
closesodoo/odoo#118437
Task: 3267790
Signed-off-by: Kevin Baptiste <kba@odoo.com>
A raw query is not necessary to produce the desired result, found
activities need to be kept only if the corresponding record can be found
with standard search (which includes multi-company check).
Part of task-3266643
closesodoo/odoo#123070
X-original-commit: 9dd7ae942aebe2cfd3e2dcd52e10b3bff5c8e0a9
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Before this commit, when a discuss composer is open on Safari,
the focus was locked inside the composer. Click away did not
resolve it.
This most certainly happens because changing `selectionStart`
and `selectionEnd` on an input in Safari puts the focus on the
input.
This commit fixes the issue by not changing the current selection
of input just before backing up.
Related to https://github.com/odoo/odoo/commit/4efb465f6adcf8e4f9c6d4daa0b6f90079832af5closesodoo/odoo#123069
X-original-commit: 71c745ea81baeb02bf217f37bf9a4c64e435da05
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
When performing the picking action in the context of savepoint, the env
inside the action can randomly change causing an AccessError which is
caught as UserError (in the current point_of_sale code). Flushing before
calling a method in a savepoint will deterministically avoid this issue.
Note that the weakset used to store environments was modified in #121604
to avoid this kind of issue.
When using a cr.savepoint, the transaction must be flushed but in we
don't have any reference to the env that should be used on the cursor,
meaning that the env is chosen in the list of existing env. This choice
is random because Transaction.envs is using a Weakset.
In some case, the chosen env does not have the correct access right
because the context allowed_company_ids is corresponding to a company
coming from another test, leading to an access error, hidden by the try
except.
Flushing the environment before creating the savepoint will help to
prevent this issue by flushing on a well defined environment.
Note that the weakset used to store environments was modified in #121604
(master)
closesodoo/odoo#123048
X-original-commit: c7c268ed50c1f6fd6eebe7d8a01abdb9d4a32573
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
Steps to reprodue:
- Create a dropshipped product
- Sell the product to a client with a different language set
- Print the delivery slip
Bug:
delivery slip is currently being printed in the vendor's language
Fix:
Print the delivery slip in the client language when possible
opw-3193015
closesodoo/odoo#123047
X-original-commit: 0ad04a80b1f99feda2fdefbf24cbc3c494110a8d
Signed-off-by: Adrien Widart (awt) <awt@odoo.com>
Signed-off-by: Walid Hanniche (waha) <waha@odoo.com>
This reverts commit bfadb8e491fe2acda63a79f9577eaaec8a1c8d9c.
Since that commit, the domain may be double-encoded in the database if
the user reorganizes the layout of his dashboard: once by the JavaScript
code, and once by the serialization of the innerHTML property.
However, there is no need to have it double-encoded, and some tools such
as the upgrade scripts will fail upgrading the domain.
With this commit, we are serializing the document to XML instead of HTML
and therefore the produced output is valid XML that will be correctly
interpreted by all the tools.
However, double-encoded domains might still be present in existing
databases, so we also need to take this into account when reading the
domain.
OPW-3130117
closesodoo/odoo#123045
X-original-commit: dd8f2640a281b86b73d3b296dd0a5aec7664eb4f
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Christophe Simonis (chs) <chs@odoo.com>
Signed-off-by: Paul Morelle (pmo) <pmo@odoo.com>
Issue:
------
In a multi-company context, the creation of a public holiday
in one company will affect leaves in other companies.
We cancel leaves that have the same time slot as the
public holiday, regardless of the company.
Solution:
---------
Take account of the company in which
the public holiday is created and compare
it with the company of the employee who has leave.
opw-3339973
closesodoo/odoo#123040
X-original-commit: 2d2d3388df7ffe0243d13d5b922b5ba6776a434d
Signed-off-by: Kevin Baptiste <kba@odoo.com>
If applied, this commit will solve the issue of keyError when we confirm the
manufacturing order and work order (s) are deleted.
Steps to produce:
- Configure BOM with 'Operations'.
- Set operations in the 'Consumed in Operation' field which is in 'Components'.
- Create MO using that BOM.
- Delete the work order(s) from MO.
- Click on the 'Confirm' button.
Fix this issue when the work order is not available for that operation,
setting False in stock.move record(s).
sentry - 4171798106
closesodoo/odoo#123033
X-original-commit: 36e02b91e88c5e014d132643b6ffb24a71342d6c
Signed-off-by: Parth Solanki (paso) <paso@odoo.com>
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Since this commit [1], the image cropping feature is no longer
functioning properly. The modification of the "activateCropper" function
code to remove the use of underscore has resulted in a change in the
"data" parameter value passed to the cropper compared to before. This
alteration is the cause of the issue.
Steps to reproduce the bugs:
- Open the homepage in Website edit mode.
- Drag and drop a text-image snippet onto the page.
- Click on the image in the text-image snippet.
- Click on the "Crop Image" button in the image options.
- Change the aspect ratio of the image by clicking on the "4:3" button.
- Click on the "Apply" button to apply the changes.
- Bug: The changes are not being applied.
[1]: https://github.com/odoo/odoo/commit/f4f0f783183507df8227b37fe1234c256325df6d
task-3339518
closesodoo/odoo#122996
X-original-commit: d42070b6abe5ca65d43ae4f2426619684c7aec4d
Signed-off-by: Colin Louis (loco) <loco@odoo.com>
Before a longpolling every 5 seconds was set up to sync the number of
orders per table in the pos_restaurant, which was not very
userfriendly / efficient.
Now, the longpolling has been replaced by a bus (websocket). As soon as
an order is sent to the server by another PoS, the server dispatches the
information to all other PoS using the corresponding floor plan.
The bus_service was initialized in the pos_store of the point_of_sale,
but is now used only in the pos_restaurant via override.
This was done for obvious future use.
closesodoo/odoo#121875
Signed-off-by: Heinz Robin (rhe) <rhe@odoo.com>
To reproduce (on runbot):
- Go to /groups url
- click on "Public Mailing List"
This fix `AttributeError: 'PortalMailGroup' object has no attribute 'env'`
(introduced by odoo/odoo@b60cf1f977)
closesodoo/odoo#123032
X-original-commit: 2bd4a907a0db07ee8bb7f4ffa3017f20c25f79d4
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: Xavier Alt (xal) <xal@odoo.com>
Before this commit, when viewing the received badges tab in an employee's
profile, there was a lack of spacing below the "Grant a badge" button.
This commit resolves the issue by introducing proper spacing between
the button and the displayed badges.
task-3329971
part of task-3326263
closesodoo/odoo#123028
X-original-commit: cace0db0aad57ee09edb1a41763b0a43aa1e46ff
Signed-off-by: Kevin Baptiste <kba@odoo.com>
This commit changes how automatic readonly props are applied to list
fields so that it doesn't override the getFieldProps method
It also fixes the method 'getCellReadonly' in ProjectTaskListRenderer,
which was renamed to 'isCellReadonly' in the framework but not in the custom renderer.
Task-3340379
closesodoo/odoo#123026
X-original-commit: da3b2421b3f851629d5d287223b7ef581a30a5ab
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Signed-off-by: Larcin Vincent (vila) <vila@odoo.com>
Co-authored-by: Vincent Larcin <vila@odoo.com>
Alexandre Kühn