When pack operations generate extra moves, they should
take the same procurement group as those of the picking.
That way, when invoicing, they will be put on the same
invoice when there is a different invoice address on the
sale order.
In "Payment Follow-up" when clicking on "Send Overdue Email"
if contact with type = "invoice" and an email exists in the childs then
the email will be send to this contact else the normal behavior
is kept. When the overvue email is sent to a contact who is not the commercial
partner, a message is written in the chatter of the commercial partner to inform him
that the email has been sent to the "invoice" contact.
Closes#7870
opw:646149, 646575
The group applied on the purchase invoices stat button
was "Accountant", while "Invoicing & payments" is enough.
That way, the customer and purchase invoices stat buttons
have the same group applied, which makes sense.
opw-646748
Partial revert of commit 39d17c2580
of PR #4617, that broke translations by introducing a different
set of criterions for filtering translations in `_set_ids()` and
`_get_ids()`, adding the `module` column in `_set_ids`.
This meant `_get_ids` would see translations that `_set_ids`
would never update: the translation interface did not appear to
be working anymore as soon as a translation entry existed with
no `module` value.
This is likely for manual entries and for entries bootstrapped
by `translate_fields()`, as they do not belong to any module.
The situation described in PR #4617 probably requires an extra
fix in the translation import system instead.
Using a selection field as color filters in a calendar view
had as effect to display the second letter of the state name
(The state name string, index 1)
as filter, instead of the full state name.
Besides, the colors of the filters did not match.
e.g., Sales > Sales > Sales Orders > Calendar View
opw-646486
The problem originally arises in the frontend (eCommerce). In this case, it is
necessary to switch the user id to the SUPERUSER_ID in order to be allowed to
create a SO. This is done in the method sale_get_order in the module
website_sale. The consequence is that in a multicompany configuration, all taxes
of the product will be retrieved and applied in the frontend.
This fix filters the taxes retrieved to keep only the ones which apply to the
company of the partner, when the user id is SUPERUSER_ID.
opw-645258
opw-645915
Before this addition, cancelling a bank statement line was allowed even if the
bank statement was confirmed. However, when the bank statement is confirmed, it
is not possible to reconcile it afterwards. The consequence is that is was not
possible to reconcile this bank statement line without cancelling the whole
bank statement, and therefore forcing the user to do the complete
reconciliation process again.
With this addition, it is not possible to cancel a bank statement line if the
corresponding bank statement is confirmed. However, we offer the user the
possibility to reset the bank statement to draft through a new button. This new
button will only change the state of the bank statement, and will not modify
the state of the associated bank statement lines. The consequence is that the
user will be able to first set the bank statement to draft, then cancel the
bank statement lines he wants, and finally launch the reconciliation process
only on the lines which were cancelled.
opw-645903
Odoo allows bad formatted emails for partners (and attendees).
Google doesn't.
Therefore, upon sync, if the email is wrong, we do
not send it to Google, to avoid Google being mad at us.
opw-646369
For debugging easyness.
For instance, when trying to sync an event with an attendee
with a wrong email, google failed, it's wasn't easy
to know why from the logs
It is now a bit easier.
opw-646369
Due to the fact the background color was hardcoded, it
wasn't possible to edit the colors of the button link
with the website editor wysiwyg
opw-646655
This regex is used for a quick sanity check of
the order_spec in `search(order=<order_spec>)`.
Because it was build on the repetition of a
group ending with a series of optional patterns,
it could cause expensive backtracking when the
order spec did not actually match the regex
(the regex engine was trying all possible ways
to split the groups)
Forcing the repeating group to either end
with a comma or the end of the string prevents
prohibitive backtracking, while being even
more restrictive with regard to the syntax of
the order spec.
Closes#7755
Complements commit af9393d505
in light of commit 62b0d99cfe,
to really have the correct effect.
When the prefetching failed due to the presence of
extra records in the cache (for which the access is denied),
the `read` operation was indeed retried. However the
result was not stored in the cache because the cache
already held a FailedValue (automatically added when the
prefetch failed).
By default, the argument to pass the record values is `vals`,
not `values`.
Besides, it's not mandatory to provide the argument name
when it's not optional.
opw-646374
Before this fix, a PO line was set as invoiced if all associated invoices were
validated. This is an issue if the invoice_method of a PO is set on 'picking',
and that only a partial quantity is received and invoiced. Indeed, in this case
it was never possible to meet the condition, and the PO could not be set to
'done'.
After this fix, the PO line invoice state is calculated from the invoice state
of the related moves, if the invoice_method of a PO is set on 'picking'. This
is more logical, and moreover this makes possible to set a PO line as invoiced
as soon as all the related moves are done or cancelled.
opw-644399
In the case of a move from an out_invoice not linked to a sale order, the customer taxes set on
the product of this move must be taken into account to create the customer invoice line.
opw:645879
The Journal field is not hidden anymore when filtering on the 'journal_id'. The
reason is that the filter might correspond to several journals. Therefore it is
not possible to know what is the journal corresponding to a given journal item.
The same is applied to the Period.
Fixes#7793
opw-646292
When the invoice is created from the picking, the delivery charges needs to be
converted into the invoice currency. Indeed, there is no currency on a delivery
pricelist.
opw-646148
xmlrpc 1.0 does not support None/null, so commit f3e4d0a will break xmlrpc api.
Therefore, we export an empty string if the field is empty, instead of False or
None. For integers and floats, zero is exported.
opw-643966
deprecate phantom_jsfile method, keeping only phantom_js, phantom_js takes a
code argument to run client side only.
Removing phantom_jsfile will allow to switch from phantom to any other engine
such as running google chrome or firefox directly. The only use of
phantom_jsfile was an example.
Pasting from the website to the website could for example copy
t-field="..." which then would easily add an error if e.g a field
is copied to an area where it is not available.
This fix strip the data-oe-... attributes of nodes added to the DOM
when pasting.
closes#7653
opw-644968
The unticked option in Sales settings "Prepare invoices based on task's activities" doesn't
have to uninstall the options "Record timesheet lines per tasks" and "Generate tasks from sale orders"
in Project settings.
When "Prepare invoices based on task's activities" is unticked, this fix avoid to uninstall these options each
time we go to Sales settings because "onchange_task_work" is triggered each time we go to Sales settings.
opw:645833
In commit 43977deb7 a mrp.bom was transformed from a recursive model
which may contains BoMs containing BoMs and so on, to a simpler model
containing a line of products (mrp.bom containing mrp.bom.line).
mrp_byproduct wasn't changed to reflect on this change which caused an
error.
Since there is no product Unit of Sale on a byproduct, the current
behaviour causing the error of trying to multiply based on the Unit of
Sale of the BoM product has been removed.
closes#7806
opw-645639
opw-645640