When the warning module is installed, `onchange_picking_type` is not
called anymore.
When the method `onchange_picking_type` was introduced, it was not taken
into account that the warning module would change the onchange property
on the `partner_id` field thanks to the method `onchange_partner_id`.
opw-672091
Fixes#11342
When there is at least one invoice already linked to the SO, the
default advance payment method must be 'Invoiceable lines (deduct down payments)'
opw:672911
Packaging doesn't include non-imported python file because
redhat. Oblivious, revision 8e81abfeb5
renamed .py.template files to .py thus breaking scaffolding from
packaged odoo.
Revert that specific change.
Fix#11050
Missing bit from #10374: because the _read_xls function is a generator
it is *entirely* lazy and Python doesn't execute *any* code when it's
initially called, which means the file is actually (tentatively) parsed
when the first line is requested which happens outside of
_read_file (and thus of the fallback mechanism implemented by #10374).
Fix by splitting _read_xls between the opening of the workbook (eager)
and the actual iteration (which remains lazy).
When having multiple aliases matching a record, take the first one coming
in the order instead of the last one. This way the defined order is effectively
taken into account.
When using the mailgateway, the responsible of the newly created lead / applicant /
issue is explicitely set to False since the original mailgateway commit in 2010.
However this conflicts with some custom behavior that tries to set the responsible
on the same objects. Notably in recruitment the responsible is set to be the
recruitment responsible set on the job, if any.
In this commit we replace the explicit set of user_id=False to using a
default_user_id=False in the context. This way the admin or mailgateway user
will not be responsible of every new records. And this enables custom behavior
to find a responsible.
Some image functionalities of the inline summernote would only take the
first of multiple editor into account when selecting the targeted image
of an image button action (image size, image padding, ...).
This commit select the appropriate editor given the current editable.
closes#11474
opw-668861
A user in base.group_erp_manager (Access Rights) but NOT in base.group_system
(Settings), will try to fetch the list of groups to generate selection fields
to represent groups selection.
As the method `_is_admin` only verifies the user belongs to group_erp_manager
and the model ir.module.category requires group_system for read access rights,
`fields_get` method tries to fetch the groups and fails with a security warning.
The user fields are fetched when a res.partner form is loaded as the field
user_ids (one2many) is present in the form view of partner in invisible.
opw-672435
We have to ensure that the invoices generated through the POS always
reuse whatever fiscal position is set on the pos.order. Both in the
front- and backend a user can change the fiscal position to be different
from what is set on the customer of the order.
opw-668155
In revision 15b8f35, we decided to 'let ACL and ir_rules
do their job', which is an excellent idea for portal
users but a catastrophe for employee users (since, with
ACLs and rules, they have access to an giganormous amount
of SO, invoices, etc.), which made the server timeout for
big databases.
This commits reintroduces a limitation of the search that
matches ir_rules for portal users but which should limit
the number of elements visible to employees.
The fixed price decimal precision must use the same precision
than the other price field referencing a product price,
as this field is expected to contain a product price.
opw-672877
When the user chooses as product image a file which is not an image, the
message "Could not display the selected image" is displayed. However, at
saving, a traceback is thrown since the file chosen is uploaded anyway.
If the image cannot be displayed, the image field is cleared.
opw-672206
When a CRM activity is defined, the subscription is activated by default
for any user. There is no way to change it since the field is not in
the form view. Therefore, a customer is automatically subscribed to any
internal activity, and the user must manually remove the subscription
afterwards.
The `default` field is displayed in the forw view, so this default
behavior can now be configured for a given activity.
opw-672453
Revision 15f27b2 introduced a dynamic form submission to
avoid some payment transaction problems.
It so happens that form submission in jquery necessitates
said form to actually be in the dom (at least for Firefox
and some version of MSIE); this revision ensures that the
form is updated in the dom by the rpc call then properly
submitted.
In 8.0, when paying by wire tranfer, the confirmation page
contained the detailed payment information.
This behaviour was lost in 9, this revision reintroduces it.
We generate the Mercury invoice number in JavaScript based on the uid
property of the order. That uid is generated by
Order.generate_unique_id() which generates a 12 digit number. A decimal
12 digit number can contain a maximum value of 10^12 - 1 which requires
40 bits to store. The issue is that Integer fields by default are backed
by a PostgreSQL integer type which is only 4 bytes. This means you can
end up with an invoice number you won't be able to store in the
database.
In order to resolve this we will update the field to be a Float field
instead which will result in a PostgreSQL double precision type which
allows values up to 10^308.
opw-671362
When attempting to pay a cart in the ecommerce,
if the customer went on the payment acquirer site
(meaning, the `payment.transaction` is created
in the database), then come back to the checkout form
using the browser back button, and changed his customer
details (address, email, phone,...),
these changes in the details were not applied
in the `payment.transaction` record that was being
re-used.
e.g.
Checkout > Confirm > Choose Paypal, Pay Now
> History back to the checkout and apply changes
in the address > Confirm > Pay Now.
Multiple technical routes were listed in the sitemap,
and it's pointless to list them in the sitemap.
There is currently no way to exclude routes
from the sitemap using a specifc argument
(e.g. sitemap=False on the route).
Therefore, in order to remove them from the sitemap,
we play with the current conditions to exclude
these routes from the sitemap:
- routes with `auth` other than `none` and 'public`
are excluded. Technical routes marked as `auth="public"`
for no reasons are changed to `auth="user" so they
are excluded from the sitemap
- routes with required arguments are excluded as well.
the route `website/image` cannot work without any argument,
`website/image` has therefore been removed from the possible
routes for the method `website_image`, so it's no longer
listed in the sitemap.
For an exhaustive list of the conditions to exclude
a route from the sitemap, check the method
`rule_is_enumerable` in `website/models/website.py`
opw-670865
Commit 4a0b6f6 slightly improves the performances of `action_assign` by
skipping moves which already have pack operations. However, if the move
is not completely assigned, it prevents the possibility to search for
new quants to assign to the given move.
opw-672069
When adding new lines to an existing statement,
the order of the lines was not kept,
due to the re-sequencing operation done in the
override of `write` in `account.bank.statement`:
```
for statement in self.browse(cr, uid, ids, context):
for idx, line in enumerate(statement.line_ids):
account_bank_statement_line_obj.write(cr, uid, [line.id], {'sequence': idx + 1}, context=context)
```
as the lines order was based on `statement_id desc, sequence`,
which is the same for all lines added,
(except if the order is forced in the web client,
using the handle widget)
and, therefore, the order
of the lines returned by `statement.line_ids` was
not determinist.
Adding the `id` to the lines order
(as it's done in `sale.order`, for instance),
solves the issue, as the lines will then be fetched
in the order they were created.
opw-667541
When validating a payment transaction,
if the cart (order) cannot be confirmed or
the email cannot be sent for any reason
(instance, the email template is broken),
the transaction must continue, so the payment
transaction can be set to `done` or `pending`.
In other words, not sending the confirmation
email or not confirming the sale order must
not be blocking to mark the payment
transaction as done.
opw-672486
Commit 7b7f3fa filters out the special periods. However, the filtering
should be done only for the display in the form view, nto for the
reporting which is actually correct.
opw-672531
In v8.0 and saas-6, the PoS does not support the concept of fiscal
position. Therefore, the invoice generated should not use it, otherwise
there might be an inconsistency between the PoS order and the invoice.
FORWARDPORT TO SAAS-6 ONLY!
Fixes#11299
opw-671743
For that, we needed to inverse the processing of the moves of the production order (first consumed, then produced
instead of the opposite) as that way we know the price to put on the produced moves based on what was consumed before.
Nicolas Martinelli