In 8.0, the amount currency field was displayed
in the journal items list view
when choosing, thanks to the `quick add` widget,
a journal with a currency set.
Otherwise, if the journal had no currency set,
the column was not displayed.
It was done thanks to the key
"currency" passed in the context.
From 9.0, the `quick add` is no longer used,
and, due to that, the amount currency field
was no longer displayed in the journal items
list view at all, despite if the journal
had a currency set or not.
In technical words, `currency` was
no longer passed in the context,
making the invisibility property
set with
`invisible="not context.get('currency',False)"`
useless.
As this widget is no longer used, there
is no other choice than either
always display the column, either never.
We choose to display it only if you have
the multi-currency group (as this is the case
in the journal item form view)
We also take the opportunity to move the column
next to the debit & credit column, this is more
meaningful.
opw-676059
When creating assets from invoice lines, the system must check
that assets have not already been created for the related invoice.
If assets already exist then these assets have to be removed.
Used case:
- In the purchase journal, tick "allow canceling entries"
- On a supplier invoice line, set an asset category
- validate the invoice
- cancel the invoice
- set to draft
- validate the invoice
Before the fix: the asset is created twice.
After the fix: the asset is created once.
opw:674674
Note: This is a cherry-pick of commits 9d14230 and 58a5b5e
In v8.0, when a procurement is cancelled and the quantity remaining on
the PO line is zero, the line is deleted. It was not the case anymore
after the Purchase refactoring.
opw-675493
When creating a partner with company_type='person' and with an invoice
adress, the created partner must stay a person.
Now a partner which is not a comany can have an invoice address.
Fixes#11730
opw:675322
If the feedback of a form is too slow, people might be tempted to
click a second time, trigerring a second request. If, after that,
the result has not been received yet, the user might be tempted
to click a lot of time because he is angry at such slowness. This
behavior would trigger a record creation each time the user clicked
the submit button. This fix disables the button once it has been
clicked once, and re-enable it if the record could not be created,
which means that there was an error in the input and the user needs
to change the values and try again.
The button has been changed to a span to avoid the default browser
behavior to post the form when no function is bound on the send button.
If the feedback of a form is too slow, people might be tempted to
click a second time, trigerring a second request. If, after that,
the result has not been received yet, the user might be tempted
to click a lot of time because he is angry at such slowness. This
behavior would trigger a record creation each time the user clicked
the submit button. This fix disables the button once it has been
clicked once, and re-enable it if the record could not be created,
which means that there was an error in the input and the user needs
to change the values and try again.
The button has been changed to a span to avoid the default browser
behavior to post the form when no function is bound on the send button.
When creating assets from invoice lines, the system must check
that assets have not already been created for the related invoice.
If assets already exist then these assets have to be removed.
Used case:
- In the purchase journal, tick "allow canceling entries"
- On a supplier invoice line, set an asset category
- validate the invoice
- cancel the invoice
- set to draft
- validate the invoice
Before the fix: the asset is created twice.
After the fix: the asset is created once.
opw:674674
When creating assets from invoice lines, the system must check
that assets have not already been created for the related invoice.
If assets already exist then these assets have to be removed.
Used case:
- In the purchase journal, tick "allow canceling entries"
- On a supplier invoice line, set an asset category
- validate the invoice
- cancel the invoice
- set to draft
- validate the invoice
Before the fix: the asset is created twice.
After the fix: the asset is created once.
opw:674674
The pricelist field is not a mandatory field on the partner. A default
value is usually defined for any new partner created. However, if the
pricelist is manually removed from the partner, errors (tracebacks) will
occur in the eCommerce when no pricelist is found.
We cannot make the field mandatory, as it could potentially break the
workflow of some users which are not using eCommerce. Therefore, we
simply log an error message to help debugging.
opw-673453
The "Resumes and Letters" action simply displays ir_attachments
linked to hr_applicant objects; but there is no default_res_model
in the context so no ir_attachment you create is actually
displayed in the kanban view.
Since the goal of this action is simply to display attachments
linked to applicants, it makes more sense to disable the create button
and to force people to upload resumes and cover letters through
the applicant record.
Avoid raising an access denied error for messages that
the user has indeed be notified about.
The issue arose when a message posted on a document inaccessible
to the user was notified to one of the channels the user
is subscribed to.
The access control logic on messages relies on 2 heuristics
to grant read access to a message:
a. either the user was notified about the messages, by being
a follower of the document, or a subscriber of a channel
following the document (in that case the user can see the
message but not the document)
b. or the user has read access to the document on which the
message is posted (in that case the user can see both
the message and the document)
Case `a.` sometimes fail to match when a message got notified
to several channels including one the user was not subscribed
to. Depending on the order of the returned rows in the SQL
query, the "foreign" channels could shadow the channels of
the user, making `a.` a non-match.
If case `b.` did not match either, the user would have the
`read` access denied, even though the message was visible by
the `search()` method.
The fix explicitly makes case `a.` match if the user was
notified in *at least* one channel.
This was not done through a change of the SQL query ORDER,
for readability reasons.
From 9.0, a sales order to invoice is no longer a
sales order in the state `manual`, but with the
Invoice Status "to invoice".
Before this revision, the sales order to invoice
were simply not counted at all, and this
count always displayed 0.
opw-675919
Lines have to be wrapped manually as nor the ESC/POS protocol, nor the
hw_escpos module will do it for us. Before this long product names where
truncated to 24 characters by hw_escpos.
This wraps the product names using available spaces in the product
name. A product name with > 24 continuous characters will still be
truncated.
When a user validates an invoice linked to a SO, he might want to modify
it afterwards thanks to the 'Modify' option in the refund wizard. This
will create a refund, reconcile and create a draft invoice.
The issue is that the draft invoice is not linked with the SO.
The fix is to link, in this specific case only, the draft invoice to the
SO. At the same time, we have to make sure to:
- unlink the first invoice (to prevent counting the quantity as invoiced
in the SO)
- keep track of the first invoice/refund in the invoice list of the SO
opw-673446
The new model is now the following:
- each recordset is attached to a prefetch object: records._prefetch
- the prefetch object associates model names to record ids to prefetch:
ids = records._prefetch[model_name]
- a call to model.browse(ids) returns a recordset with a new prefetch object
- the prefetch object is passed and populated by
- iteration
- access of relational field
- with_env(), sudo(), with_context()
Make the following statements add secondary records (values of relational fields)
in the prefetching object of ``self``:
self.read(fields)
self.partner_id # implicitly invokes read()
This makes sure that traversing relational fields on records automatically
feeds the prefetching of secondary records.
The prefetching now has a more intuitive and controllable model: every
recordset is linked to a "prefetch object" that tells which record ids to
prefetch for any model. The prefetch object of a given recordset is shared
with the records obtained by iteration and relational field access. All other
operations instantiate recordsets with a fresh prefetch object.
records = model.browse(ids)
assert records._prefetch is not model._prefetch
for record in records:
assert record._prefetch is records._prefetch
assert record.relation._prefetch is record._prefetch
The cache data format has been split between a cache format and a record format
(returned by accessing a field on a record). We have the following converters:
ANY FORMAT
|
| convert_to_cache
v
CACHE FORMAT
|
| convert_to_record
v
RECORD FORMAT
|
| convert_to_read
| convert_to_write
| convert_to_onchange
| convert_to_export
| convert_to_display_name
v
OTHER FORMATS
Modify the API of the converter methods to make them uniform (pass value and
record), and adapt their documentation.
On the `res.company` model, the fields
`name`, `phone`, `email`, `website`, `vat` are
related field on the `partner_id` of the company.
When creating a new company, the partner
associated to the company is created automatically,
it's handled in the overrided `create` method
of the model, but it forgots the values
`phone`, `email`, `website`, `vat` at the moment
the partner is being created.
opw-675526
Aaron Bohy