Usecase to reproduce:
- Create a planned receipt of 10 product A
- Set quantity done to 10
- Put in Pack
Actual result:
UerError "There is not move line to pack"
Expected result:
Pack them
It happens because since we are in a receipt without suggestion (by
default) then the fields `move_line_nosuggest_ids` is used.
But `_set_quantity_done` on `stock.move` will first try to fill
move line with reservation before creating new ones.
So the move_line_nosuggest_ids will not contain the quantity done
on planned quantity
closesodoo/odoo#83430
X-original-commit: 3c7453a61372d6ecdeae099d49cbc79844c144ae
Related: odoo/enterprise#23767
Signed-off-by: Tiffany Chang <tic@odoo.com>
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Usecase:
- Install mrp with demo data
- Log in chicago company
- Go to manufacturing list view
-> Access error is raise due to multicompany rule
It happens because the state.res_ids contains all the mrp.production
even in SF company. So it try to read records in the wrong company
and raise the error.
Instead of doing a read, we change that and do a search_read like in the
classic process using the state.domain. So it filter the wrong records
before reading them
X-original-commit: 2077ee3b9312fc511d8fd5d328b5c4e329d9b784
Part-of: odoo/odoo#83430
Usecase to reproduce:
- Create product 1 with supplier `Vendor` and a delay of 3 days
- Create product 2 with supplier `Vendor` and a delay of 4 days
- Create two procurements with a need for stock at 01-01-2022 (warehouse
1 step)
- Run procurement for product 1
- Run procurement for product 2
The PO contains the two product but the order date is for 3 days before
and not 4. Also the line for product 2 is planned for the 02-01-2022
It happens because the delivery date is computed base on the purchase
order date and the supplier but the procurement is totaly ignore
X-original-commit: aec7fcdb693729f432ae2341c00ef317b65fbcbc
Part-of: odoo/odoo#83430
Some projects start to have real planning and in multiple
steps the `stock.move` that are not linked to a RFQ or a MO
are always merge together with the minimal date are result.
It's not flexible since you don't know the correct quantity
for a specific day. And once this quantity is received, you
don't know the next date.
We just add a system parameter for now and it will be modify
in master to be able to do this configuration for everyone.
X-original-commit: b9fffac7a8b6ccef2d957b5564ce615b2e1b0b36
Part-of: odoo/odoo#83430
While the batch is currently visible on the tree view, there was no
current link to a picking's batch while in the form view.
Task-2670580
closesodoo/odoo#81533
Related: odoo/upgrade#3205
Related: odoo/enterprise#23484
Signed-off-by: Arnold Moyaux <arm@odoo.com>
When adding a selection of pickings from the list, select the 'create a
new batch' over 'add to existing batch' as it better reflects user's
usual flow.
Task-2670580
Part-of: odoo/odoo#81533
Improves the auto-batcher, allowing it to also group by :
- Carrier
While adding a new restriction on the batch size as well :
- Max weight per batch
Task-2670580
Part-of: odoo/odoo#81533
Allow confirmed pickings to be automatically put into batches that match the
group criterias defined in their picking_type.
The pickings can be grouped by :
- Contact
- Destination Country
- Source location
- Destination location
To avoid having batches too big then, some restrictions can be put over
the auto-batcher to restrict the size of a batch :
- Max moves per batch
- Max pickings per batch
Task-2670580
Part-of: odoo/odoo#81533
Since [1], the test suite waits for 5s to start running. It's
really annoying when you run the suite in your browser, to debug
a single test or a sub suite. Waiting for 5s to determine whether
all modules can be loaded or not is not necessary anymore since
all assets coming from the same bundle are loaded in a single
file, even in debug=assets. This is true under the assumption that
there's no js module in assets_common requiring a module in another
assets bundle, which seems reasonnable.
[1] 468eb84fb4closesodoo/odoo#83805
Signed-off-by: Géry Debongnie <ged@odoo.com>
- Steps :
Sales > New Quotation > Order Lines > in a new product line :
Write a price
Write a name, Create and Edit
In the form, change the price of it and Save.
- Issues :
When first getting in the form, the price is not correctly computed from
the sol.
When saving the form, the price is not saved.
- Cause :
`lst_price` is the product's price.
`list_price` is the template's price.
The sale/quotation view puts `default_lst_price` in the context with the
unit price of the sol.
Yet lst_price is not in the form, so its value remains zero as this context key is not taken into account.
However, list_price is in the form. After this has been changed
manually, when the form is saved, it takes the value of lst_price = zero.
- Fix :
Add an invisible field lst_price in the product form.
This way, the context key is taken into account, so lst_price is
changed, and list_price accordingly.
opw-2731620
closesodoo/odoo#83793
X-original-commit: d3ec94f1c79ecb76acb8de027bf47b0f0b7a3b0f
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Signed-off-by: Onockx Audric (auon) <auon@odoo.com>
Some html field are not in their ideal style.
As the style for html fields is now dependent of
where you are in the xml view ( in group or not),
we have to adapt some views and flags some fields
to ensure they have the correct look.
This change is only be a visual enhancement
and should not prevent the function of said html fields
even if the views are not updated.
task-2637488
# Conflicts:
# addons/mail/wizard/mail_compose_message_views.xml
# addons/website_slides/views/slide_channel_views.xml
# Conflicts:
# addons/sale/views/sale_views.xml
closesodoo/odoo#83792
Related: odoo/enterprise#23911
Signed-off-by: Antoine Guenet <age@odoo.com>
Signed-off-by: Geelen Sébastien (sge) <sge@odoo.com>
Allow wysiwyg field html to blend better in odoo view,
Remove the default resizer and make the field html's size
automatically fit its content
task-2637488
# Conflicts:
# addons/project/static/src/js/project_form.js
Part-of: odoo/odoo#83792
This commit brings the ability to use some feature detection
mechanism used in Odoo. The jquery.touchSwipe library
implementation requires the browser to get ontouch* events from
the window to be available to assert that the browser has touch.
The switch will make the mechanism to work as expected, and
allow tests to use touch events while being correctly executed
because the library expects such events.
closesodoo/odoo#83588
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
in version 14, if you have anglo-saxon accounting and are posting inventory at the end of the session, and create a PoS order without invoicing it, then leave the session without closing and validating,
and open said order and invoice it outside the session, picking for said order will not be created. So, once the session is closed and validated, there will be an invoiced order without any picking in it.
After this commit Odoo will check if order that is being invoiced already has picking order, and if not, will create one for it.
OPW-2725930
closesodoo/odoo#83787
X-original-commit: 894dfa892c92d55ce9897193b4016a5e1f40858d
Signed-off-by: Masereel Pierre <pim@odoo.com>
Before this commit, it was impossible to make a payment if the
transaction reference exclusively contained digits. This is because the
reference is extracted from the data-* attribute of the <form/> element
of the payment form and wrongly cast into an integer by jQuery before
being passed to the server. Indeed, as of jQuery 1.4.3, HTML5's
data-* attributes are automatically pulled into a jQuery's data object.
To reproduce the issue, remove the prefix from the sequence of the sales
orders and attempt to pay a quotation from a payment link.
This commit forces the reference to be cast into a string as it is the
variable type that the server expects, and it crashes if the reference
is an integer.
opw-2732448
closesodoo/odoo#83753
X-original-commit: 57d9997fa59c82e03c46b149daece5ce32395c5c
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
We are currently lacking an index with (author, failure) due to the information
being spread out in two different tables which are both rather big (there are a
lot of non-failure messages for the current user, as well as a lot of failure
messages for other users), so the fetch of failures for the current user can
become extremely slow (> 20s).
With this new index, the query takes less than 1ms.
task-2742946
closesodoo/odoo#83451
Related: odoo/upgrade#3204
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Following recent conversion of onchanges to computes in the sale scope,
it was observed that updating one line triggered price recomputation in other
lines (which isn't expected).
After investigation, it seems that the `product_packaging_id` field is considered
modified and sent on SO save for all the lines, which triggers the `product_uom_qty`
record computation, then the whole price computation is triggered, since it depends
on that quantity field.
This commit aims to fix this case by only considering a m2o field as modified
if its value was effectively changed.
closesodoo/odoo#83252
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Split a manufacturing order in several parts
using the back order mechanism
Merge several manufacturing orders related to the same product/bom
by cancelling all of them and creating a new one
closesodoo/odoo#82427
Task: 2662566
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Add the possibility to force the two-factor authentication for all users,
using a two-factor authentication by email
when the 2FA using an Authenticator app is not configured for the user.
Two possibilities:
- Force the 2FA only for employee users using the system parameter `auth_totp.policy=employee_required`
- Force the 2FA for all users, employees and portals, using the system parameter `auth_totp.policy=all_required`
closesodoo/odoo#83750
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
Steps to reproduce:
- Create an invoice and confirm it
- In Accounting Dashboard, on the Customer Invoices card,
click on 'Unpaid Invoices'
- Select the invoice with the checkbox
- Click on button 'Register Payment'
Issue:
- The journal_id is not set by default
Before this commit, the default fields inherited 'journal_id',
if it's not the good one, we delete it in order to compute it..
opw-2729754
closesodoo/odoo#83770
X-original-commit: 9e2f96598f3d62b501e894eab7151af8390937e1
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Guillaume Vanleynseele <guva@odoo.com>
PURPOSE
Before this commit it's impossible to unlink a sale order line containing
a booth product (the ondelete parameter is unset thus default to restrict)
After this commit this bug is fixed.
Further explanation on the task implying a bug on the database setting
the on delete to cascade despite the default value...
LINKS
Task-2749521
PR : odoo/odoo#83685closesodoo/odoo#83767
X-original-commit: e8d96fb1cfd5016f12dc43b988a8a0450bf36a04
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Purpose
=======
A field `use_google_gmail_service` has been used in stable to define
a mail server which use Gmail authentication.
But now that the fields `smtp_authentication` exists, we want to use it
to simplify the mail server form view. For the incoming mail server,
the field `server_type` will be used for the same purpose.
Add a new field to have the option to install `google_gmail` in the
main settings page.
Task-2170676
closesodoo/odoo#83413
Related: odoo/upgrade#3199
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Steps to follow
- Select only one company in the company selector but not the default one
from the current user;
- Go the the CRM app;
- Create a lead;
-> A multi company error appears !
Solution
- The default team is now restricted to the companies in the context
- When computing a lead's company_id when the team has no company, keep only
the ones within the allowed_company_ids;
opw-2713757
closesodoo/odoo#83764
X-original-commit: 58b9b3e839c7725fdcd66376564ce6554a4b82ac
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Purpose is to add some tests involving unsync of env.companies and current
user's company. Tests are added trying to mimic notably assignment cron
using sudo().
Next commit will fix some side issues.
opw-2713757
X-original-commit: 70b9f3aaa86acc6d32bee21fbd6114541115d310
Part-of: odoo/odoo#83764
The `_create` don't batch the SQL request to insert of data which it
isn't efficient we there is a several record to create.
Batch the SQL insertion and measure performance
depending of batch size to avoid any regression (see result in the
PR: https://github.com/odoo/odoo/pull/80961).
task-2299314
closesodoo/odoo#80961
Signed-off-by: Raphael Collet <rco@odoo.com>
Co-authored-by: rco-odoo <rco@odoo.com>
The `check` decorator in `sql_db.py` was on a lot of `Cursor` methods.
It checks if the cursor is close before be using a the method.
Remove it because:
- It is completly redundant because `psycopg2` do already the job
to check the cursor before usage.
- It complicated the call stack and lead to a small overhead of
highly use methods (can be more than 1% of the execute call)
- Also the nature of
the Error isn't correct: raise `OperationalError`
(https://www.psycopg.org/docs/module.html#psycopg2.OperationalError)
instead of `InterfaceError`
(https://www.psycopg.org/docs/module.html#psycopg2.InterfaceError).
Part-of: odoo/odoo#80961
Previously for `appointment`, now for `appointment_hr`, the computation of
users' availability for appointment slots can be dependent on that person's
work schedule if:
* The user is linked to an employee
* The user's employee has working hours defined (resource calendar)
This commit provides working hours to all employees and a user to some, within
a multi-company setup.
Task-2728093
See odoo/enterprise#22642closesodoo/odoo#80688
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Current behavior:
After creating a group chat in the discuss app you were not able to close it.
Steps to reproduce:
-Create a group chat with more than one user in the discuss app
- Try to leave it
- You get an access error
opw-2736464
closesodoo/odoo#83717
X-original-commit: cc1c132ee092368e77108f327ecdc5a6d2c490a6
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Engels Robin (roen) <roen@odoo.com>
Activities and mailing trace models are linked to records through a model and
a many2one reference field. The latter one is required but is implemented like
an integer field, meaning writing 0 is actually a valid value for 'required'.
In this commit we add a constraint to ensure we never update activities with
a void res_id value. Same for mailing traces.
Source: internal feedback about activities with 0 as res_id
Task-2694133
closesodoo/odoo#81292
Related: odoo/upgrade#3106
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Oversight of odoo/odoo@cd885ad2cd . On transient record (having newID) this
line leads to creating activities with res_id being 0.
Part-of: odoo/odoo#81292
Activities and mailing trace are linked to documents through a model and
a many2one reference field. The latter one is required but is implemented like
an integer field, meaning writing 0 is actually a valid value for 'required'.
In this commit we add a constraint to ensure we never update activities with
a void res_id value. Same for mailing traces. This allows to remove the
required attribute on fields to avoid having redundant sql constraints.
Source: internal feedback about activities with 0 as res_id
Task-2694133
Part-of: odoo/odoo#81292
Part of the overall v16 SCSS optimization/restyle, task-2704984.
task-2731819
closesodoo/odoo#83108
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Add new utility classes to handle basic opacity behaviors.
Once migrate to BTS5 these classes should be generated using the
upcoming utility classes API.
Part of the overall v16 SCSS optimization/restyle, task-2704984.
task-2731819
Part-of: odoo/odoo#83108
With a recent commit[1], we now gather the chatter related data with a
single controller ('/mail/thread/data') which was a bit scattered
previously. With this controller, instead of searching in dedicated
model, we now simply use the main document/record itself and it's
fields whenever possible. For example, previously for the followers,
we used to search data from 'mail.followers' model, but now we simply
use `message_follower_ids` field of the record itself.
The problem with this approach is, if the record is archived, we won't
be able to fetch the related data. That leads to empty follower list/
activities and a trackback while getting suggested recipients.
This commit fixes the issue by loading the record even if it's
archived, and thus fetching the data required by chatter.
commit[1] - https://github.com/odoo/odoo/commit/e0913197ac84b25b40e7599a6432362141d104c9
TaskID-2748030
closesodoo/odoo#83731
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
When archiving a Tax, you do not want that action to
invalidate Sales Orders and Invoices confirmed in the past
and that were using it.
The purpose of Archiving it is that it would not appear
or be proposed to new items created.
Until now, we had an inconsistency between Sales Orders and Invoices
when a Tax was archived.
The tax "disappeared" from old SOs,
but the amounts remained unchanged, which created an inconsitency.
The domain in the field definition no longer works
because a custom domain in the view is shadowing the current domain.
task-2745094
closesodoo/odoo#83712
X-original-commit: 09f6d682669e4e9d898f89706fece3fa9ce59da3
Signed-off-by: Laurent Smet <las@odoo.com>
When creating automatic entries for multiple moves on different dates with the automatic entry wizard, the wizard would reconcile all the lines on the accrual account of the destination move with the lines on the accrual account of each accrual move. As this would imply reconciling the same lines multiple times, it triggers a reconciliation error.
What must be done is, for each accrual move, reconcile it’s lines with only the related lines on the destination move.
closesodoo/odoo#83732
Task: 2717578
X-original-commit: 502003ac548d6620374dfbab4fb7be6dee3c1bf5
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: Florian Gilbert <flg@odoo.com>
Signed-off-by: de Wouters de Bouchout Jean-Benoît (jbw) <jbw@odoo.com>
Sometimes _compute_percentage would return a percentage slightly over 100 due to a rounding error. This would then trigger the constraint asserting that percentage must be >= 0 and <= 100.
Task: 2717578
X-original-commit: 813d52ed7daff408819d8838c8c36fcee825905f
Part-of: odoo/odoo#83732
Thibault Delavallée