Expected behavior : The log note sent when received quantity is updated should take into account the quantity already received.
Current behavior : The log note sent doesn't take into account the quantity already received for a 'stock_moves'. So it always displays `Received Quantity: 0.0 -> quantity in stock` instead of `Received Quantity: quantity already received -> quantity in stock`
Steps to reproduce the error :
- Create a RFQ with few units of a Storable Product (e.g. 5 units)
- Partially validate the receipt and create a backorder (e.g. 3 units)
- Validate the backorder (e.g. 2 units)
Log notes should be :
`Received Quantity: 0.0 -> 3.0`
`Received Quantity: 3.0 -> 5.0`
But are :
`Received Quantity: 0.0 -> 3.0`
`Received Quantity: 0.0 -> 5.0`
The value is always equal to 0.0 because `qty_received_method == 'stock_moves'` so `line.qty_received` is overridden by 0.0 in parent `_compute_qty_received` even though its value is already set to 0.0 (default) or to the quantity already received
opw-2600221
opw-2613116
closesodoo/odoo#78858
X-original-commit: 0c8ea86fb8d706af139cd2d412d01487e5899df6
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
and in the notification zone.
part of task-2634175
closesodoo/odoo#78865
X-original-commit: 88fc69c06e4f1516c8d95812395f1e2fbf10f44c
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Steps to reproduce:
1. Log on odoo with a user A on mobile device
2. Log on odoo with a user B on desktop
3. User B call user A
4. User A answer the call and the keyboard popup on the screen => BUG
To avoid this behavior, we disable the input auto-focus when we open a
chat window like other chatting app on mobile devices (like: Signal,
Messenger, WhatsApp...)
closesodoo/odoo#78864
X-original-commit: cf36921df8dff114f26a161c4f9d2f6a05ac2adb
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Currently the runner kinda sorta tries to run the message pump when it needs a message, but it makes for messy and convoluted code as the "request/response" callers have to deal with a bunch of events they don't understand or care for, and can lose other people's events entirely.
Try to use a more evented model: the downstream from Chrome is handled by a separate thread which can handle all events and responses somewhat uniformly. Request/response callers can register their desire for feedback and get a nice `Future` to wait on (or add a callback to).
Also:
* removes the failfast mode of JS tests as that mostly just makes fixing tests more annoying (as only one failure is shown per run)
* fix a hitbox bug in calendar on Chrome 94
* fix a somewhat latent race condition in the qunit test suite / runner, which triggered during the POS qunit run (and is now a hard failure)
closesodoo/odoo#77735
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
* remove `component_extension_tests`, that's a test from web and
already tested by web, no idea why it's rerunning in POS
* remove all failfast specs, after discussion with ged, seb, and
xdo it was considered not useful: it's mostly for the runbot but
turns out to be pretty minor as far as positives go, and it makes
fixing errors much harder
Part-of: odoo/odoo#77735
By delaying the check of `didLogInfo` until run end, it becomes
possible for the test suite to start running before all the test
modules have loaded, which leads to some of the modules loading after
the test suite "ends" and start running at that point, leading to
multiple teardowns of the test suite.
This would occur in the POS test suite, leading to the `QUnit.done`
callbacks running multiple times, and multiple `"test successful"` to
be emitted.
This has historically not been an issue (hence having remained
undiscovered), but with the "success state" being a `Future` it now
breaks the corresponding test, as a resolved future can not be
re-resolved.
Part-of: odoo/odoo#77735
The new handler changes the behavior of `wait_ready`: before it would
wait for the `ready_code` to be `true` *or a settled promise*.
Now it waits for `wait_ready` to resolve to true, whether it's a
promise or not.
Part-of: odoo/odoo#77735
The current system uses an imperative request/response model to a
communication which is full-duplex and thus (hopefully) more suited to
a reactive approach.
This updates the Chrome runner to:
* use a separate thread for reading from Chrome, which limits stalling
/ buffering
* uses futures for request/response cycles
* uses a callbacks system for events (unrequested messages from
chrome)
The test end (success / failure) is also signaled via a future.
This requires a bit more cleanup as the browser is reused for all
tests of a *class*, so e.g. the results future must be reset between
tests.
Also for convenience add debug logging of WS requests / responses,
it's convenient for looking at a test / tour's traffic.
Part-of: odoo/odoo#77735
How to reproduce the problem:
- Install hr_timesheet and create a project.
- Create a task in the project, and assign a Partner as the Customer
- In the Timesheet tab of the Task, add a new entry. Save the Task.
- Edit the task again and change the Customer. Save again.
-> the partner on the Timesheet entry did not change.
With sale_timesheet, the Sales Order Item of the timesheet entry can
be updated from the Sales Order Item of the Task, but it isn't the case
with the partner, which is not logical.
Solution : Now, the partner_id is computed and will automatically be
updated from the Task's Customer/partner_id. If sale_timesheet is
installed, it will first filter out the invoiced timesheet entry:
we don't want to change an already invoiced entry.
opw-2616784
closesodoo/odoo#78861
X-original-commit: 200a16ee15c0f2f2d07367eee984aaedccd26a6f
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
Due to floating point limitation, the quantities displayed in the
forecasted report should be formatted to ensure the rounding.
Issue example:
(Need stock)
1. Create a storable product P
2. Update its quantity to 7.1
3. Consult the Forecasted Report
Error:
Quantities are "7.1000000000000005 Units". In this case, the
floating-point issue comes from the method `float_round()`
Another example:
(Need purchase_stock)
1. Create a storable product P
2. Update its quantity to 0.1
3. Create a PO with 0.2 x P
4. Consult the Forecasted Report
Error:
The "Forecasted + Pending" quantity is 0.30000000000000004 Units. This
field is directly computed while rendering the report, it's the sum of
0.1 and 0.2 which, in python, results in 0.30000000000000004
(floating-point issue)
Since the rounding of these quantities are actually based on the decimal
precision of the UoM, this commit may slightly change the report.
Suppose the generic precision is .001 and the precision of "Units" is
0.01: if the quantity is 12.34, one zero will be added in the report:
12.340. However, these unnecessary zeros do not change the information
that is initially displayed. Moreover, the UoM precision can not be
greater than the generic precision, so we will never lose a part of the
quantity to display.
OPW-2611892
closesodoo/odoo#78853
X-original-commit: f4df8b5eec788cf701e58b02a4be58266d5ddc71
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
When a componentes is in a modal and uses the positioning hook (filter dropdown in the Search More modal for example), it will shifted from the toggler button.
This is due to a `-webkit-transform: translate3d (0, 0, 0);` applied on the `modal-body`
which influences the `position: fixed` attribute of `.o-popper-position` in the `dropdown-menu`
"It is positioned relative to the initial containing block established by the viewport,
except when one of its ancestors has a transform, perspective,
or filter property set to something other than none (see the CSS Transforms Spec),
in which case that ancestor behaves as the containing block. "
See: https://developer.mozilla.org/en-US/docs/Web/CSS/position
the translate3d was applied with https://github.com/odoo/odoo/pull/20314
As the bug is no longer exists, we can remove this style.
opw-2668638
closesodoo/odoo#78775
X-original-commit: 1f86e285aeb69578378cc89771cd090cc29ccc7d
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Achraf <abz@odoo.com>
- Improve _search methods of stock/product by using subqueries
- Improve efficiency _search_on_hand of stock.quant (see
odoo/odoo#77190)
closesodoo/odoo#78847
X-original-commit: 82562cc25c10500d30056ca19d816c1d211a24eb
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Signed-off-by: Rémy Voet <ryv@odoo.com>
Expected behavior : The order button should go green and active when you 'unskipped' an orderline
Current behavior : The order button doesn't go green and can't be clicked when an orderline is 'unskipped'
Steps to reproduce the error :
First of all, you need to setup a PoS Restaurant with these options :
~ Bar/Restaurant
~ Enable `Table Management`
~ Enable and setup `Order Printer` with IP Address and choose Categories to be printed on.
1. Open a restaurant session
2. Pick a table
3. Select a product and put it on hold
4. Select the **same** product and order it
5. 'Unskipped' the product from step 3
Order button should be green and active but is unactive so the order can't be sent
Previously, the condition was only based on the product_id so error occurs when multiline of the same product are handled
opw-2557518
closesodoo/odoo#78850
X-original-commit: 8159e5ac93b18d147fc8688f1dc48f75cbd44a9b
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
Steps to reproduce:
- On bank journal set the outstanding payments accounts and the
outstanding receipts accounts, respectively to 101403 and
101402
- In Accounting > Configuration > Settings > Default Accounts,
let the two outstanding accounts empty.
- Customer > payment > create a payment : payment type "Receive",
amount 5 for example. Save it.
- Edit the payment and change the payment type to "Send".
- Click on Save.
Issue
Got an UserError "Cannot create unbalanced journal entry"
Since the payment_type has changed, the computed outstanding_account_id on the payment is recomputed.
When splitting journal items using the _seek_for_lines() method, odoo is not able to retrieve the liquidity lines since outstanding_account_id has changed.
opw-2620046
closesodoo/odoo#78866
X-original-commit: 865c5d7741ca1bf003b4181d06484cc4ecaf8fcb
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Signed-off-by: guva-odoo <guva-odoo@users.noreply.github.com>
The commit 6135b04 forgot to remove from the assets_frontend bundle
the DebugMenu which depends from the @web/core/commands/... features.
closesodoo/odoo#78863
X-original-commit: 60f000a3d538cbc64f86aeef8aae66149d60ff7c
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Bruno Boi <brboi@users.noreply.github.com>
quotation_description on the sale order is copied from the
product template, where it already is sanitize_attributes=False,
and it has to stay like that because otherwise widgets like
"tab" or "accordion" cannot be rendered correctly.
This is also linked to a bug in the ORM where the _related_attrs
weren't copied correctly.
Related ORM PR: https://github.com/odoo/odoo/pull/78687
Ticket link: https://www.odoo.com/web#id=2487749&model=project.task
opw-2487749
closesodoo/odoo#78836
X-original-commit: ee90f6bcea35350efa9eae8db749199b39ff5644
Signed-off-by: Paolo Gatti <lordkrandel@users.noreply.github.com>
After some analyze on a lot of customer databases, seems like most of the time
their are performance probleme, and big store, it is due to a lot of big file
uploaded without reason. E.g. barcode, photo, ... a small one will be enough.
Now, we decided (in stable) to auto resize these pictures to 1920x1920px
by default and compress it with a quality of 80 when the source is bigger.
You can bypass this behaviour in your specific use case,
using a context key: 'image_no_postprocess' set to True.
You can disable the resize (and quality implicitely)
using an icp: 'base.image_autoresize_max_px' set to '0'.
You can change the default resize (1920x1920) format using an icp:
'base.image_autoresize_max_px' set to '<width>x<height>' (e.g. '1024x768')
You can change the default quality (80) using an icp:
'base.image_autoresize_quality' with a value between 0 and 100 where 0 skip it.
You can change the type of file that will be post process using icp:
'base.image_autoresize_extensions' (subtype of the mimetype comma separated).
Api of image has not be changed in this commit, only refactored to allow to
work with image directly without the need to encode/Decode in base64 the raw.
We decide to keep 1920x1920 by default instead of 1080p to avoid to resize
portrait picture in 1080px and stay consistent with field image_1920 that
return a 1920px image for width or height whatever the orientation.
+ fix some lint diff for ci style in master
closesodoo/odoo#78556
X-original-commit: d9ce0507960f247e1187baf7bd8399f90be237aa
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
There exists an optimization when creating fields to avoid calling
`setup_models()` for fields when creating a custom model, since the
latter already calls `setup_models()`.
We add the same optimization for field selections, so that creating a
custom field with selections only calls `setup_models()` once. Note
that both optimizations are combined when creating custom models with
selection fields: `setup_models()` will be called once for all.
closesodoo/odoo#78514
Related: odoo/enterprise#21746
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
Before this commit, trying to create a field related to another field in
the same batch raises an error, because the computation of the field
'related_field_id' cannot find the target field in the registry.
The new approach consists in getting the target field from the database
instead. It works when creating fields in batch, because all records
are inserted into the database before the field is computated.
This costs extra queries, but it allows to batch field creation and
avoids multiple calls to setup_models() when creating a model with
partner field in Studio. (see odoo/enterprise#21746)
The creation of a simple custom related field (related="x.y") costs 3
additional queries to determine the target field:
- 2 queries to get a given field on a given model
- 1 query to get the first field's comodel
Part-of: odoo/odoo#78514
The real overhead of creating a related field is actually two queries:
- one query in update_db_related, the purpose of this test
- one more query for _compute_related_field_id in flush()
With the previous version of this test, one prefetching done in the
first create was not present in the second create since it was in cache.
The fix clears the caches to make the creation of both fields in the
same situation, such that query counts are compared in a fair way.
Part-of: odoo/odoo#78514
Registry updates can be quite expensive (on the order of a second).
When creating new fields, this update is performed *for each field*,
leading to sub-par performances when bulk-creating fields.
Also remove `_existing_field_data` which has been unused since
9afce4805f, and the `clear_caches`
set up for that purpose.
Part-of: odoo/odoo#78514
When using a profiler manually inside the code, and longpolling uses
this part of the code, an error will appear on runbot since gevent
server cannot be profiled properly.
This fix mitigate the issue by disabling the profiler automatically in
this case.
Part-of: odoo/odoo#78514
When installing a database with all modules in enterprise,
install take around 20 minutes and almost half of that is spent in the
`setup_model` method.
There is actually two calls to `setup_models` for each module.
One of them was introduced in b5c50fa824
and only looks useful when upgrading a module with migration scripts.
This first fix proposes to skip `setup_models` if the module state is
`to install`.
closesodoo/odoo#78808
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
This reverts commit 4c18e2d09a372e975c2133516cc9bdd1880b2c1b.
This commit makes a barcode qunit test crash non-deterministically,
but quite frequently (50% of the time).
At the time of reverting this commit, we still don't know how this
commit affects this barcode test, but it's urgent to resolve by
revert and understand more in depth what are the causes.
closesodoo/odoo#78827
X-original-commit: 29eb6d3e5ea859955290a2c3f53908b80e16f03e
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Purpose
=======
This commit is enhancing the website_slides module.
Specifications
==============
It changes placeholders for certain fields, it changes helpers in some
of the views.
It updates some of the main views of the menus and corrects wordings
inside of them.
It activates the Graph and Pivot views for the reporting of
Courses, Reviews and Quizzes.
It cleans up some of the measures inside of the Pivot and Graph views
of each menus where it is available.
It also merges 2 models: slide.slide.link and slide.slide.resource into
slide.slide.resource with a type Selection field.
This is done in order to create a single table for the additional
resources of a Content.
It also improves the front-end of the module with minor changes.
It fixes the problem of long names inside of breadcrumbs.
It also adds a message when there is no leaderboard in /profile/users.
task-2597345
closesodoo/odoo#75646
Related: odoo/upgrade#2784
Related: odoo/enterprise#20480
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Purpose
=======
This commit is used to merge 2 models into 1: `slide.slide.resource`
and `slide.slide.link`
Specifications
==============
These models are merged in order to create a unique table for the
*Additional Resources* of a Content.
In order to do that, we merged the models into `slide.slide.resource`
that will contain either a link or a file.
task-2597345
See odoo/enterprise#20480
See odoo/upgrade#2784
Part-of: odoo/odoo#75646
Purpose
=======
This commit improves the front-end when we have no leaderboard yet
Specifications
==============
It hides the `Show All` button when we have no leaderboard.
It also modifies the leaderboard view if a user manages to get to it.
task-2597345
See odoo/enterprise#20480
See odoo/upgrade#2784
Part-of: odoo/odoo#75646
Purpose
=======
This commit changes a conversion variable
`RATING_LIMIT_SATISFIED` in order to follow a new conversion:
> 5/4 := Satisfied
> 3 := Okay
> 2/1 := Dissatisfied
Specifications
==============
This commit only changes the variable in order to limit the
modifications made to the `rating` module/models.
This is done in order to change the faces displayed for each review/rating
without impacting the statistics. The ratings/reviews will have the same values
as before but will only get a different conversion if higher than 4.
task-2597345
See odoo/enterprise#20480
See odoo/upgrade#2784
Part-of: odoo/odoo#75646
Purpose
=======
This commit is enhancing the website_slides module.
Specifications
==============
It changes placeholders for certain fields, it changes helpers in some
of the views.
It updates some of the main views of the menus and corrects wordings
inside of them.
It activates the Graph and Pivot views for the reporting of
Courses, Reviews and Quizzes.
It cleans up some of the measures inside of the Pivot and Graph views
of each menus where it is available.
It also merges 2 models: slide.slide.link and slide.slide.resource into
slide.slide.resource with a type Selection field.
This is done in order to create a single table for the additional
resources of a Content.
It also improves the front-end of the module with minor changes.
It fixes the problem of long names inside of breadcrumbs.
It also adds a message when there is no leaderboard in /profile/users.
task-2597345
See odoo/enterprise#20480
See odoo/upgrade#2784
Part-of: odoo/odoo#75646
This commit fixes the case where you have some text after a comment.
Until know, we miss it. Now we render the tail part.
```
<t>
<!-- HIDE Text 1 -->
Text 1
<p>SHOW Text 2</p>
</t>
```
After the fix, Text 1 is correctly rendered
This commit fixes#76628closesodoo/odoo#78782
X-original-commit: 566360b07b4ff6c7290f264d9064400df2b06ca5
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
when a message or logenote with attachment(s) is edited attachment gets removed
even if user does not want to delete attachment.
after this commit,
editing message text will update only message and attachment will not be removed.
attachment will be deleted only when user wants to delete it
closesodoo/odoo#78785
X-original-commit: dbd6cf34d3fcf9d66657b68766d2a25ee0d2515b
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Before this commit, When you try to edit the link then the link widget is
removing 'btn-block' class from the class list of the link node.
After this commit, the link widget will allow using 'btn-block' class.
closes#78511closesodoo/odoo#78783
X-original-commit: 888687b487e95b4bf4fb080118b5eb945c8ab724
Signed-off-by: Antoine Guenet <Zinston@users.noreply.github.com>
Mako is not used anymore for a long time.
closesodoo/odoo#78781
X-original-commit: fb9f89afbc7a22e82309150617e8b5de5c995ff9
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
With the release of Debian Bullseye the time has come for the balancing
act by trying to update the requirements.
The constraints are the following:
* Stick as close as possible to python3-* Debian packages versions
of the current Debian stable.
* Same but for the Ubuntu LTS version.
* When one of the above package is patched by Debian or Ubuntu
maintainers, set the upstream version that includes the patch if any.
Also, as support for python < 3.7 is dropped, some cleanup can be done.
The `reportlab / pillow` combo is a special case:
* Pillow has to be updated to 8.1.2 as this version includes the
security patches that were added to Ubuntu package 7.0.0 (Focal).
* Reportlab crashes with 8.1.2 with version prior to 3.5.54 [0].
The problem does not occur on Ubuntu Focal as both versions from
the Ubuntu packaging are compatible.
So the reportlab 3.5.59 is chosen as it's the Debian Bullseye version
and to avoid multiple lines for a few minor versions.
[0] https://hg.reportlab.com/hg-public/reportlab/rev/0cf382dab63b
X-original-commit: 794677fb6a3391379200eb2144a6ed372e89c17a
Part-of: odoo/odoo#78781
This commit intends to fix two strange bugs encountered while trying to
push a new component into the systray menu:
- MessagingMenuWidget and RtcActivityNoticeWidget were removing their
parent node via DOM manipulations when attached in the DOM. This caused
a crash when adding other items to the systray menu since the deleted
nodes were actually managed by OWL.
- The t-foreach directive in the navbar used indexes as the t-key, which
led mapping items subsequently added to wrong templates.
closesodoo/odoo#78784
X-original-commit: 5f0f80da4fc951954d253c9e45defd591605f556
Related: odoo/enterprise#21829
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Signed-off-by: Ooming <oomsveta@users.noreply.github.com>
Description of the issue/feature this PR addresses:
Currently, search engines index a SAAS-hosted website twice
(once for the actual domain, and once for the .odoo.com domain)
which is something that should be preventable.
Desired behavior after PR is merged:
If a domain name is configured, and the website is accessed
through a different domain than the configured one, the noindex
tag appears, preventing crawlers from indexing it..
task-2418904
closesodoo/odoo#78425
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Steps to reproduce:
- Install website_sale module
- Enable discount and advanced pricelist in settings
- Create product with sale price 0$ and set a website in
- eCommerce + publish the product
- Create pricelist PPP with Discount Policy as
- "Show public price & discount to the customer" and selectable in the website
- Go to the product and set an extra price of 10$ for the new pricelist
- Go to the product in the eshop and select the pricelist PPP
- Add the product to the shop cart
Issue:
The price displayed is 0$ instead of 10$.
Cause:
Since price_unit equal 0$, not possible to calculate the discount and
therefore using the 0$ value.
Solution:
Use price of pricelist in case 'discount_policy' is 'without_discount'
and price_unit equal 0$.
opw-2652192
Forward-Port-Of: #78570
Cherry pick of 32d34ffb04b3c6a8397c8ff7eb4e8a3dd9fb8a95
closesodoo/odoo#78778
X-original-commit: f34e441578bd2ba93dff1feffe6cafee633b9d32
Signed-off-by: bon-odoo <nboulif@users.noreply.github.com>
This commit ensure the pricelists are properly configured before launching a pos session.
Steps to reproduce:
- Have a V13 with point_of_sale
- Have minimum 2 companies A & B
- Select both companies in the company selector
- Go to Settings / General Settings
- Point of Sale
- Check Pricelists
- Go to Point of Sale
- Open a pos.config PC
- Set a Pricelist PL as Default Pricelist
- Go to Point of Sale / Products / Pricelists
- Open PL
- Set a company (must be different than PC)
- Go to Point of Sale
- Click "New session" on PC
--> Traceback
In V13, the traceback shows as "Traceback not available"
As from V14, the traceback is shown properly
A variant would be to start the session before changing
the pricelist company then click on "Resume" on PC
closesodoo/odoo#78767
X-original-commit: 86381c60214d210a42f736261a54e32042eedaba
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
Before Odoo saas-14.4, one should call `_get_http_domain()` on website to get
its domain. Indeed, that method was in charge of cleaning that domain, as it
was done with commit [1].
Since Odoo saas-14.4, that cleaning is automatically performed on domain before
saving it into database, thanks to commit [2].
Thus, we can now remove the `_get_http_domain()` and use directly the domain as
it is considered clean.
Note that migrated databases coming from version older than Odoo saas-14.4
could still have an incorrect domain (trailing slash, no scheme..).
This will be handled during migration with [3].
[1]: https://github.com/odoo/odoo/commit/3ad775aab717b395a5d11527aeb3596af66afa99
[2]: https://github.com/odoo/odoo/commit/042c95b0219bb0aa13e73385e092fa76ff1a1b0a
[3]: https://github.com/odoo/upgrade/pull/2951closesodoo/odoo#78766
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Currently, projects that are 'on hold' stage are represented in grey in
the kanban progress bar while the colored dot on their card is in blue.
In this commit, we change the color of the 'on hold' stage into 'info'
instead of 'muted'. After this projects that are 'on hold' are display
blue in the kanban progress bar as well.
Task-Id:2633273
closesodoo/odoo#78761
X-original-commit: 0886c10d5f276aca2539060ffaa047780a408354
Signed-off-by: LTU-Odoo <IT-Ideas@users.noreply.github.com>
The active field of stock_valuation_layer is related to product_id.active.
Adding auto_join = True avoids bloating search/read_group queries in
expression.parse().
closesodoo/odoo#69207
X-original-commit: 2526c640969f462c18ab8a3da7aa0a4e8ed871f8
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
thcl-odoo