The fith arguemnt of the search method in count in new API.
Passing all arguments as positional arguments will make the context passed for
the value of the `count` argument.
bbc67ec is a similar fix in 9.0
Closes#12830
When the schema of a view change (e.g. drop of column), the "CREATE OR REPLACE"
will not be enough and dropping the view is required.
Fixes#12754Closes#12756
Steps to reproduce:
1. Activate the following options
** Settings > Warehouse > Products > Manage different units of measure for products
** Settings > Accounting > Accounting & Finance > Analytic accouting
2. Desactivate the following option
** Settings > Accounting > Analytic accouting > Sale > Use multiple analytic accounts on sales
3. Create a Sale order
** Add 2 qty of the product iMac
** Add in quote the delivery method "Normal Delivery Charges" and set 2 qty
** Set an analytic account under Contract/Analytic
** Set the field Create Invoice to "On delivery Order"
4. Deliver only 1 quantity of the iMac and then create the invoice
5. Deliver the last quantity of the iMac and then create the invoice
Behavior before the fix:
The first invoice contains 2 qty of the Transport
The second invoice contains 1 qty of the Transport, has no analytic account set, has no UOM set
Behavior after the fix:
The first invoice contains 2 qty of the Transport
The second invoice contains 0 qty of the Transport because it has already been invoiced
Closed#12644
opw:682284
In case of a move where source location = destination location, the result of
SUM(quantity) would be 0 and ending up with a division by zero.
Closes#12247Closes#12423
The view yields one line per stock move, with a price/unit on each line.
It doesn't make sense to sum price/units, the avg will be only meaningful when
grouping per product but it's correct in the default state.
Closes#11309
We don't mount /boot in fstab to prevent systemd-udev looking for
corresponding kernel modules in /lib/modules. We need to do this
because the modified kernel-qemu image we use for emulation is usually
not 100% the same version as in the Raspbian image. Therefore
systemd-udev won't be able to find the 'correct' kernel modules in
/lib/modules.
This causes issues when the raspberrypi-kernel package is updated
however. apt will update /lib/modules and will write the new
kernel{7,}.img files to /boot. Before this patch /boot was just a
directory on /dev/sda2, not the 'real' /boot which is on /dev/sda1. So
you'd end up with old, not updated kernel images but new, updated
kernel modules in /lib/modules.
This mounts /boot after the system booted. /boot gets mapped to
/dev/sda1 by /etc/udev/rules.d/90-qemu.rules.
Fixes#12650
opw-682320
When an applicant is moved from a stage to another, an email is sent to the
applicant(s) if an email template is specified on the stage.
The active_ids is correctly set in the compose context to be used by the
send_mail method to send a message to all the applicants in the new stage.
However, a potential active_id may be propagated from a previous action.
This is the case when a user goes from a Job Position record to the list of
applications and change the stage using the kanban view (active_id & active_ids
is the id of the hr.job).
The default_get method of mail.compose.message will use the active_id as the
default value for the field res_id which is wrong as it is the id of another
record).
Forcing the value at False instead of ids[0] as it would not work in batch mode.
The list of records is correctly used in send_mail anyway.
Closes#12494
Consider fields G1 and G2 being computed fields with inverse methods that
require the value of a common dependency F, which is also a computed field.
For inversing G1 and G2, their values are put in cache, then their inverse
method is called. If the inverse method of G1 requires the computation of F,
setting F's value will invalidate both G1 and G2 in cache. Hence the value of
G2 is lost when invoking its inverse method!
The fix consists in marking G1 and G2 as being computed before invoking their
inverse method, which prevents them from being invalidated by field F.
Setting NOT NULL constraints on required fields may fail if there are
any row with unset value for this column.
The ORM handle this case by catching the exception raised and warning
user.
However, not commiting the current transaction before, will rollback
changes made before like setting default values or renaming a column.
When a product is a kit and a discount is applied thanks to a pricelist,
the discount is counted twice if the invoice is created from the stock
picking.
This is because the pricelist will modify the price unit, but moreover
the discount will be applied a second time by the method
`_compute_price` of the account move line.
opw-676838
Our usage of domain on fields One2many seems to trigger an obscure behaviour on
onchange.
With the following (simplified) config:
Message(models.Model):
_name = 'test_new_api.message'
important = fields.Boolean('Important')
Discussion(models.Model):
_name = 'test_new_api.discussion'
name = fields.Char('Name')
important_emails = fields.One2Many('test_new_api.emailmessage', 'discussion',
domain=[('important', '=', True)])
Email(models.Model):
_name = 'test_new_api.emailmessage'
_inherits = {'test_new_api.message': 'message'}
discussion = fields.Many2one('test_new_api.discussion', 'Discussion')
message = fields.Many2one('test_new_api.message', 'Message')
Steps:
- We change 'name' on discussion, triggers an `onchange()` call
- we ends up filling cache on virtual record (on secondary fields, we calling
record.mapped('important_emails.important'))
- we get a cache miss ('important' field not provided, only 'important_emails' ids,
i.e with no change on existing records)
- we fill the cache, this mark 'important' field as modified
- because of commit 5676d81 and because 'important' is that case is a related (i.e
computed) field we triggers cache recomputation
- as there is no way to recompute 'important_emails' for virtual record (no real
ID) we ends up with empty 'important_emails' generating removal of existing records.
=> Finally changing any value for 'test_new_api.discussion' that trigger an onchange
will always reset 'important_emails' to empty
Fixed by Raphael Collet <rco@odoo.com>, and test by Xavier Alt <xal@odoo.com>.
Do not redefine the view arch but do a proper inherit.
It was a problem as the redefinition removed some fields (headers,..).
It was also a problem if crm_profiling was uninstalled as the redefinition was
not removed.
Closes#12454
The group_lines method didn't make the sum of the quantity field, hence resulting in incorrect results when making product based statistics from the account.move.line records.
Courtesy of Luc De Meyer. Was PR #10551
The `related_usage` field of `purchase.order`
is a related field to the location `usage` field,
which is defined in order to display/hide
some other field in the PO according to the location usage
This is purely a technical field, which is set only
to change the form view according to the location
usage.
This is not expected to change the location usage
through this field, this field must therefore
be set to readonly.
A change on the location usage could happen because
of the `onchange_picking_type_id`:
If the user changed the picking type, and then the location,
the usage returned by the `onchange_picking_type_id` was
applied on the location, and this must not have happened.
In addition, since `related_usage` is a related to the location
usage, it should be changed as well when the location is changed.
(in the new api, this is no longer required, the related field
is updated automatically).
This revision therefore adds an onchange on the location as well,
to handle this.
opw-676428
[FIX] anonymization: default anonymization fields
res_partner.name was twice : remove one
res_users.name doesn't exist (now, it use the partner name) : remove
remove training.* fields that do not exists
Closes#11806
Partial backport of ef19830. The error message cannot be included for
compatibility reason, but the browser will highlight the field in red,
which should be enough to locate the error.
opw-677121
Fixing the error ValueError: "name 'date_from' is not defined"
while evaluating '[date_from, date_to, employee_id, contract_id]'
This commit close#12383, close#8883, close#3116
The parameter forward_debug is used to keep the debug mode during redirection.
Previous code was setting the debug to None which is ignored by werkzeug, making
the option useless.
Closes#12107
Odoo Translation Bot
Stefan Rijnhart
Ronald Portier
Goffin Simon
Denis Ledoux
Christophe Combelles
Martin Trigaux
Daniel-CA
Lionel Sausin
Laetitia Gangloff
Alex Comba
Joren Van Onder
Anton Engelhardt
Nicolas Martinelli
Stéphane Bidoul (ACSONE)
engelant
Alexis de Lattre
Raphael Collet
Christophe Matthieu
Josse Colpaert
Christophe Simonis
Xavier ALT
jeffery chen fan
qdp-odoo
luc-demeyer
Nick-OpusVL
Florian Kisser
William Moreno
Simon Leblanc
Jordan Vrtanoski