Format_tz allow to format a date, but if the format was '%B', it was always January regardless lang in context
Now, it possible to use babel, to get the date in the customer language.
So:
format_tz(object.date_order, format='short', context={'use_babel':1, 'lang': 'fr_BE'})
will return '5/01/16 22:20'
format_tz(object.date_order, format='short', context={'use_babel':1, 'lang': 'en_US'})
will return '1/5/16, 10:20 PM'
format_tz(object.date_order, context={'use_babel':1, 'lang': 'en_US})
will return 'Jan 5, 2016, 10:20:31 PM'
format_tz(object.date_order, context={'use_babel':1, 'lang': 'fr_BE'})
will return '5 janv. 2016 22:20:31'
When configuring the payment acquirer with the confirmation
`at_pay_now`, meaning the sale order has to be
confirmed when clicking on the "Pay now" button, instead
of waiting for the payment confirmation,
the confirmation email wasn't not sent.
opw-665697
As the report are downloaded from a controller, the context of the
webclient is lost. We chose to use `context_get` to get back one
instead of serializing the context trough the url.
This revision is related to 6efc371291
The return URL parameter key has changed: The capital letters
are not the same than before.
Besides, send a dict in the `ADD_RETURNDATA` doesn't seem
to be supported by Buckaroo. We therefore no
longer uses a dict but a string to avoid problems.
opw-665697
Does not explicitly mention how static files are loaded. This will
confuse anyone who is using the documentation as a guide and not going
through the pet store example code. Feel free to edit however, as long
as it is mentioned somewhere.
fixes#9170
If anybody adds a new modal in the `then()` part of the promise, without
this code, all `.modal-backdrop` elements will be deleted, and further
dialogs will not be modal; with this, only the current modal's backdrop
will be deleted.
`default_location_dest_id_usage` on `purchase.order` is
used only for an attrs domain on the field
`dest_address_id` in the purchase order form.
There is therefore no worries to set it as readonly,
it won't break the feature he has been added for.
Besides, this will prevent the useless write of the
same field value on the related `stock.location`
when saving the purchase order.
This is important to prevent the useless write
on `stock.location`, as users might have the rights
to create/edit purchase orders without having
the write access to the stock locations.
opw-660736
We have taxes on pos.order.line and we have taxes on the product of the
`pos.order.line`. There was no real consensus in the POS about which
taxes to use. As long as they're the same it doesn't cause issues, but
if someone where to change the taxes on a product which is used in an
open `pos.session` things will start going wrong.
When closing the pos.session amount_total of the `pos.order` in question
will not equal tax `account.move.lines` + product
`account.move.lines`. The reason for it is that we use the taxes on the
`pos.order.line` for the tax account.move.lines, whereas amount_total
used the taxes on product.
This fixes the problem by always using the tax set on
`pos.order.line`. This tax should be set only once through
`_order_line_fields` during orderline creation. After that it shouldn't
change. Therefore `pos.sessions` won't be affected by changes to taxes
of products anymore.
opw-660765
In some non-usual circumstances, using unicode in controllers can lead
to issue. For example on a terminal using C encoding (instead of the
mighty UTF-8) werkzeug might use sys.getfilesystemencoding to encode the
request URL which will fail with UTF-8 inside.
This commit change the URL character of the font awesome controller to
UTF-8, but keep the old way since every sent mail might still use it.
There is the overlap of character 0 to 9 which are overidden in this
commit by unicode code 0 to 9, but these were not used in font-awesome
anyway (or these are not even visible ASCII characters).
closes#9572
When creating a department, a default message appears in the chatter
that says "HR department created". It is misleading because the
department is not necessarily HR.
The default domain set in _compute_analytic didn't allow to recompute
SO lines linked to several analytic lines because unit_amount is always
greater or equal to zero. The idea is to recompute the quantity delivred
on SO line linked to analytic lines with amount<=0 (which means that this
is a cost for the company, an expense or a refund).
opw:660812
With de5a00ac9 the editor would be loaded on the forum, but it would
then always be loaded on the website which might not be for the best.
With this change, the editor assets will be loaded on the website:
- if the viewer is part of the "base.group_website_designer" group,
- if we are on a forum page,
better solution for #9402
"total_invoiced" must only take customer invoices into account because
when you click on the button "invoiced" in the partner view form
you just see the customer invoices.
opw:665574
Remove fixed width for kanban records in .o_kanban_mobile (in grouped
view the records overflowed their columns).
Note: this class seems useless and wrongly used by templates. This
should be removed in master (remove the class from templates and
include its less rules in all kanban records for specific classes).
"//div[@class='o_my_sidebar']" is not valid and fails when evaluated.
Could have been replaced by "//div[contains(string(@class),"o_my_sidebar")]" but
as needs a view modification, using an id is better for future inheritance.
Fixes#10279
Commit ec949ad5 links the extra move to the Sale Order through the
procurement. To be consistent, we also have to link the extra move to
the Purchase Order.
The original issue is that any extra move is not taken into account in
the received quantity calculated.
opw-665398
Christophe Simonis