If a product is a kit and has a storable component, if this component is
already ordered (with sufficient quantity), when running the scheduler,
the ordered quantity of this component will still be increased.
To reproduce the error:
1. Create two products P_kit and P_compo
- Both are storable products
- P_compo must have at least one vendor
2. Create a BoM for P_kit:
- Must be a kit
- Add P_compo to components
3. Set a reordering rule for P_kit
4. Inventory > Operations > Run Scheduler
5. Go to Purchase and find the generated RfQ
- The ordered quantity is correct
6. Repeat 4-5
Error: This time, the ordered quantity is incorrect. While you don't
have any P_kit on hand, each time the scheduler is run, the ordered
quantity will increase.
A similar issue has already been fixed: #63891. The original commit
targets the version 13, but the fix has also been applied to v14 (#64277).
However, here the case is slightly different: the user run the scheduler
twice while the first RfQ is not yet confirmed and received. In such a
case, the scheduler must also check the "quantity in progress". In version
14, it seems nothing computes this quantity for the kits.
OPW-2421841
closesodoo/odoo#65100
X-original-commit: f53ab55000c32fd67c567f01a9533298936daaac
Signed-off-by: Adrien Widart <adwid@users.noreply.github.com>
For now, when you are selling products in the point of sales, the stock
is affected once the order is validated or the session closed. But in
some case, you don't have the product in your store, and you have to
plan a delivery for the order.
To be able to plan a delivery, you can now choose the warehouse in POS
Config and the routes of your warehouse will be applied. You can also
set a specific rule on your POS Config if you've enabled the
multi-step-routes in the inventory module
closesodoo/odoo#58506
Task-id: 2082104
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
Adjustment of a previous commit b1dff85a85
It is possible for the argument to be something else than `undefined` or an array. We're adding a check to prevent an error to occur in that case.
closesodoo/odoo#65098
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
The regex was updated in JS with [1] but its python counterpart was
forgotten during forward-port.
[1]: https://github.com/odoo/odoo/pull/46898closesodoo/odoo#65087
X-original-commit: 8d0b82683b95615267ff3acf84ebdd20456c595a
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Steps to reproduce the bug:
- Create a promotion program PP
- Set 50 in minimal amount
- Set promo_applicability = on_next_order
- Set reward_type = discount
- Set discount_type = discount
- Create a new sale order SO with a product with price 100€
- Cancel the SO
Bug:
A coupon C had been created
PS: When reset to draft and confirm SO, C became valid
Closes#64361
opw:2431740
closesodoo/odoo#65067
X-original-commit: c2ce00173c612d38dd8dc6b1f15edf2261f2acc6
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Steps to reproduce the bug:
- Let's consider two companies C1, C2 and a website W1 in C1
- Set C2 on the payment term Immediate payment
- Go to the shop
- Add a product in the cart
Bug:
A traceback was raised because Immediate was not in company C1
opw:2431705
closesodoo/odoo#65066
X-original-commit: 48ec6f2e4f91e4d1317b246b7017f78746161450
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
commit 31e1322b40 is allowing the
customer to increase is decimal accuracy for currency without
consequences but triggering issue upon lowering it if entries
already exist.
+ Remove the redirection to the support.
Let's ensure that the behavior is consistent and the users are
warned on first modification. To do so, adding an alert msg
in addition of the blocking message in case of lowering the decimal
accuracy after already creating accounting entries.
opw-2428857
closesodoo/odoo#64757
X-original-commit: 66533ebd88ed89c3baae6fdb1d0a28a458fa0cb9
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Issue
- Install "Manufacturing" module
- Go to settings and activate "Master Production Schedule"
- Install Dutch language
- Switch user language to Dutch
- Go to Manufacturing -> Planning -> Planning by Production
- Hover work order
Dates are not displayed with user locale.
Cause
Date are formated to "YYYY-MM-DD HH:mm:ss",
regardless the locale.
Solution
Format date instead with locale format letters (L, LL, LTS, ...)
Doc : https://momentjs.com/docs/#/parsing/string-format/
Go to "Locale aware formats" section
opw-2430570
closesodoo/odoo#65092
X-original-commit: 08978c6d2d14a94e6ee2fea0dedc805a56378de0
Related: odoo/enterprise#15970
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: bon-odoo <nboulif@users.noreply.github.com>
with this commit we fixes various tour steps, remove steps from crm and sale
tour and improve step selector in project tour.
task-2444272
closesodoo/odoo#65073
X-original-commit: f6c05693f857acfb0f74bb76c4bd72f83d9fb335
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit saving a custom snippet inside an email template
produced a "cross origin" error related to the combination of the save &
reload mechanism with the fact that the email template editor is inside
an iframe.
After this commit saving a custom snippet inside an email template is
not available anymore.
Given that fixing the reload problem would be only temporary -while
quite complex-, it has been decided to disable the feature until the
editor allows for cleaning snippets without saving them.
Decided during task-2374802
closesodoo/odoo#65052
X-original-commit: 86333160f92c16bc61f36b413caed325f8ac59a0
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Co-authored-by: qsm-odoo <qsm@odoo.com>
Start odoo in threading mode with bus installed. Login in the browser
using any internal user. Make sure the browser call the
/longpolling/poll uri. While the browser is waiting for a response, stop
the server. The server takes up to 50 seconds to stop.
When started in threading mode, a request to /longpolling/poll is served
by a casual http thread. It searches for messages enqueued in the bus
and returns them. If there are no message for the user in the queue yet,
it creates a `threading.Event`, attach it to the user in a shared
dictionnary and `wait()` on it with a timeout of 50 seconds (hardcoded
value). When the bus thread (the one responsible to listen on the
database) receives new messages, it `set()` the events which resume any
http thread that was waiting.
Because when we stop the server, there is no way to server new requests,
there are no way new messages arrive in the bus. All the threads that
were waiting for a new message will just wait until the event timeouts
which slow down the shutdown of the server.
Now we actively `set()` all events in order to resume all those workers
when we stop the server.
The `ImDispatch.poll` signature has been changed too so it is possible
to change (via code) the hardcoded default. The function was using the
object referenced by `TIMEOUT` at the time the function was defined,
using `timeout None` then `if None: timeout=TIMEOUT` ensures we lookup
the variable.
closesodoo/odoo#64530
Signed-off-by: Julien Castiaux <Julien00859@users.noreply.github.com>
Before this commit, the countdown snippet was layouted vertically on
mobile devices.
After this commit, the countdown snippet is layouted vertically,
just like on desktop.
task-2349095
closesodoo/odoo#59756
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Co-authored-by: Siddarth Gajjar <sga@odoo.com>
Before this commit the user had to type in the exact same formatting to find contacts.
After this commit the user will be able to get better search results and does not have to type the same formatting.
To avoid code duplication, the existing _search_mobile_phone method has been moved to the mail_thread_phone class, so that it could be used by both the crm and res_partner models.
Task-2435233
closesodoo/odoo#64490
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
The uom must be displayed to the customer in any case.
Otherwise a customer couldn't know the modalities of a contract
(ex: a contract of one year or one day)
Fine tuning of 342dd5f
opw:2411108
closesodoo/odoo#65048
X-original-commit: 29fb2f93d218109edd1db1e94555bf4b58d25158
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
The .po format is wildly used in Odoo and is the format used for storage and
interaction with Transifex
closesodoo/odoo#65039
Signed-off-by: Ivan Yelizariev // IEL <yelizariev@users.noreply.github.com>
Modifying product attributes involves discarding product variants via
the method _unlink_or_archive(), which tries to delete variants, and
archive the ones for which the deletion fails. This process is very
slow when most product variants must be archived. Instead, we filter
out the variants that must be archived anyway (like the ones used in
sales or stock), in order to avoid the variants that cannot be deleted.
On a product with ~200 variants, the time goes from more than 15 minutes
(the request times out) to around 5 seconds!
opw-2440417
closesodoo/odoo#65027
X-original-commit: 63b2f85079404eafac918a74c95e27051539c133
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Also did below improvements/fixes,
- Added missing .pot file for internationalization and re-exported
Swedish translation file and adapted the translation.
- Fixed partner view by inherting it from account instead of base.
- Constrain method should not 'return' ValidationError, it should
'raise', it is now fixed.
closes odoo/odoo#53298
Task: 2279356
Closes: #53298
Related: odoo/upgrade#1371
Signed-off-by: William André (wan) <wan@odoo.com>
Issue
- Install calendar
- Go to calendar and set 'week' view
- Go to first week of the year
- Add a 'Full Day' event
- Add an event of 'few hours'
- Click on filters -> Date -> Q1
Only 'Full Day' events remains displayed.
Cause
'start_date' is used to in the 'Date' filter
and this field is set only on 'Full Day' events.
Solution
Use 'start' field instead since always set.
opw-2439460
closesodoo/odoo#65022
X-original-commit: 5f13ac8cf52c2042fe0b4697cbf41aa7f8714427
Signed-off-by: bon-odoo <nboulif@users.noreply.github.com>
The affixed header was not reappearing if page content was removed and
the page thus indirectly scrolled.
task-2446020
closesodoo/odoo#64999
X-original-commit: 4da6df09a4df195ad7c0caa7de7fbc7389339958
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
The uom must be displayed to the customer in any case.
Otherwise portal user couldn't sign their online quote if
they couldn't read the uom (ex: a contract of one year or one day)
opw:2411108
closesodoo/odoo#64993
X-original-commit: 342dd5ffb8281cb5c37fea4fb96db2b570c30122
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Before this commit, routes were prevented to be accessed if the route model was
not accessible from the current website, eg you couldn't access blog1 which is
set to website2 from website 1.
That would raise a 404 even from admin/editor.
This commit introduce that behavior at a lowel level in a generic way, instead
of having to write it on every route.
Note that routes without a model converter won't benefit from this.
Closes#63499closesodoo/odoo#64313
Related: odoo/enterprise#15688
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
The mobile app's authentication bases its feedback to the user on the
error message returned by the server.
Sadly, in case of multi-databases, no error message are properly
returned when the user provides wrong credentials (presenting only an
empty Snackbar).
This difference of behaviour was introduced in the commit
odoo/odoo@07d5ea3 which goals was to give more power for JsonRequest's
error handling customization. To do so, the catching of the exception
(if one happens) was delegated to the caller instead of the JsonRequest
itself.
This change indirectly introduced a difference about the treatment of an
exception between mono and multi-database :
* mono-database was already catching the exception and handling it
properly (see in
https://github.com/odoo/odoo/blob/f05f8ef647a4eaba49d8a20eb8068f1c7a702297/odoo/addons/base/models/ir_http.py#L235-L241).
* multi-databases didn't catch it.
This commit restores the parity between both use cases by applying the
same behaviour (as described in the commit odoo/odoo@07d5ea3):
```python
ir_http.dispatch():
try:
request.dispatch()
catch Exception as e:
ir_http._handle_exception(e)
ir_http.handle_exception(e)
request._handle_exception(e)
```
Steps to reproduce:
1. Open the mobile app;
2. Try to register an account with a wrong password with multiple
databases;
3. The snackbar is empty and no error is shown => bug;
Task ID: 2287176
closesodoo/odoo#64965
X-original-commit: f54c97f6214c235bac931184c6e533a7fa72fbe2
Signed-off-by: Olivier Dony (odo) <odo@openerp.com>
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
When using the Calender synced with Google, if the user tries to delete
an event, an error message is displayed: he has to archive it instead.
To reproduce the error:
1. Sync Odoo Calendar with Gogle Calendar
2. Add an event
3. Click on it > Delete
Error: UserError message: "You cannot delete a record synchronized with
Google Calendar, archive it instead"
To make the flow simpler and faster, when clicking on "Delete", the
server will archive the event. When archiving an event, the server
deletes the corresponding event on Google Calendar. As a result, the
next time the user loads his Odoo Calendar, the sync Google->Odoo will
delete the archived event.
OPW-2440339
closesodoo/odoo#64957
X-original-commit: 109ffab4a5d3e77d330d7fa4cc5fd39017bdf561
Signed-off-by: Adrien Widart <adwid@users.noreply.github.com>
Issue
- Install "Ecommerce" app
- Go to 'Shop' page and edit it
- Add a "Dynamic Products" block
- Click on it to edit it :
- Select any template
- Select `Desks` as product category
- Save
- Go to "Website -> Configuration -> eCommerce Categories"
- Delete the "Desks" category
- Go back to Shop page
Error : "Record does not exist or has been deleted".
Cause
The search domain is looking for child categories of dataset.productCategoryId
(who does not exist anymore in the above case).
`child_of` do a browse() to fetch the records, and therefore generate
an error if category not found.
Solution
Log warning message if unexptected domain and return empty records set instead.
This commit also reverts commit 0de069b8ca9fb005ba5b076984f5677de25889ee that generated the issue.
opw-2440917
closesodoo/odoo#64947
X-original-commit: e452d30f739db39a088248a3109c8c49cff9d49f
Signed-off-by: LTU-Odoo <IT-Ideas@users.noreply.github.com>
Signed-off-by: bon-odoo <nboulif@users.noreply.github.com>
Before this commit the custom snippets were saved across websites
because the RPC mechanism used by the save & reload does not include the
context by default.
After this commit the custom snippets are saved for the specific website
as initially intended.
No migration is needed: already created snippets that have been created
across all sites will have the correct lifecycle because of the
copy-on-unlink system: trying to delete one will make it specific on
other websites.
Related to task-2374802
closesodoo/odoo#64963
X-original-commit: 42e0f9112404541d1c11ba35e7a3d9bcb939f73b
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
* = hr_holidays, im_livechat, website_livechat
A huge amount of components where rendered for no reason, notably when typing a
new message (at every key press), which significantly slowed down the interface.
There were 2 causes to this number of renders:
- OWL rendering all children automatically, even if their props didn't change,
unless `shouldUpdate` is overridden, which is now done.
- `useStore` selectors being way too generous in what they observed
task-2399731
closesodoo/odoo#64958
X-original-commit: a0472425251d429a0828eff1675c84b3f24527d8
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
In 13.0, some account.move.line fields (amount_currency, debit, credit
and account_id) couldn't have a value when the line is of type 'note'.
Skiping them during line copy for notes is not an issue.
During 12.0->13.0 migration, we were facing issues with "grouped similar
invoice lines in a single move line", because this feature is not
available anymore in 13.0. To avoid any "loss of data" during migration,
we used lines of type note to create "missing" invoice lines in move
lines without altering accounting in any way. As a consequence, we have
13.0 databases with lines of type note having values for fields who
couldn't have ones.
closesodoo/odoo#64962
X-original-commit: 677edafeaf8d691764178f5e7e9639017b0249a8
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
- On account_edi_document, lock the documents successively instead of all at once.
- Lock account_move that should be cancelled. Before, cancelling the invoice after cancelling it on the web-service could fail.
- Lock ir_attachment that might be unlinked. Before, attachments that weren't attached to any model could become unreachable but still present in the database when an invoice was cancelled or a new attachment was produced.
closesodoo/odoo#64946
X-original-commit: 8d0c25f359f92533eb25f2990d6e2aceef33b77a
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
Signed-off-by: bfr-o <bfr-o@users.noreply.github.com>
This mobile specific code does not work correctly because
`if channel in channel_previews` always returns false due to the dict having
channel ids as key and not channels.
A fix could be to look for id instead of record in the dict, but at the same
time this is dead code, there is no need for mobile specific channel info.
task-2412157
closesodoo/odoo#64945
X-original-commit: a27907e27fb99a523c7b2d58544c36073640511c
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Before this commit, on pivot view when a user adds some groupBy the
dropdown menu remains always open.
This commit restore the same behaviour like on desktop.
Steps to reproduce:
* Open an app with a Pivot view
* Select the Pivot view
* Add one "groupBy"
* The dropdown remains open => BUG
Task ID: 2439742
closesodoo/odoo#64944
X-original-commit: 298f3900a8f4c80fe06585634ce97c7725cf7f7d
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
Signed-off-by: rfr-odoo <rfr-odoo@users.noreply.github.com>
Add two indexes (on `product_id` and `product_tmpl_id`)
on the `mrp.bom` model to speed up `_bom_find`
which is highly used and it uses always the `product_tmpl_id` and
sometime the `product_id` in the search domain.
Performance Gain:
With a DB with 2K BoM, a `_bom_find` search (`product_id` and
`product_tmpl_id` are in domain): The SQL execution time
is +- 5 times faster.
task-2390516
closesodoo/odoo#64934
X-original-commit: 64861aed03b616820d717bc08e7c38c56145e0f2
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Use UNION ALL instead of UNION to let PostgreSQL
filter out rows before sorting and avoid Unique check.
Note that it shouldn't change the result because each 3 SELECT
doesn't have domain intersection.
Improve performance the `_get_orderpoint_action` and the Forecasted
Inventory.
Performance Gain:
With a large Database (5K products, 120K stock move, 20K quants, etc):
To open the Forecasted Inventory:
Before: 10.06 sec +- 0.02
After: 3.98 sec +- 0.07
task-2390516
X-original-commit: 0a89bc231aaadee959deb6cda4aa09318b08f591
Avoid to filter in a loop and use a read_group instead to group by
product-warehouse outside.
Also remove costly useless code.
Performance gain
----------------
On a large database (120K stock move, 5k product) where
+- 700 manual orderpoints will be create during the open of the
replenishement report:
Before:
16.14 +- 0.16 sec of python. (SQL time is +- 14 sec)
After:
1.33 +- 0.91 sec of python. (SQL time ==)
task-2390516
X-original-commit: 569b45d5cb139825690a90189b7a360f3fa89815
`o.location_id.id == g['location_id']` =>
`Comparing apples and oranges: stock.location(243,) == (219 ...`
replace by the correct code and avoid warning.
task-2390516
X-original-commit: 461a3e737c4ffe048b738dd09f83571602324257
Replace union of RecordSet by union of OrderedSet to reduce the
complexity and improve the scalability. It can be a bottleneck to
huge number of move to assign.
task-2390516
X-original-commit: e89105144a34ee73981db383ac0625dcaf63b27b
Replace union of RecordSet by union of OrderedSet to reduce the
complexity and improve the scalability. It can be a bottleneck to
huge number of move to validate.
task-2390516
X-original-commit: d9510aee26578e1b345a7700f7c94032d5745bf4
This commit fixes a nondeterministic issue during the rainbowman tour.
We make sure that the record is properly created and the kanban reloaded before
moving on to the next step, ensuring that the tour completes without race
conditions.
Task-2426257
closesodoo/odoo#64921
X-original-commit: f332541bc84d6110c90d4c5e736892f185fff3df
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: awa-odoo <awa-odoo@users.noreply.github.com>
Xavier Dubuc