In a grouped kanban view, drag a record and drop it in a folded
column. Before this commit, it opened and loaded the target column.
It shouldn't, the column should remain folded. This behavior has
been introduced in v16 with the wowl views.
This commit restores the legacy kanban behavior, which keeps the
target column folded and thus doesn't load it. We ensure that
the progressbar of the source column is correctly updated though.
Task 3208098
closesodoo/odoo#115728
X-original-commit: d6d6e4f64ea379a6795b139c5fafd604b7e185eb
Signed-off-by: Géry Debongnie <ged@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
In cases where the progress record does not yet exist, it is not
possible to toggle the visibility of the onboarding panel.
Therefore, we hide said button.
Task-3192327
closesodoo/odoo#115727
X-original-commit: 68e3e2b93d9028d6c469c627ef6d1b3c661a70a2
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Before this commit, when scrolling in messaging menu, the header was scrollable too,
which shouldn't be the case.
closesodoo/odoo#115715
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
On listview, a m2m_tags takes two lines when it's not needed to avoid
this effect we reduce the flex basic value by half wide should still be
plenty enough space to be an easy target to hit.
Task ID: 3074587
closesodoo/odoo#115714
X-original-commit: 0527d170606fcc32e3dcc096470da8288228610a
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit, when a record had a very long
display name, the name could be cut in the middle of a
word in the many2one's dropdown.
Now, these names are truncated and have ellipsis to tell
the text continues.
task id: 3234714
closesodoo/odoo#115712
X-original-commit: ed9f9098e3b85c8c739ed7fa5ff6b28bfa2e3584
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
In some databases, there are multiple bank statement lines linked to the
same move. Example:
* account_move:
id | statement_line_id
---+------------------
5 | 20
* bank_statement_line:
id | move_id
-----+--------
20 | 5
21 | 5
Thus, joining both tables should be done using the
account_move.id and the bank_statement_line.move_id. Otherwise, some
bank_statement_lines will be missed.
opw-3202392
closesodoo/odoo#115687
X-original-commit: c63cdde8506e201bf3313c5566049dde6692d0a6
Related: odoo/enterprise#38338
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: Julien Van Roy <juvr@odoo.com>
Before this commit: if you had a pos order with one product and one
quantity, it wasn't possible to refund less that one quantity.
Steps to reproduce:
1. Create POS order with any product -> Qty = 1.0
2. Go to the refund page -> Select Order -> Update Qty to 0.5 -> Click
on the 'Refund' button
The solution is to keep the input quantity in case of a single product
refund.
issue https://github.com/odoo/odoo/issues/112291closesodoo/odoo#115671
X-original-commit: d7baf99405d2b5ee092a38e2beb3b201292b9345
Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>
Signed-off-by: Pedram Bi Ria (pebr) <pebr@odoo.com>
To reproduce the issue:
1. Create a product:
- Type: Storable
- Category:
- Costing Method: AVCO
2. IN 2 @ 4.63/u
3. IN 5 @ 3.04/u
4. OUT 0.1
5. Repeat step 4 70 time in total, so that the final quantity is 0
6. Open the inventory valuation of the product
Error: the total value is $-0.04 instead of $0.
The compensation of rounding issue is stuck by a check that ensure we don't erase a valuation error.
However, this check can never succeed with small quantities, here is the mathematical proof:
°Current check: rounding_error <= qty * curr_rounding / 2
With:
1) rounding_error >= curr_rounding
2) 0 < qty < 2
3) v1 = rounding_error / curr_rounding
4) v2 = qty / 2
We can be sure that:
5) v1 >= 1 because of 1)
6) v2 < 1 because of 2)
7) v1 > v2 because of 5) and 6)
° rounding_error <= qty * curr_rounding / 2
° rounding_error * curr_rounding <= qty * curr_rounding / 2 * curr_rounding
° rounding_error / curr_rounding <= qty / 2
° v1 <= v2
==>> This contradict 7), hence this check can never be True for qty < 2
To fix this issue, we change the check to:
° rounding_error <= qty * curr_rounding / 2 OR rounding_error <= curr_rounding
Where the 1st part doesn't change, but the second one is true when rounding_error == curr_rounding
closesodoo/odoo#115668
X-original-commit: 7825e0e474bdfedc741a20af0e1ee0ffba9a25fc
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: David <dafr@odoo.com>
Support is limited and more of a hindrance than a help, as some
clients' suppliers create PDFs with broken scripting which trigger the
autoprinting any time they're loaded and can have other odd
misbehaviors, which is a hassle.
OPW-3208409
OPW-3222228
closesodoo/odoo#115659
X-original-commit: a7331d9709c8e097356f89bf144986f441c8f2cc
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Add new icons allowing editor to choose how text should wrap around the
image when adding a picture inside a paragraph.
task-3235798
closesodoo/odoo#115629
Signed-off-by: Bouvy Damien (dbo) <dbo@odoo.com>
Since [this first commit], the elements that make up the submenu of the
navbar of a website can no longer overflow the page. Depending on
whether the content is too long, the elements are aligned to the left or
to the right. Unfortunately, since [the merge of the frontend into the
backend], the dynamic alignment no longer works in edit mode. This commit
restores the dynamic alignment of the submenu items so that they no
longer overflow the page in edit mode.
Steps to reproduce the bug:
- Have a submenu with a long element in it
- In edit mode align the navbar elements to the right
=> When opening the submenu in edit mode, the long element goes over the
page instead of being aligned with the right side of the menu.
Technical explanation:
In edit mode, the dropdown opening in the navbar is done by
`WebsiteWysiwyg` which is instantiated in the backend while the function
that allows to align the submenu elements correctly is declared in
`menuDirection` in the iframe. So the dropdown must be opened with the
Bootsrap instance of the iframe in order for the iframe to detect that
the dropdown has been opened.
[the merge of the frontend into the backend]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3b
[this first commit]: https://github.com/odoo/odoo/commit/392c91cda3133b921e9aca9a7b1c511231027438
task-2904507
closesodoo/odoo#115607
X-original-commit: 11f817e8d0b0764427f0db7d62fb0cdd403e3012
Signed-off-by: Vray Benjamin (bvr) <bvr@odoo.com>
Since [this first commit], the elements that make up the submenu of the
navbar of a website can no longer overflow the page. Depending on
whether the content is too long, the elements are aligned to the left or
to the right. This was done with the public `menuDirection` widget which
looked at the available space on the left and right and depending on the
size of the submenu elements, aligned the submenu in an optimal way. It
has now been decided to get rid of all this widget because Bootstrap
(with Popper) knows how to position dropdowns dynamically. Unfortunately
Bootstrap has limited this dynamic positioning by disabling it on
dropdowns that are in a navbar. So this commit removes the public widget
and replaces it with a bootstrap patch so that dropdowns are dynamically
aligned in navbars too.
Note that if we had not made this patch in master, we would have had to
adapt the public widget to the migration to Bootstrap 5 (see original
commit).
[this first commit]: https://github.com/odoo/odoo/commit/392c91cda3133b921e9aca9a7b1c511231027438
task-2904507
X-original-commit: b6963dc21bad4b012aace16b9ea9264c33a0d618
Part-of: odoo/odoo#115607
No need a common file for 3 tests. On top of it contains
global variable and a lot of indirection, making it impossible
to read.
Also before the quant reservation commit, a savepoint was call
during the action_assign and trigger a flush and recompute all.
Since it has been remove, it's computed during the first read on
it, that's during the mark as done and since the MO state is not
draft it will keep the default value (False). Call it after create
to trigger the computation at the right time.
+ a bit of linting
closesodoo/odoo#115328
Related: odoo/enterprise#38207
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
A lot of issue with "It is not possible to unreserve more products of ... than you have in stock".
It's the result of a desynchronisation between
`stock.move.line`.`reserved_qty` and `stock.quant`.`reserved_quantity` fields.
It should never happens in theory. However we already faced it a lot due
to bugs/custom code/server actions... It's not trivial to fix because
the issue come from data corruption. So it is hard to spot the different
main issues.
In order to avoid it, this commit try to modify the structure of stock
module. Before the operations was made in this order:
- The `stock.move` checks the quantity available on `stock.quant`
- The `stock.move` write the quantity reserved on the `stock.quant` and
save it in a variable
- The `stock.move` create a `stock.move.line` with the quanity reserved.
The main issue is that a `stock.move.line` could be easily created with
a reserved quantity while the `stock.quant` are not update nor checked.
After this commit the operations will be:
- The `stock.move` checks the quantity available
- The `stock.move` dispatch the available quantity among the `stock.move.line`
based on create or write calls.
- The `stock.move.line` reserve the quantity on `stock.quant`
- If the quantity is bigger than available, we write the max available on
`stock.move.line`
The idea is to respect the different layers
`stock.move` <-> `stock.move.line` <-> `stock.quant`.
Avoid the interactions bewteen `stock.move` and `stock.quant`
This behavior is already well managed in other use cases.
E.g. the real quantity itself, `_do_unreserve` of `stock.move`,...
opw - a lot
Part-of: odoo/odoo#115328
In 64fc704527, we made it so that when an
async module throws an error, we catch the error and log it so that we
can mark the module as being in error. This means the error is now
invisible to the error service.
We do not want to rethrow the error, as this would stop us from loading
the rest of the modules, but we can still allow the error service to see
the error by simply dispatching it as a promise rejection in a separate
async call stack, allowing us to continue loading modules but also
giving the opportunity to the error service to see the error if it is
started.
Closes#92192closesodoo/odoo#115230
X-original-commit: facc0f0c022df94487ef9518348f039b56c7b536
Signed-off-by: Samuel Degueldre <sad@odoo.com>
This commit fixes an issue that causes thin spacing to appear between
two snippets containing shapes. This bug had already been fixed in this
commit [1] but the theme snippets have not been adapted to the changes.
With this commit, the shapes of theme snippets are automatically adapted
when they are dropped on the page.
Steps to reproduce the bug:
- Choose the "Clean Theme" for a website.
- Drag and drop a "Call to action" snippet on the page.
- Drag and drop a "Text" snippet with a dark background before it.
- Resize the window to change the window width.
- At some points, the gap will appear.
[1]: https://github.com/odoo/odoo/commit/42b3ad10e0b32b7fc72f801e2c67d6baf938c566
task-2824607
opw-3069213
opw-3057533
closesodoo/odoo#115004
X-original-commit: 256ff539afe331544ccb58848f1ecd0eecbe4daa
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
The value of the timer was wrong when timesheeting with multiple employees
at the same time.
The problem was that the compute duration already takes the current timesheets
into account. So the problem was that we added some time
that was already in the duration
task id : 3216277
closesodoo/odoo#114901
Related: odoo/enterprise#38007
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
This commit add a mass start and stop buttons that allows to start
or stop multiple workorder at the same time.
Starting a workorder checks if the user needs to be logged and
if the workorder is not blocked.
This commit also change the appearance of the mark as done button
task id : 3216277
Part-of: odoo/odoo#114901
Explanation:
A rework of hr_expense has been introduced in master and landed in 16.2.
https://github.com/odoo/odoo/commit/f79ff3fb374650670e89f231aaf17bb8d6596c25
There was a need to backport it to 16.0 then 16.1.
https://github.com/odoo/odoo/commit/90affb562962d0dc233526e3f15f5b60f383331d
During the backport;
- a computed fields 'journal_displayed_id' has been introduced and will need to be removed again in master.
- 2 bugs have been discovered:
-- the analytic.account were not created anymore (function not called)
-- the payment terms for expense paid by company could not be modified as a filter was missing
closesodoo/odoo#115650
X-original-commit: 672f4efd2c990ab6eef8f934c41625860b8ded46
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: Detry Thomas (det) <det@odoo.com>
Move the kanban gauge field from web_kanban_gauge to web.
Also delete the web_kanban_gauge module and remove all its references.
opw-3231911
closesodoo/odoo#115293
Related: odoo/upgrade#4437
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Since v16, the QRR reference would always be set at 000000000000000000000000000.
This was because of a conflict in the computation dependencies in account_invoice.py: _get_invoice_computed_reference (account_move) was called on a draft invoice, which hadn't compute its name yet. Since the computation of the QRR invoice checks for this name in order to integrate it into the reference, the space dedicated to the name was instead filled with 0 (see _compute_l10n_ch_isr_number).
By manually computing this field, we ensure the reference computation can be completed.
This fix allows for a correct behaviour in v16, while a more sustainable change will be made in master.
closesodoo/odoo#115071
X-original-commit: 7852b0ee4dddf6cf96b6ce40cf7c24011b9ef33a
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
To reproduce
============
- on any app try to import a record that has subfields
- subfields are not matched and not even found on the list
Problem
=======
comparing to 16 **Allowing subfields matching** is disabled here in 16.1,
because of this condition that is checking the list of fields on a variable `fields`,
but this variable is not set before importing the file, so the condition is always true.
Solution
========
apply the condition on `res.fields` instead
opw-3209365
closesodoo/odoo#115639
X-original-commit: 284fab64e33ca398a0ebf69d3d6d59685480156d
Signed-off-by: Luca Vitali <luvi@odoo.com>
After 3a798039d6, the emoji in the chat box is not
properly position. This is because of the change in logic in the application
of the calculated position to take into account the tour pointer.
This commit restores the logic of reposition and then made the tour pointer to use
the onPositioned option to properly reposition its element.
closesodoo/odoo#115479
Signed-off-by: Bruno Boi (boi) <boi@odoo.com>
Before commit it you want to print original bills with report_original_vendor_bill and that your list contains a refund it ends up with a UserError "You can only print the original document for vendor bills.".
Fixing the filter, using the is_purchase_document helper, allows to properly print documents, including refunds.
closesodoo/odoo#115452
X-original-commit: 7dd553b8ec1bcea8487dfe71c336787f35d69bea
Signed-off-by: Laurent Smet <las@odoo.com>
The insertHTML test file was named too specifically while we want it to
test the recently renamed `insert` command, which doesn't only insert
HTML.
closesodoo/odoo#114176
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Although Odoo 16.0 was already adapted to work with python 3.11 in
67c7cea , the requirements were left untouched. The purpose of this
previous work was to prepare for the next Debian Bookworm release.
With this commit, the requirements are updated to match the python
packages versions from Bookworm. That way, it will allow people who
installs Odoo in Python 3.11 environments by using the requirements
should be able to do so.
Closes#114195
X-original-commit: fbe4932cd583a2cc019644807a7ea248d34eec80
Part-of: odoo/odoo#115618
## To reproduce:
=> Import 5 units of P1 at $5
=> Import 2 units of P1 at $2
----> Current valuation: Qty 7, Value $37, Std Price $5.29 (rounded)
=> Change standard Price to 7
----> Current valuation: Qty 7, Value $48.97, Std Price $7
## Solution:
To compute the value delta, we don't use the current standard_price (which may be rounded), but the current value_svl.
OPW-3233260
closesodoo/odoo#115574
X-original-commit: 07ad8744a37a3e8d5a665a452f050e0dfacc6917
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: David <dafr@odoo.com>
We have introduced a method that compute the download URL of a slide in the fix
odoo/odoo#113749 which we convert here into a computed field to simplify the
code.
Task-3196081
closesodoo/odoo#115267
Signed-off-by: Stéphane Debauche (std) <std@odoo.com>
This commit translate the ics file for an event to
the language chosen by the public user on the website.
For connected users, the ics file is translated to
the user's language.
Task-3199180
closesodoo/odoo#115599
X-original-commit: 2fa5ceaf2978036f44027c19abaf17afec1d5db3
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Since [1] when the Dynamic Snippet was first introduced, it also
introduced a concept of "inherited" snippets. Specific snippets would
all `t-call` the same template for their rendering.
A mechanism was introduced to deduce the `data-snippet` from the caller
template, but it stored the obtained value in the `t-called` template
itself. Because of this if several "specific snippets" that used that
template had to be rendered, they would all have the `data-snippet`
value of the first one that got compiled.
We could compile the snippet template into something having a
dynamically obtained `data-snippet` value, but then that would be
equivalent to just using a `t-attf-data-snippet`.
All specific snippets already do set a `snippet_name` in the context
because it needs to be added in the classes.
This commit therefore adds a `t-att-data-snippet` attribute on the
base template, and populates with that same value in `onBuilt` for
stable versions.
During forward ports across stable versions, each new caller must be
patched as well - and all patches must be removed in master.
[1]: https://github.com/odoo/odoo/pull/53175
task-2922635
closesodoo/odoo#115566
X-original-commit: 73d2c9f87bf9a1a792f4318325c2e52fc81db5f2
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Benoit Socias (bso) <bso@odoo.com>
When the user schedules a datetime for the emailing campaign, it creates
a ir.cron.trigger entry that should run the Mail Marketing: Process queue.
This fix tries to take this into account to calculate a next_departure
datetime closer to the true moment job will be run.
When the schedule datetime is between now() and the next call datetime
for the cron job (nextcall field), current logic will always chose
nextcall given the use of max(). This can be confusing for the end-user
as the information banner in the form view will indicate the nextcall date,
which in some cases can be way farther in the futur.
While a ir.cron.trigger is not a 100% guarantee that the cron job will
run at that specific time, it will give better feedback to the user for
when he should expected his mailing campaign to be send out.
Main changes:
simplified logic in _compute_next_departure to take into account
the implicit creation of cron.triggers (methods action_launch and
action_schedule)
added test_mailing_next_departure to simulate "Send", "Cancel" and
"Schedule Date" buttons on mass_mailing form view. Check ir.cron.trigger
model for presence of triggers for cron job "Mail Marketing: Process queue"
and assert if cron.trigger was created as expected
opw-3137819
original commit b98494d
some trailing whitespace got linted from commit 4cebf5
closesodoo/odoo#115068
X-original-commit: f82dec9e6433dc027391978420237efaa1d0be7d
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Commit [1] recently restricted the context sent to read records
and related records (m2o, x2m) in form views (see commit message
for details). It restricted the context in too many cases though.
For instance, open an existing record (or create a new one) with
an x2many, and add a line in that x2many. If there is an inner
x2many inside, and there're records in that inner x2many by
default, the context sent to read those records does not need to
be restricted, as this is not part of the (initial) read of the
whole form view.
To reproduce the issue, create a new invoice, add a line: the
default tax's name isn't correct ("15% (Sales)" instead of "15%").
[1] fa11f330b8closesodoo/odoo#115552
X-original-commit: 81c619113fed0b70c2bb69e016b18e1f93ce5983
Signed-off-by: Géry Debongnie <ged@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Steps to reproduce:
Create an expense by sending an email.
Make sure the product has a zero cost.
Issue:
The expense has no total amount even if
a unit price is detected in the subject of the mail.
Solution:
Compute a total amount if we have a unit price.
opw-3128566
closesodoo/odoo#115620
X-original-commit: eb629fa82cbf592184ed60d0bf309a26a4465b70
Signed-off-by: William André (wan) <wan@odoo.com>
Fix the populate script of account bank statements that
would try to create statement lines with an amount set to 0.
This is wrong, and also causes the populate to fail because
of a constrains
closesodoo/odoo#115597
X-original-commit: 273b99adc34d478d62d107040eae1db3ca883f6e
Signed-off-by: William André (wan) <wan@odoo.com>
Prior to this commit, the generation of token aliases in Ogone relied
on the util function `singularize_reference_prefix`, which is intended
to make transaction references (and not token aliases!) more
distinguishable by suffixing a timestamp accurate to the second. That
util function does not guarantee the uniqueness of generated reference
prefixes, which is okay because the final reference is further suffixed
if the prefix happens to collide with an existing reference.
Using the util to generate Ogone's token aliases, however, poses a
problem because aliases *must* be unique. Otherwise, a customer saving a
payment token at the same second as another customer would end up
linking their payment method to the other customer's payment token.
This commit drops the use of the util method and replaces it with a UUID.
closesodoo/odoo#115580
X-original-commit: 61d833ffcd1562950126d3c87c92569fe35a8b08
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Steps to reproduce:
- enable PICK + PACK + SHIP
- in Inventory/Configuration/Operations Types
- check print label in PACK
Bug:
print label is already enabled by default in the SHIP Operation
and it's not possible for the user to edit it.
Fix:
allow the user to disable print label on the SHIP Operation
opw-3085428
closesodoo/odoo#115572
X-original-commit: 0e26baa8881e44edc85f553559f9c572008a921c
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Since [1], when a filter dropdown menu is active a check icon is shown but it's
positioned over the carret of the dropdown sub-menu (e.g. a date field).
After this commit, the CSS rules for [1] are excluded when it's a
`o_menu_item` (OWL) to target only Bootstrap dropdown.
Steps to reproduce:
* Open the Sales app
* Filter by the `Create Date` and select a sub option
=> BUG the check sign is on the right
[1]: odoo/odoo@e24bff6991closesodoo/odoo#115551
X-original-commit: 965c6cdcdedcc8696f20a27c39273c0a24c941b8
Signed-off-by: Bruno Boi (boi) <boi@odoo.com>
Signed-off-by: Romeo Fragomeli (rfr) <rfr@odoo.com>
mrp_operation picking type is not handle by default in stock module get_description function.
Add default return to stock get_description function
opw-3232811
closesodoo/odoo#115533
X-original-commit: ea9632e643071ae1b0d85053fde506fb1a7c606f
Signed-off-by: Tiffany Chang <tic@odoo.com>
"Non-stored fields like product.template.location_id/warehouse_id cannot
be searched" log error is generated because the non-storable fields are
not searchable, so it shows a log error for those fields.
This commit added the blank filter_domain in the above fields to avoid
the log error in search.
This fix is for the "product.product" search view for the
"product.template" search view has already been fixed in
https://github.com/odoo/odoo/commit/a5835a160ea3f7aea37644ed4e1a49e2e4a6effd
sentry-3933983991
closesodoo/odoo#115522
X-original-commit: 92448abfb4d488cc03a14e5cec0ca15c49b8e8e5
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Aaron Bohy