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.
the widget FieldMany2ManyTags does a rpc to fetch the fields (just to
know if 'color' is in the model...). It was done in a mutex and used
later in a mutex. This commit simply use the willStart method to make
sure the data is available before rendering.
Oversight of e8b965f93c. Although the
previous commit gave the correct behaviour for a negative fixed tax with
a base_amount of 0, it was still incorrect for positive fixed taxes with
a base_amount of 0.
This rewrites the code to more closely resemble the relevant code of
account.tax._compute_amount() solving the above mentioned issue.
When using sequences per fiscal year,
the sequence used to build the bank
statement name must be the according fiscal
year sequence.
opw-671937
Closes#11185
In 9.0's 05adb7f the `<div class="address_format"/>` wrapping an address
city, state_id and zip fields was removed.
There is a hack on fields_view_get which transform this block depending
on the company country, so without the block the feature isn't enabled.
This commit adds a class on the new block `<div class="address_format"/>`
used to wrap the whole address which will change the sizing of the city,
state_id and zip fields as it was before version 9.
To fully follow what was done previously, the zip is aldo moved before
the city if the address format needs it.
Thus we now have as before the three format as follows:
[default format]
city state zip
[format .o_city_state (brazil)]
city state
zip
[format .o_zip_city (belgium, netherlands, ...)]
zip city
state
Another change is brought by this commit, before most element attributes
from city, state_id and zip fields were lost whilst doing the hack, now
they are all kept.
closes#10692
opw-666567
Since aae5647988,
the payment transaction ID is set in the session.
Unlike ecommerce carts, this is possible to open multiple
quotations at the same time
(one browser tab on SO001, another one on SO002),
and therefore to pay multiple quotes at the same time.
This revision makes sure to get from the session the transaction
of the right quote.
That way, the message "Your payment has been received, thank you for your trust.",
is not displayed when opening a new quote when another one was paid
just before.
`ids` is supposed to be either a list of ids, either
a single id.
This revision adds the support of single id
as possible value for the `ids` argument
in methods that could be called with a single id
as value for the `ids` arg.
For instance, `action_confirm` is called
with a single id passed in the method
`_confirm_online_quote` of `website_quote`
Following commit 1dbccc8, there is no `user_id` field on the analytic
account anymore. However, a field `user_id` was added directly on the
project with commit 908f416.
opw-672333
There are 2 journal items missing on the accounting entry that
represents the assignation of the landed costs (for a product that has
already left the stock!) => expense account at the debit and stock
output account at the credit (amount is equal to the cost of the landed
cost)
opw-671311
Prevent drag'n'drop in the following cases:
- Group by field is read-only
- Group by field is a date or datetime
This is necessary to avoid, for example, changing the state of a sales
order or an invoice without going through all the business logic.
Related to #7047
opw-671697
When checking the route of a product, if the product is set with route drop shipping
then the product is available.
Inspired from 14fd46c0d5
opw:672392
Before this revision,
when a user tried to pay his cart with a first acquirer
e.g. Ogone
then came back to the shop (using the browser back button)
then chose another acquirer
e.g. Paypal
a new transaction is created, due to the change of acquirer
(following revision cb9d798)
and therefore, the transaction has a new reference compared
to the last payment transaction attempt (e.g. the ogone one)
but, the old reference is still referenced within
the `Pay now` form values, because the page wasn't re-rendered,
because the user pressed the browser back button, and this
doesn't refresh/re-render the page, and, therefore,
the old reference was still referenced within the `Pay Now`
form values.
Therefore, the wrong reference was sent to the acquirer
(e.g. paypal) and this prevented the payment validation
at the payment feedback, as the new reference was expected
in the feedback information, while we receive the older one.
This revision makes sure to always re-render the `Pay now`
form, so the transaction reference, as well as the other
possible changes in the values, are correctly set,
before sending the information to the acquirer.
POSBoxes will be registered with the government. If a POSBox is not
registered it won't load the blackbox driver, preventing communication
with the Fiscal Data Module.
Nicolas Martinelli