Problem was that administrators have access to every channels, even private
channels they are not registered to, because when trying to join an existing
channel, the autocomplete proposed every channels accessible for the user, but
didn't filter private ones.
This rev. makes sure to only suggest non-private channels.
Also prevent '|' domain injection to disable filters (odoo/odoo@44e65e72d3)
by using expression.py to build domain.
Except for messages, activities on a document like internal notes posted
trigger notifications to partners and channels following the corresponding
activity's subtype.
Rev. 69ed801 rightly re-introduces a filter on followers to prevent notifying
more partners than necessary. Unfortunately, this filter doesn't take into
account channels, which are thus automatically removed from followers to
notify, whatever the subtypes they follow, e.g. internal notes on a document
don't appear in channels following the 'Note' subtype of this document.
This commit makes sure that channels always pass through that filter, but warns
users that public channels should probably not following internal subtypes.
Also makes the edit subtypes dialog html valid (li's must be inside, e.g., ul).
We should not trust arbitrary arguments from public method to compose a domain
as it is possible to inject '|' to disable filters and be able to search any
channel (mitigated by access rules).
Create a private method and use a wrapper that ignores the domain.
The use case is the following: the currency of a customer invoice (e.g.
EUR) is different from the currency of the company (e.g. USD). An
invoice is created in EUR, and a payment is done in EUR on the
receivable account which is in EUR.
Between the invoice date (e.g. 2015-01-01) and the payment date (e.g.
2015-02-01), the rate has changed. The reconciliation between the
invoice and the payment is done afterwards, for example 2015-03-01.
When the write-off related to the exchange difference is created:
- the date should be the max date between payment and invoice if the
corresponding fiscal year is not closed (otherwise, today's date).
- the amount currency on the receivable/payable account should be zero,
since the amount currency on the foreign exchange account is zero.
opw-659289
When selecting contacts from Contacts list views and clicking on
action window "Partner Mass Mailing", the 'active_domain' must be
filled in the wizard with the selecting contacts. In this way,
the right mailing_domain will be set when creating the related
mail.mass_mailing record (in addons/mass_mailing/wizard/mail_compose_message.py
in function get_mail_values).
opw:659383
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
`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.
`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 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.
When a purchase order is created through a procurement order,
the purchase order pricelist is taken from
the partner `property_product_pricelist_purchase`,
which is a property, which therefore can be different
according to the company. This is therefore
important to force the company to the procurement company
when browsing the partner, to get the correct pricelist,
from the right company. Otherwise, it take the pricelist
from the `SUPERUSER` company (when running the schedulers/cron),
which can be different than the procurement company.
The same as to be applied when browsing the product,
as the `standard_price` field (Cost Price) is a property
as well, and can be different according to the company,
in order to get the correct price unit on the purchase
order line, from the correct company.
Fixes#5329Closes#5330
Géry Debongnie