When searching sale order lines from another model (e.g. task), the
order number was not being considered.
The technical reason for the above is the resulting domaing was like this:
[
'|',
('order_id.name', 'ilike', 'SO name'),
('name', 'ilike', 'SO name'),
# The below line is added by _name_search of base model
('name', 'ilike', 'SO name'),
])
So, even though the order number is added to the domain, an extra
condition was forcing the line description to be the only field to be
considered.
closesodoo/odoo#83911
X-original-commit: b5d45d6cae3579970ed55bc65d52c2de2377c381
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
To reproduce :
- Create a new documentation course from front-end
- Add a content there
- Edit the course in backend
=> any attempt to save the record or exiting it will trigger an error
as the specific option is set and no content has been manually set.
This has been introduced in 2597345
=> We restore the default 'latest created' that makes it work all the time.
Task-2731468
closesodoo/odoo#83910
X-original-commit: 1973944c0cdd0ea3f706280875acedfbd190333e
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Shipping insurance is a service which may reimburse senders whose parcels are
lost, stolen, and/or damaged in transit. Since most shipping connectors
provide it, it makes sense to put it in the base directory.
task-2701459
closesodoo/odoo#83896
Signed-off-by: Arnold Moyaux <arm@odoo.com>
When trying to set up a new bank account using the bank account wizard,
there is an issue with the check company on the linked_journal_id field.
The check will make sure that the company on that field is either false
or the same as the company on the record. But with a recent change in
68f4534aa5 the bank account company_id will be the one from the linked partner.
As the partners for companies have an empty company_id, this check does
not make a lot of sense anymore, as it would be wrong in most cases.
(We expect a journal with the currently selected company, but the bank
account will in most cases have an empty company_id)
closesodoo/odoo#83852
Signed-off-by: Josse Colpaert <jco@odoo.com>
In 9f7e6d2bb6ae0a6b0257edf26a5aa069cd00d78e , when start a workorder, we
always suggest the qty to produce to be the full qty to produce on MO.
If the previous WO produced less than the full qty to produce on MO,
user won't aware of that when start the WO. We revert it in this committ
Task-2678388
closesodoo/odoo#83389
Related: odoo/enterprise#23961
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Storno accounting is the term used to described the process of recording
a reverse action as a negative amount on the same site instead of a
positive amount on the opposite site of the credt/debit.
For instance, when one creates a credit note for an invoice, the values
of debit and credit will be kept in the same column with negative signs
instead of swapping columns like in non-Storno accounting.
It is a business practice commonly used in Eastern European countries.
Countries where Storno accounting is mandatory or considered as best
practice would be :
Czech Republic, Poland, Romania, Russia, Slovakia, Ukraine, Croatia,
Bosnia and Herzegovina, Serbia, Romania, China, Russia, Slovenia
It is available as an option in the settings and is automatically
activated for some countries which use this type of accounting.
otask-2064899
closesodoo/odoo#79581
Related: odoo/upgrade#3212
Signed-off-by: William André (wan) <wan@odoo.com>
Co-authored-by: william-andre <wan@odoo.com>
Co-authored-by: qdp-odoo <qdp@odoo.com>
Users are able to create accounts without restriction on the type of account to be created. With this commit we provide a context key to limit available account types and thus minimise errors.
part of task-2684816
closesodoo/odoo#80831
Related: odoo/enterprise#22198
Signed-off-by: William André (wan) <wan@odoo.com>
Current behavior :
When creating an invoice from a PoS the description attached to the product was not the same as the one in the SO
Steps to reproduce:
- create a SO from Sales
- create an invoice from the SO
- preview the invoice
- open a POS session
- fetch the same SO
- validate the order with an invoice
compare the 2 invoices, they are not the same
opw-2674896
closesodoo/odoo#83833
X-original-commit: dbd766f1b87f91eefce7b6e5946856961fd96c70
Signed-off-by: Masereel Pierre <pim@odoo.com>
Signed-off-by: Engels Robin (roen) <roen@odoo.com>
When comparing existing translations to new source value
html tag would invalidate existing translations.
The html tags used for styling (coloring, italic, ...) should not
invalidate the translation as the meaning of the text as not changed.
Changed the logic to compare translations based on textual content only.
+ add some tests.
task-2667950
closesodoo/odoo#83895
X-original-commit: 1fe4b0cc1981382cc3d944ec44276f0aee90945d
Signed-off-by: Antoine Guenet <age@odoo.com>
Signed-off-by: Geelen Sébastien (sge) <sge@odoo.com>
Co-authored-by: rco-odoo <rco@odoo.com>
Co-authored-by: xmo-odoo <xmo@odoo.com>
When selecting the text content of a link
the underline and italic commands were not working in Firefox.
We re-implement the Browser command to fix this.
task-2667950
X-original-commit: 52a5b2bb692ab6712d497492f4f2fbef3a9a7874
Part-of: odoo/odoo#83895
Steps to reproduce the bug:
- Go to Settings > Technical > Decimal Accuracy
- Change Unit of Measure to 4 digits
- Go to Inventory report or Valuation report
Bug:
The decimal accuracy in Valuation report for quantity or reserved quantity was in two digits instead of four digits
The decimal accuracy in Inventory report for qty_at_date was in two digits instead of four digits
PS: In stock move report or stock move line report, the decimal accuracy of quantity fields are in four digits
By default digits of Product Unit of Measure is 3, that's why some test had to be modified
opw:2410981
closesodoo/odoo#82989
X-original-commit: 0cf5c4e8241c46724defc0ea7e0d2c881ec2eeab
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Arnold Moyaux <arm@odoo.com>
The method constraint to validate the Check Number is slow
1. Analyzing the following query:
```sql
SELECT
payment.check_number,
move.journal_id
FROM
account_payment payment
JOIN account_move move ON move.id = payment.move_id
JOIN account_journal journal ON journal.id = move.journal_id,
account_payment other_payment
JOIN account_move other_move ON other_move.id = other_payment.move_id
WHERE
payment.check_number::integer = other_payment.check_number::integer
AND move.journal_id = other_move.journal_id
AND payment.id != other_payment.id
AND payment.id IN (1085159)
AND move.state = 'posted'
AND other_move.state = 'posted';
```
The output is:
Planning Time: 3.354 ms
Execution Time: 2514.660 ms
Discarding null values
```diff
AND other_move.state = 'posted';
+ AND payment.check_number IS NOT NULL
+ AND other_payment.check_number IS NOT NULL
```
The output is
Planning Time: 3.216 ms
Execution Time: 0.140 ms
2. The constraint is computed even if the payment is not a check (check_number is empty)
Returning early save useless extra computating
It is not needed to compare falsy values for duplicated for whole table
3. The validation to check is it not a number is not optimal
It is transforming the string -> integer -> string to check if the string is not a number
but it is enough using only string -> integer not needed to transform to string again
python3 -m timeit -u msec -s "check_numbers = [str(i) for i in range(1000000)]" "[str(int(i)) for i in check_numbers]"
> 1 loop, best of 5: 323 msec per loop
python3 -m timeit -u msec -s "check_numbers = [str(i) for i in range(1000000)]" "[int(i) for i in check_numbers]"
> 2 loops, best of 5: 135 msec per loop
It is better but not enough, using `str.isdigit` method is 5x faster than original approach
python3 -m timeit -u msec -s "check_numbers = [str(i) for i in range(1000000)]" "[i.isdecimal() for i in check_numbers]"
> 5 loops, best of 5: 64 msec per loop
closesodoo/odoo#83851
X-original-commit: 31e0ed8c957e8a6af7f6bd5d449b450967206eab
Signed-off-by: Olivier Colson <oco@odoo.com>
QWeb is the primary templating engine used by Odoo. It is an XML
templating engine and used mostly to generate XML, HTML fragments and
pages.
To create new XML template, please see :doc:`QWeb Templates documentation
<https://www.odoo.com/documentation/15.0/developer/reference/frontend/qweb.html>`
In **input** you have an XML template giving the corresponding input
etree. Each etree input nodes are used to generate a python function.
This fonction is called and will give the XML **output**.
The ``_compile`` method is responsible to generate the function from the
etree, that function is a python generator that yield one output line at a
time. This generator is consumed by ``_render``. The generated function is
orm cached.
In the graphic below you can see theresume of the call of the methods
performed in the IrQweb class.
Odoo
┗━► _render (returns MarkupSafe)
┗━► _compile (returns function) ◄━━━━━━━━━┓
┗━► _compile_node (returns code string array) ◄━━━━━━━┓ ┃
┃ (add technical directives: t-inner-content, t-tag) ┃ ┃
┣━► _directives_eval_order (defined directive order) ┃ ┃
┃ ┃ ┃
┣━► _compile_directives (recursive) ◄━━━━┓ ┃ ┃
┃ ┣━► _compile_directive ┃ ┃ ┃
┃ ┃ ┗━► t-if ━━► _compile_directive_if ━┫ ┃ ┃
┃ ┃ ┗━► t-foreach ━━► _compile_directive_foreach ━┫ ┃ ┃
┃ ┃ ┗━► t-* ━━► ... ━┛ ┃ ┃
┃ ┃ ┗━► t-inner-content ━━► _compile_directive_inner_content ◄━━━━┓ ━┛ ┃
┃ ┃ ┗━► t-tag ━━► _compile_directive_tag ━┫ ┃
┃ ┃ ┗━► t-call ━━► _compile_directive_call ━┫ ━━━┛
┃ ┃ ┗━► t-out ━━► _compile_directive_out ◄━┓ ━┫
┃ ┃ ┗━► t-field ━━► _compile_directive_field ━┛ ┃
┃ ┃ ┃
┗━━┻━► _compile_static_node ━┛
Part-of: odoo/odoo#81024
Before this commit, when a project has no SOL set and has an employee
mapping, then the domain builds in the search method of `pricing_type`
is the following:
`[
('sale_line_id', '!=', False),
('sale_line_employee_ids', '!=', False),
('allow_billable', '=', True),
]`
The problem is we don't need to have a SOL set into the project to
define the pricing_type as employee rate. We should find the project
with at least an employee mapping set in that project.
Moreover, this commit fixes the domain built in the
`_search_pricing_type` method.
Some unit tests are added to check the domain built in the
`_search_pricing_type` method.
The issue has been found during the development of task-2680425
closesodoo/odoo#83874
X-original-commit: 490747c85f2d2e390a44e8f375e24dc3a8425409
Related: odoo/enterprise#23951
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
Before this commit, most acquirers needed to run several successive
searches for the transaction whose reference was received by a
controller in notification data. This is because the security checks
run on the notification data require access to the acquirer through the
transaction record which was immediately discarded.
Starting with this commit, all `*_feedback_data` method are no longer
decorated with `api.model` and can use the transaction record they're
called on if provided. They are also renamed to `*_notification_data`.
task-2737144
closesodoo/odoo#83850
Related: odoo/enterprise#23938
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
To ease comparisons for query counters let us try to keep the same test flow
through v15+. We therefore now also compute recipient groups for portal users
for some test models, like before odoo/odoo@faeb5e7fee .
Part-of: odoo/odoo#83832
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>
Luis González