- Create a stockable product, create a SO selling 1 unit.
- Confirm the SO, validate the Picking 1 => delivered qty is 1
- Return Picking 1 and validate Picking 2 => delivered qty is 1
- Return Picking 2 and validate Picking 3 => delivered qty is 2
The delivered quantity should remain 1.
opw-715685
We sometimes use in Odoo a One2many field with an inverse Integer
field instead of a usual Many2one.
This allow for example in several instances to have a "Many2one" which
can be reference from several models, eg:
Model Ranking:
name = String field
res_id = Integer field
res_model = String field
Model Toy:
rank = One2many [inverse: Ranking -> res_id]
[domain: res_model == Toy]
Model Tool:
rank = One2many [inverse: Ranking -> res_id]
[domain: res_model == Tool]
This enable us to have a shared feature between otherwise unrelated models.
But there was several issue when searching on these One2many:
1) if the Integer Many2one was not stored (eg. it came from an inherits) on
the searched model, this could lead to an error.
2) when we searched:
- by IDs (rank in ['55']) with at least one id not respecting the domain
- by IDs with a negative operator
- with a negative operator on unfound string (rank != "no rank has this")
- with a false value (rank = False)
we would not apply the One2many domain (eg. res_model == Toy) and thus
possibly getting Toy 3 errenously because a Tool 3 was found without
the domain being applied.
This fix modify the search on One2many and for:
1. if the inverse is an Integer not stored field instead of Many2one
manage it.
2. if the field is an Integer field instead of Many2one and there is a
domain on the One2many: apply the domain on the inverse model found.
So only some search on One2many with a domain whose inverse field is an
Integer could be impacted.
This would also be nice to have for all One2many with a domain but the
probability of it being useful versus risk for performance is not judged
high enough.
opw-710508
Use case when it happens:
* Create a maintenance request
* Schedule a date with a duration greater than 1 hour
* Switch to calendar view
* The maintenance request stop time is equal to start time plus 1 hour
and the duration is equal to 1hour.
The calendar view doesn't correctly display the duration and stop date because
the duration field was not passed to the xml view.
This commit pass the duration to the calendar view in the xml and corrects
the help text of the duration field.
Commit 00bd7274c4 introduced speed improvements when
sending emails through batching and reusing an SMTP connection for a
given batch.
However exception management was slightly changed during that patch.
Previously to this patch all errors in the sending process were considered
as MailDeliveryException, except for MemoryError and psycopg errors.
However now mail_mail.send() may raise another kind of exception in the
SMTP connect process. Moreover a raise_exception parameter allows to
choose to either raise an exception, or just set emails in exception
state without raising an error. However since the patch it is not taken
into account correctly.
This leads to several issues, notably
* auth_signup waits for a MailDeliveryException when sending a password
request email. A badly configured SMTP server leads to a connection
error that is not caught. This prevents creating users, which could
be annoying.
* chatter does not handle exceptions as notification emails are sent
using raise_exception being False. Having an issue in the connect
process crashes the chatter.
This commit fixes the exception management so that it behaves like
before the patch.
- Create Product A with a BOM which depends on a product with tracking
"By Unique Serial Number" (Product B).
- Create a MO for Product A
- In the "Register lots" wizard, add two lines for "Product B", with the
same serial number.
Nothing prevents the user to do it, even when the inventory is posted.
opw-709888
The method `write` calls `env['res.lang']._get_installed`, which is ormcached.
After activating a language with `write`, one must invalidate the ormcache.
When unlinking an ir.model, all the ir.model.constraint linked to this
ir.model must be removed to avoid to call unexisting model.
In stable version, the right fix would be to put an attribute ondelete=cascade
on the field model of ir.model.constraint.
In 10.0, the ir.model.constraint are created with module = the module where the related field
has been declared. But when unlinking the ir.model in function _module_data_uninstall, the related
ir.model.constraint to remove were chosen according to the removed modules. So with models
declaring constraints on inherited fields, some problems occured because the model could be removed
and not all the related constraints.
opw:716032
When registering a payment on an invoice, the pop-up kept asking you to
enter a writeoff_account_id even when no reconciliation was asked.
The field should of course not be required in that case.
- Go to Mass Mailing > Configuration > Mail Templates
- In the Kanban view, find a template which contains a link (http,
mailto, whatever)
- Click on the link
You are redirected to the link instead of being redirected to the
record.
opw-706047
When creating a stock.picking, the related fields picking_type_entire_packs and
picking_type_code were both updated.
This was an issue was required write access on stock.picking.type (warehouse
manager) to create a stock.picking (warehouse user).
The fields were updated as they were present in the view and filled with the
related value. Even if the value was unchanged, it was triggering a write
anyway.
The two fields were in invisible="1" and used only in attrs for other fields.
Making these two fields in readonly does not prevent to use it in the attrs but
avoid to send a value to the server and trigger a useless write.
Fixes#15769
Currently the manager fields have this meaning:
* manager_id: employee that approved the leave first;
* manager_id2: employee that approved the leave secondly;
It makes no sense. Furthermore, on the Leaves Dashboard, when you group
by Manager, you group by first approver, which is also a nonsense.
This commit improves the behavior
* rename manager_id and manager_id2 into first_approver_id and
second_approver_id in order to understand their meaning
* add a stored related field manager_id, readonly to avoid modifications
on the employee
* modify the views to only display the real employee manager, the other
values are not valuable on the views
* in code regularly a manager variable is used but is actually the
current employee; a renaming is then applied
When an input is saved with an invalid value, it gets the
`o_form_invalid` class. This makes the border red. In enterprise, there
was a bug as required inputs have also a different border color and the
rule was more important. Unfortunately there is no avoiding
the !important rule here. Indeed, other solutions would require to make
more rules in enterprise or to change the order of files (which would
create many problems).
Setting a max-height on the tags section is not a good idea ; this
causes the tags to overlap the record.
If something (like a text) is put in the section instead of the
tags, the height is not correctly adapted.
In the kanban view, if we try to group by a selection field that is
not defined in the arch, the key will be used as column name (instead
of the string).
A fix has already been pushed to load all the fields in this case
(see 0e6eb96) but these fields were not correctly used in this
particular case.
As the product.packaging model is used for two different business cases,
the views shown when the model is used for product packaging must only
contains a product_id, barcode, and qty because and when it's used for
delivery packages we must show the carrier, barcode, size and wheight.
So for usability purpose, we have made two different views explicitly
called in each use case.
If the company currency is not active (that should not happen but nothing
prevents it, probably happening with some CoA installation), the variable
company_currency_format is undefined and an error is raised.
Closes#15799
When a sale order is created from the interface, the name field is read-only so
not given in the create call.
However, if the create values are filled with the default value, the string
'New' is translated and the condition is not met in the create method.
This commit makes the create consistent with the default `lambda self: _('New')`
Fixes#15839
The manifest loaded l10n_chart_china_standard_business_chart_data.xml but this file no longer exists in Odoo.
Changed to the new XML file.
Closes#15841Fixes#15840
The customers' Tax ID (VAT number) was printed next to the shipping
address *and* next to the invoice address, when both were present.
And when the shipping and invoice addresses matched the customer
address (so neither was printed), the Tax ID was not printed at all.
Simplify this and always print it next to the customer's address,
where it belongs.
During the refactoring of Purchase, the method '_prepare_order_line'
available in Odoo 8.0 has been lost. It's therefore no more possible to
extend this method to covers use cases where we need to provide
additional data to the stock moves created from a purchase_order_line.
This restores the functionality thanks to the method
`_prepare_stock_moves`.
Closes#15842
Sometimes, there is a need for mass mailing "basic" mails with no
image or style. The "basic" theme is designed for this (note that
there still is the possibility to add style and images, default
images are just gray placeholder).
- Create an expense of 0.00, validate
- The expense can never be set as paid since it's not possible to create
a payment of 0.00.
An expense of 0.00 still makes sense in the following use case.
An expense is paid by salary before the expense is actually made, i.e.
I get 1000 EUR to redecorate my homeoffice, I get the money beginning of
the year. After that I want to book expenses against the initial payment
until the 1000 EUR is gone and I would like to make use of the expense
workflow to approve the costs.
opw-710695
When forcing another language that the current one (the cookie one) in an
url, the requested lang wasn't set correctly in redirect url, but the
cookie was, resulting in multiple redirect which ends with initial lang.
A side effect of this error was the inability to edit website page when
default lang is not en_US and user not in default lang.
The request context must be reset before being used by
`request.redirect` (in `url_for` method).
Improve thank page after the application to a job.
Stop duplicate Magic field, using global fields
Add helper method on website to retreive the last created record
Nicolas Martinelli