Currenlyt, when using dark theme, spreadsheet is a mess. It's mostly
light theme, with some dark theme elements (mostly coming from odoo
components). There's even inputs where the text is white on a white
background.
o-spreadsheet code isn't prepared to handle dark theme. At all.
There are hardcoded colors everywhere.
Until we have a proper way to handle dark theme (use overridable scss
variables, rely on bootstrap), we force light theme for all elements
inside o-spreadsheet, including odoo components.
The css rules aren't pretty, but at least the spreadsheet is usable.
opw-3329765
closesodoo/odoo#123359
X-original-commit: 37a5f6a5b4b8ecbacf7a8ce4be822c6f348eb5da
Signed-off-by: Rémi Rahir (rar) <rar@odoo.com>
Currently, when we create a draft move in an empty period, a sequence
number (name) gets generated and set on the move. This is fine.
When subsequently we change the date of that move to a period that
already has entries in it, the sequence number (name) for our draft move
is recalculated according to the new period.
When we post a new move in this same period afterwards, and then
delete our previous draft move, we are left with a gap in the sequence.
Example: We already have a move on 2023-01-01 with name `2023/01/0001`.
We add two new moves `A` and `B` as follows.
| Step | Move | Action | Date | Name |
| ---- | ---- | ----------- | ---------- | -------------- |
| 1 | `A` | Add | 2023-02-01 | `2023/02/0001` |
| 2 | `A` | Change date | 2023-01-10 | `2023/01/0002` |
| 3 | `B` | Add | 2023-01-15 | `/` |
| 4 | `B` | Post | 2023-01-15 | `2023/01/0003` |
| 5 | `A` | Delete | | |
A gap is now created, since we have `2023/01/0001` and `2023/01/0003`,
but `2023/01/0002` was deleted (possible since it was in draft).
To solve this issue, we now make sure that when a draft entry is moved
to a period that already has entries in it, we reset the name to `/`,
to not consume a sequence number and prevent possible gaps in the
sequence later on.
task-3326834
closesodoo/odoo#123329
X-original-commit: 31f94b31b820799459ad70593abb74a2f5415b47
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Dylan Kiss (dyki) <dyki@odoo.com>
The 'view_partner_bank_search_inherit' is inherited from 'view_partner_bank_search' and it is using replace value of position attribute. This is not letting the fields already added in the base view to display.
Steps to reproduce:
1. Go to Bank Accounts in Contacts' configuration.
2. Try to enter some value in search field.
Current Behaviour:
The search field will not work properly and will not even display the columns to search.
Expected Behaviour:
The search field should display the columns and search the table.
OPW-3340543
closesodoo/odoo#123328
X-original-commit: 6371bc5ce85f728fcaa6561bad4bef1aba161687
Signed-off-by: William André (wan) <wan@odoo.com>
Since [this commit] which allows to have mega menu with transparency,
the user can see the color of the block which is positioned at the very
top of the page (behind the mega menu when it is open). Before that,
the gap was always gray.
Steps to reproduce the bug
- Have a mega menu on your site
- Put a block on top of the page
- Put a red background color on this block
=> When you open the mega menu, you can see the red color between the
mega menu and the navbar.
[this commit]: https://github.com/odoo/odoo/commit/147f99bb04f83943aaedbacb1844234288e60eaf
task-3327094
closesodoo/odoo#123312
X-original-commit: dba1dac5d0b09e999e194debcb5907affca61bd7
Signed-off-by: Outagant Mehdi (mou) <mou@odoo.com>
Signed-off-by: Dieleman Guillaume (gdi) <gdi@odoo.com>
A new validation was recently added to prevent importing
reserved quantities on stock move lines, to prevent inventory
discrepancies [1]. However, such validation inadvertently introduced
another issue, which is now, if the reserved quantity is not filled with
0, the new validation is triggered.
This commit fixes the above issue by not requiring the reserved quantity
to be provided.
In addition, a typo is fixed in the error message:
"it is not allow" -> "allowed"
[1] odoo/odoo#119201
X-original-commit: 79f825537aa6bed8cbcd7d7edab07ea0cb80a7cd
Part-of: odoo/odoo#123287
*: gamification, hr, hr_contract, hr_expense, hr_holidays, hr_org_chart,
lunch, mail, web
Since the Milk refactoring, the backend uses only `.rounded` avatar
images. The `.rounded-circle` classes on images have been replaced by
`.rounded`.
task-3336569
part of task-3326263
closesodoo/odoo#123286
X-original-commit: b492049788353274fb32bb6fbe4d40e97a184a87
Related: odoo/enterprise#41798
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
as Adyen sends the same notification data for POS and online payments
that can not be distiguished, the webhook controller logs a stacktrace
for every POS payment. If the payment_adyen is installed it generates
noise in logs as the POS transaction can not be found in online
payments. To clear the log we make missing transaction as warning to
not log the stacktrace.
task-2960381
closesodoo/odoo#123282
X-original-commit: 4754895ac7901c497f33a6bf9be6d18c0b4b55d8
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Signed-off-by: Valeriya Chuprina (vchu) <vchu@odoo.com>
The report_stock_quantity model defines a view in its init method
to compute quantity information related to stock. This view
is made of two CTEs and a three-part query separated by UNION ALL.
The first CTE, existing_sm, retrieves the stock_move data
from the database that are later used by the remaining of the query.
One of the where conditions of existing_sm is (m.state != 'done' or
m.date >= ((now() at time zone 'utc')::date - interval '3month')).
m.state != 'done' is translated to m.state <> 'done' by the query planner.
This type of operator has the side-effect of turning off index scan.
Therefore, the scanning of the existing_sm CTE performs a Seq Scan
and applies the where conditions in a Filter node. This can be quite
ineffecient if the stock_move table is big, and if the selectivity
of the m.state != 'done' condition is high enough to theoretically
justify an IndexScan.
To fix that, we take the inverse of m.state != 'done', i.e. an IN cond.
This allows postgres to use Bitmap Scan, which
is usually better under these specific conditions.
E.g. speedup: db with 7M stock_moves, select from report_stock_quantity
with conds for state, date, product_id, warehouse_id, company_id
4.5s -> 2.5s
opw-3288364
closesodoo/odoo#123221
X-original-commit: aad458e5c5ecf8e843bbe8ddb7710b93eb95b362
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Van Delft Aurélien (avd) <avd@odoo.com>
Before this commit, when a snippet section was hidden on mobile devices
and its height was then set to 50% or 100%, the visibility classes
remained as "d-lg-block" instead of "d-lg-flex". This inconsistency
resulted in the content not being vertically centered until the "hidden
on mobile" toggle was turned off and then back on.
Steps to reproduce the bug:
- In edit mode, drag and drop a "Text" snippet onto the page.
- Click on the "Mobile visibility" option button to hide the snippet on
mobile devices.
- Click on the "50%" button in the "Height" option of the snippet.
- Bug: The content within the "Text" snippet is not vertically centered.
This commit fixes the issue by properly updating the CSS class set by
the mobile visibility option when the "height" option is enabled.
task-3224575
closesodoo/odoo#123135
X-original-commit: 0377b035eff80baec3f78ea984e12ad1422dbf7a
Signed-off-by: Bojabza Soukéina (sobo) <sobo@odoo.com>
Adding methods to trigger the cash drawer opening as well as a log in
the message to state by who and for which action the cash drawer was opened.
There is also a log now for when in an action for which the cash drawer
was opened is canceled. The action concerned are: Cash control at opening,
cash in / out, Cash control at closing.
task-3293113
closesodoo/odoo#121110
Signed-off-by: Monnom David (moda) <moda@odoo.com>
When user create a pos category from 'restaurant.printer' model in
'pos_restaurant' module. it will give an error with the
message -
'sequence item 0: expected str instance, bool found'
Steps to Produce:-
1. Install 'pos_restaurant' module
2. Go to 'point_of_sale' module
3. Go to 'Configuration' -> 'Order Printers'
4. Click on any printer or create new
5. Under 'Printed Product Categories' click 'Add a line'
6. Click 'New'
Trace-back will be generated.
Applying these changes will resolve this issue.
sentry - 4072172292
closesodoo/odoo#123247
X-original-commit: c99090d4b70f293d3784c19511d0a1f3078e3d9c
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Signed-off-by: Preksha Chouhan (prec) <prec@odoo.com>
Previous commit (https://github.com/odoo/odoo/pull/116570) renamed
this method _get_subtasks_recursively.
But instead of calling itself in the return statment, the
method _get_all_subtasks was called resulting in a non-recursive
function and to potential undesired behavior as _get_all_subtasks calls
_get_subtask_ids_per_task_id that calls _get_subtasks_recursively in
some cases.
With this commit, we just call _get_subtasks_recursively on the children
to make it actually recursive, like it was in the first place.
closesodoo/odoo#123149
X-original-commit: 3a6f5e4d8eddaa4effbf96d8b59d47afc0ee9503
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Signed-off-by: Audric Onockx (auon) <auon@odoo.com>
ValidationError: PayPal: Missing value for txn_id (78X739757D473425R) or
txn_type (None).
This issue occurs when there is some missing value in the received
notification_data while evaluating the '_process_notification_data' function.
It raises an Exception which will be caught by the sentry.
sentry-3954375754
closesodoo/odoo#123191
X-original-commit: 8c539133f374ad709b5ed7770b15a3233e2463b2
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
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>
Lucas Lefèvre