When registering lot or serial number for a component in a workorder,
the manufacturer can create it on on the fly. We would like to give this
ability a restriction depending on the picking type.
This commit blocks the creating by default but leave the possibility to
tick a new checkbox on the manufacturing picking type to allow the
creation of lot and serial number for components inside the production process.
Task : 1891864
This commit fixes the document viewer: the document viewer
was altering the `type` key of attachment objects, this issue was causing
matching errors in some cases.
With this commit, the document viewer widget uses its own key `attachment.fileType`
to store the information that used to override `attachment.type`
closesodoo/odoo#32414
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Technically it does 3 different things:
* switch from 1 level of o2m to 2 levels of o2m when recursing
* handles `parent.<xxx>` readonly modifiers on o2m subfields
* handles `id` readonly modifiers on o2m subfields (already worked in the
normal case but not for o2m records from default_get)
The last two especially are temporary quickfixes, that will need proper fixes.
closesodoo/odoo#32428
Signed-off-by: Christophe Simonis <chs@odoo.com>
When creating a customer profile in Authorize.Net we specify a field
merchantCustomerId that is composed of:
ODOO-{partner-id}-{8-random-characters}
But the limit of this field is of 20 characters:
https://developer.authorize.net/api/reference/index.html#payment-transactions
So if we have 1 million partner, we may have eg. a partner 1000005 that
would result in an ID `ODOO-1000005-af123c5b` that is too long and
results in an error.
With this changeset, the generated ID is truncated to 20 characters so
this should theorically be alright for up to 9.99*10^15 partners (the
postgres limit for an integer is 2.15*10^9 so this should be safe
enough).
opw-1962422
closes#32423
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
When opening the weight screen in PoS it can take up to 10 seconds
until the weighting starts. This can be resolved by using a
Threading.Event instead to reset the 10 second sleep time.
Using exit_flag.wait(timeout=DELAY) will be more responsive, because
you'll break out of the while loop instantly when exit_flag is set. With
time.sleep(timeout=DELAY), even after the event is set, you're going to wait around in
the time.sleep call until you've slept for DELAY seconds.
closesodoo/odoo#32389
Signed-off-by: Olivier Dony (odo) <odo@openerp.com>
This commit fixes a js crash that occured when the user was trying to
edit a new record while the chatter was not completely loaded
(this.field.thread.$el was not in the dom yet)
Behavior before this fix:
Traceback js & impossible to edit the form afterward.
Behavior after this fix:
no traceback, still possible to edit the form normally.
The thread will display on next chatter re-render. Could be forced by
triggering an onchange.
opw-1986061
closesodoo/odoo#33381
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Since b5a12b4aac the website_id was not set anymore.
Indeed, before this commit website_id was the field from the inherits, thus
when writing on website_id from res.user, we would write on the partner field.
But with b5a12b4aac the website_id was explicitely overrided on res.users as a
related to res.partner (its inherits) with readonly=True.
Thus, writting website_id on res.users was not working anymore.
closesodoo/odoo#33521
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
* properly handle 3-args version of odoo.define(): just ignore the
second argument, pretty much the only use-case is dynamic
dependencies (otherwise it should be using static require() calls)
so there's little the extractor can do
* fix an issue with sys.path ordering meaning sphinx would pick up an
odoo installed into the current virtualenv (editable or not) over
the local copy it's part of
closesodoo/odoo#33538
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
- When validating payments on the payment process polling page
errors can occurs and the tracebacks aren't logged which doesn't help
when trying to understand the issues.
With this commit we display the traceback instead of shadowing them.
closesodoo/odoo#33537
Signed-off-by: Toufik Benjaa (tbe) <tbe@odoo.com>
This has several advantages:
- make the code easier to maintain by having the logic only on the python model
- prevent price flickering when changing from/to an impossible combination
- fix the UI for the issue mentioned in the previous commit/the opw
- make the code much faster when using many combinations, by not requiring to
browse and to return every existing and every archived variants
The opportunity is also taken to properly throttle the rpc and to use
"DropMisordered" on its result:
- fix all the other remaining flickering when changing quantity or combination
- fix the server being spammed of rpc when using the configurator modal, but
also in a lot of other cases such as incrementing the quantity, ...
- fix UI consistency by ensuring the result of the last rpc is always the one
displayed, obsolete rpc returns are ignored
By computing the possibility of the combination asynchronously, the two
drawbacks are:
- the UI is a bit less reactive than in the previously the best case scenario,
but this almost completely mitigated by debouncing with a leading call
- it is possible for a quick user to click on "add to cart" on an impossible
combination before the return of the rpc, but this is not really an issue
because when the product will be added to cart there will a check and the
closest possible combination will be selected automatically instead
Finally the event of the configurator mixin and the widgets using it have been
cleaned to avoid the duplication of the rpc in the first place.
opw-1959317
PR: #32691
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Before this commit, if multiple variants exist for the same combination it would
consider the combination impossible if any of the variants was archived.
After this commit, it will consider the combination impossible only if all the
corresponding variants are archived.
opw-1959317
PR: #32691
When the configurator modal is shown on the shop page (when the add to cart
button customize show is enabled), changing the quantity would trigger an
infinite recursion before this commit, because the selector was not finding the
input on the page (because it is not there), but it was not restrictive enough
so it matched the input on the modal itself.
PR: #32691
Install CRM (we need the "Hide Private Message" record rule defined by
that module), create a meeting as of today, set a reminder of one day,
invite another user (Demo) as attendee, save. Edit, go to the options,
change the "Show time as" to "free", save => access error due to the
said record rule.
The reminder is handled by the `get_next_potential_limit_alarm` method
of the `calendar.alarm_manager` model. It uses a raw SQL query to
perform its search. It returns a dictionary of the different events with
data attached. Due to the "Hide Private Message" record rule, some
records are not accessible.
Original (reverted) 9c4b52000 fix was replacing the `browse` by a `search`
in order to filter out non-accessible records. That fix was later fine
tuned by (not-merged) 7dd93809c to exclude calendar's virtual ids. The
real fix is to filter out records in the original result dict.
opw-1974599
closesodoo/odoo#33209
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Co-authored-by: Raphël Collet <rco@odoo.com>
Before this rev., we searched for 'label' tagname into the DOM, but
the fields labels are not always inside <label> (sometimes <span>).
However, they always have className 'o_form_label', so we use this
instead.
task 1961427
closesodoo/odoo#33487
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
- Create a product P
Costing Method: FIFO
Inventory Valuation: Perpetual (automated)
Price Difference Account set
- Create a PO with P, set a price of 100 (no tax).
- Receive the product
2 journal items are generated:
| Account | Debit| Credit|
|-------------------------|--------|--------|
| Stock Valuation | 100.0| 0.0|
| Stock Interim (Received)| 0.0| 100.0|
- Create the corresponding invoice
- Change the:
Discount: 10
- Validate the invoice (for a total of 90.0)
2 journal items are generated:
| Account | Debit| Credit|
|-------------------------|--------|--------|
| Account Payable | 0.0| 90.0|
| Stock Interim (Received)| 90.0| 0.0|
This is not correct, it should be:
| Account | Debit| Credit|
|-------------------------|--------|--------|
| Account Payable | 0.0| 90.0|
| Difference Account | 0.0| 10.0|
| Stock Interim (Received)| 100.0| 0.0|
This comes from the fact that the valuation price is compared to the
price unit without the discount.
opw-1974002
closesodoo/odoo#33296
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
- Create a product P
Costing Method: FIFO
Inventory Valuation: Perpetual (automated)
Price Difference Account set
- Create a PO with P, set a price of 110 (no tax).
- Receive the product
2 journal items are generated:
| Account | Debit| Credit|
|-------------------------|--------|--------|
| Stock Valuation | 110.0| 0.0|
| Stock Interim (Received)| 0.0| 110.0|
- Create the corresponding invoice
- Change the:
Unit Price: 100
Discount: 10
- Validate the invoice (for a total of 90.0)
3 journal items are generated:
| Account | Debit| Credit|
|-------------------------|--------|--------|
| Account Payable | 0.0| 100.0|
| Difference Account | 0.0| 20.0|
| Stock Interim (Received)| 120.0| 0.0|
This is not correct: the Stock Interim (Received) should have a debit of
110.0, and the Account Payable credit should be 90.0.
This comes from the fact that the difference is subtracted from
`line['price_unit']`, which doesn't contain the discount.
We can use `price_val_dif` to update the price. Moreover, the
`price_unit` seems ultimately useless, since it is not used in:
https://github.com/odoo/odoo/blob/e11bacfe512a3170f44d6d43646af914a9cf3b73/addons/account/models/product.py#L63
We still update it for consistency.
Fixes#32911Fixes#33201
opw-1974002
Basic Chart of Accounts and taxes for the Mongolian
accounting. Tags for a lot of reports in Enterprise.
A lot of different taxes are created to be able
to represent them in the vat report. Mongolians
are used to taxes included even for B2B.
Some fiscal positions are added e.g. to automatically
apply 0% for export.
We got a lot of input from our Mongolian partner
Baskhuu Lodoikhuu and colleagues from BumanIT LLC
opw-1946238
Separate pr for 12.3
Closes#32830
Signed-off-by: Cedric Snauwaert (csn) <csn@openerp.com>
If you create a partner with a e.g. the key show_vat, it will be stored on
the partner while we would like to have this information only in the name_get.
After this commit, we will stop to save partner in our production database
with the vat number stored in the name because we create the partner (with vat)
from the invoice, where partner_id have a context with show_vat.
closesodoo/odoo#33492
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
The ir_translation table has an index on the (name, lang, type and value)
key, however this index was not being used when generating field
translations because the column `type` was missing!
With this commit, we fully utilize the index when generating field
translations.
With the eCommerce with categories and 4k+ products, the time to charge
products per category would be around 4-5s; With this patch it is
reduced to 1-2s.
opw-1961665
closesodoo/odoo#33504
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
- When processing payments on the payments processing page,
`psycopg2.OperationalError` can be raised.
We do not want those exceptions to be displayed to the customers,
instead we want the polling page to try to process the payments again.
This commit hides the display of psycopg2 operational errors.
- This commit also fixes the "processing your payments" message being
hidden after the first polling, no matter if the processing has succeeded or not.
closesodoo/odoo#33462
Signed-off-by: Toufik Benjaa (tbe) <tbe@odoo.com>
Before this commit, the URL of the bootstraped homepage for a new website
could be '/-1' instead of '/'.
Indeed, creating a new website ends up calling `page.copy` which try to get an
unique URL for the website (to avoid duplicated URL after copy). Typically, the
copied page will have a suffix (-X).
But `get_unique_path` in charge of doing that is based on `get_current_website`
method which will/could return a wrong website (not the one we created).
For instance the one forced in session after using the website switcher or
creating a website or installing a theme.
As those website already have (most likely) a homepage '/', get_unique_path
will create the bootstraped homepage with '/-1' as URL.
Step to reproduce (among others):
- Create a new website in backend through res.settings screen
- Create another new website, it's homepage will be '/-1'.
- Repeat indefinitely, every two website created, the bug will appear.
(One out of two, the bug won't appear since it will try to get an unique URL
on the previously created website which only has '/-1' so '/' is assumed
unique)
closesodoo/odoo#33372
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
To calculate the product quantity and the average price, two UOM are
used: The UOM of the product, and the UOM of the invoice line.
The UOM of the product it's mandatory in the product, but the product
itself it's not mandatory in the invoice. The UOM of the invoice line
it's not mandatory.
When either of the UOM is not filled, it gives as value NULL, and gives
'empty' as result of the calculation.
Now, we use the psql function COALESCE to return '1' when one of the UOM
is not filled.
closesodoo/odoo#33465
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
- Go to Accounting > Reports > Invoices
- Go to the pivot view
- Enable 'Total' and 'Untaxed Total' in the measures
The Total is wrong.
The sign of the total must be positive for the customer invoices and the
vendors refunds; and negative for the credit notes and the vendors bills.
Before this commit, the total of the credit notes and the vendors bills
weren't negative.
This occurs because the sign of the result of amount_total * invoice_type.sign
is different of the sign of amount_total_signed. Indeed amount_total is
the total amount without sign, and invoice_type.sign is used to change
the sign only for the vendors bills and the vendors refunds
(see https://github.com/odoo/odoo/blob/3cf9cfc985950c30c6b76480f77f5ffe53650b24/addons/account/report/account_invoice_report.py#L144).
Contrariwise amount_total_signed is the total amount signed : negative
for the credit notes and the vendors refunds.
Later on the calculation, the total amount is multiplied to
invoice_type.sign, to have the signs as expected
(see https://github.com/odoo/odoo/blob/3cf9cfc985950c30c6b76480f77f5ffe53650b24/addons/account/report/account_invoice_report.py#L118)
Fine tuning of this commit: 4218f3b
opw-1999175
When you import a variant or when you archive variants to only leave
one tied to the template, the image of the variant can't be changed.
If the variant has a picture and you archive all the other variants,
when you change the image on the variant, it's the template
image which is modified.
opw 1974727
The board created out of a tree view wasn't taking the default domain of
the view.
opw-1958349
closesodoo/odoo#32240
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
- currently, cuurency_id has default value as currency of user's company id. but, when there is no partner set then 'onchange_partner_id' will trigger and set currency_id to false.
- so, set user's currency_id instead of false if no partner set.
Related to Issue: 1948645
closesodoo/odoo#32415
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
If bulk-importing clients with a parent_id set, there's a ton of extra /
post-processing work which is not batched and "de-optimises" the
batching added to import.
High-level comparison of performing a "Test Import" on a synthetic test
file of 10000 partners (all with a parent_id set to a pre-existing
record) went from ~30mn to ~8mn on my machine.
Fixes#31549closesodoo/odoo#31876
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
When a asset is confirmed, it's not allowed to link it to an invoice.
Side effect, it recomputed the depreciation lines of the confirmed asset.
opw:1961468
closesodoo/odoo#32388
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Task#1963335
Now that the product configurator has its own module, the tour
"tour_shop_custom_attribute_value" needs to be split in two parts
to handle the optional products.
The "sale_tour" also needed to be adapted to handle the fact that
the product input can also be a product_template input.
The "shop_buy_product" had its 'add_to_cart' step changed to handle
possible optional products window.
closesodoo/odoo#32368
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Task 1942983
Accounting firms need to upload PDF of customer invoices and refunds (not only vendor bills). For that, we now allow to
* define a mail alias on sale journals
* upload customer invoices from list view
* check for `facture X` XML attachments in PDF of customer invoices
closesodoo/odoo#31655
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
When confirming a second SO, with its project set as the project of a previous SO (so they
can share the same project, and all their task created end up in the same project), we want
to see the sales line without timesheet on the table of the project overview.
Before this commit, it only takes the empty lines of the origin sales order, not the ones from
the second. This commit fixes that by including 2nd SO's service lines in the empty lines to
display.
Task-1915660
closesodoo/odoo#32391
Signed-off-by: Jérome Maes (jem) <jem@openerp.com>
product_location was confusing, not correctly working and is now
replaced by a new feature to manage subcontracting correctly.
TaskID: 1915022
closesodoo/odoo#32390
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Since the package level task, most time it is not move_lines which is
displayed in the form view but move_ids_without_package. We apply the
weird write override to this field too, and we'll apply the comment in
the code (change this override by a proper onchange) someday in the
future.
Task 1831382
We may want do disable a picking type. In this case, we don't want the
linked manufacturing orders to appear on the main view of the
manufacturing orders (not through the inventory dashboards but through
the "manufacturing orders" menu item).
Task 1831382
With this module we can now add the price of the subcontracting on the
subcontracted move by using the `extra_cost` field on the MO and the
unit price of the PO.
We also enhance the view of the supplier info to display a checkbox if
the linked partner is a subcontractr, for clarity sake.
Joint work with: Arnaud Baes <arb@odoo.com>
task 1831382
In a few words, it allows to send components to a subcontractor partner
and receive a finished product. The production is managed through classical
manufacturing orders where the raw and finished location is the
subcontracting location. When creating a receipt picking for a
subcontractor partner, the location_id of the moves will be set to the
subcontracting locations by using the property_stock_customer and
property_stock_supplier of the partner. An override of _action_confirm
will create the manufacturing order.
When a subcontracted bom contains tracking, the produce wizard is
available from the picking to record which lots were produced/consumed.
New type on the BoM: subcontract
New type on res.partner: subcontactor
New location per company (we still own the components stored at the
subcontractor so they're still valued)
New routes created to resupply the subcontracting location on order or
not (through a reordering rule).
Override of res.partner to set the property_stock_customer/supplier on
subcontactor partners.
Proper tests were added too.
Joint work with: Arnaud Baes <arb@odoo.com>
task 1831382
In the subcontracting. we want an extension of the BoM lookup handling
the subcontractor_ids field we'll add. So this is a preliminary work.
task 1831382
William Henrotin