`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
Commit 64e1c28e3 introduced timezoning in resource_calendar in resource already.
This broke the stock_calendar module, but as such, the timezoning in the module
is not necessary anymore. All dates calculated from the times in the calendar
are calculated back to UTC and the results are without timezone in UTC. That way,
timezones are also not needed for calculating the leaves.
Commit 64e1c28e3 introduced timezoning in resource_calendar in resource already.
This broke the stock_calendar module, but as such, the timezoning in the module
is not necessary anymore. All dates calculated from the times in the calendar
are calculated back to UTC and the results are without timezone in UTC. That way,
timezones are also not needed for calculating the leaves.
The keep_query() function has to **keep** all or selected query parameters
or add new ones but not change them by merging those with the same name.
That unnecessary parameter merge breaks the *Change language* feature in the
website_sale module when *Website -> Customize -> Product Attribute's filters*
is enabled and there's 2 or more select type attributes created and at least
one of them is selected.
Merging params was added in:
* 8.0: commit 7759af7c4c
* 9.0: commit daf8bdf688
`event_sale` adds an onchange on the `product_id` of the
sale order lines, which returns values for the fields
`event_type_id` & `event_ok`, which are used for an attrs
domain on the fields `event_id` & `event_ticket_id` in
the sale order line form (dialog). `event_type_id`
& `event_ok` are related to `product.product` fields,
in addition.
Changing the partner of the sale order triggers
the onchange on the lines, which triggers
the onchange of the `product_id`.
As these two fields `event_type_id` & `event_ok` were
not in the sale order lines tree view, as readonly,
they were passed to the write operation when
saving the SO, therefore writing on the product (the
same value than before, in addition).
Indeed, if an onchange returns values for fields
that are reandonly in the view, these are ignored
when saving/writing. However, if the onchange
returns values for fields that are not in the view,
these values are nevertheless passed to the write operation,
even if there was actually no change.
This behavior should probably change, that if an onchange
returns values for fields that are not in the view, these
are ignored, either when saving the record, either when
returning the result of the onchange.
Either way, these are risky changes, that we prefer to avoid
in a stable release such as 9.0. As a workaround,
we therefore add these fields in the sale order line tree view,
as readonly, so they are properly ignored when saving
the record.
This is important to avoid this write on `product.product`, as
users can have the write access to the `sale.order` without
having access to the `product.product`
(e.g. `Sales > See own leads` group)
opw-660716
When you are in form view and came from calendar, a screen refresh
throwed an error from fullcalendar lib. Also when going back to the
calendar view, it would not be loaded.
It is due to fullcalendar not being rendered if it is not visible, and
other part of the Odoo code are dependent on it having been rendered.
This commit hide the calendar after having been rendered.
closes#10253
opw-659314
The links present in forum messages are parsed to integrate "nofollow"
attribuate in it.
In case the content of the link contains some special char (e.g. <a>foo)bar</a>)
the regex fails as it interprates the content as an invalid expression.
Nicolas Lempereur