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
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
"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.
The quantity is not correctly computed, and therefore the weight is
wrong.
The fix uses the appropriate _compute_qty method to convert the
quantity.
Closes#10204
opw-660801
The system showed different Description for product in invoice when you generate invoices based on delivery
orders compared with based on the sales order lines. But the invoice is in the two cases attached with the SO.
Then the description of the product must be the description linked to the SO line.
opw:660723
When cancelling a `stock.move` with as invoice status
`To be invoiced`, the invoice status was left that way.
Therefore, the `stock.picking` to which this `stock.move`
belonged remained in the "Deliveries to invoice" list,
even if all other moves of the picking were invoiced,
and this one cancelled.
Setting the invoice status to "Not applicable" on
the `stock.move` cancellation solves this issue
as the `stock.picking` will no longer be considered
as to be invoiced if all its moves are
invoiced or `not applicable`
opw-660729
The ir.module.module model has a 'url' field (so there is a 'url' field
in db) but the 'url' values in the __openerp__.py files were not used.
Now, the 'url' field is filled with the manifest 'url' value with a
fallback to the manifest 'live_test_url' value.
Despite the fact there is a `company_id` field
on `account.payment.term`, there is no multi-company
record rule on this model. The payment terms
are therefore shared by default accross companies,
even if the company is filled on the payment term.
In addition:
- The `company_id` field on `account.payment.term` is required
- The field is invisible on the payment term form
- The default value is the user company
Adding the record rule would imply to change:
- The fact the `company_id` field is required,
as you probably would like to share some payment
terms accross companies, by leaving empty this field
on the payment term form
- The field should be visible in the form for users
having the multi-company group, so the admins can
create payment terms for other companies than the one
they are currently in.
This cannot be done in a stable release, such as 9.0.
This is for master.
In the mean time, we keep the behavior as it was in 8.0:
We consider that the payment terms are shared among companies,
and the `company_id` field is simply ignored.
This implies that choosing a payment term from another company
in an invoice must not lead to multi-company access rights issues,
as it was the case before this revision: If a user other than
the admin chose a payment term from another company, the on change
on the payment term leaded to access rights issues, as it needed
the read access on the company of the payment term, to get
the currency decimal places.
From this revision, the currency is took from the invoice directly,
through the context, and if not passed in the context, the company
of the user is used instead of the company of the paymen term.
It makes more sense anyway to take the currency from the invoice
instead of the currency of the payment term company to retrieve
the currency decimal places.
opw-659818
project_time_mode_id is the timesheet UoM. However, all timesheet
widgets assume that project_time_mode_id is hours, therefore it is not
supposed to be changed.
Commit fde3a529 unlinks the product and the timesheet. Although we don't
want to use the cost of the product in the timesheet, we still want to
link the timesheet to the product for reporting.
Denis Ledoux