From f255aa7,
the lost semantic is `probability = 0, active = False`
The existing filters "Lost" in the leads/opp search views
have not been updated with this change of semantic.
opw-666186
Mailing lists (mail.channel) should not send specific notification emails.
Indeed there can be a lot of recipients and customizing each email can
take time to compute. This leads to posting a message on a mail.channel
being very slow.
It is now possible for a model to customize the notification email
recipients computation. The first use is to ensure that mail.channel
encodes recipients using email_to instead of recipients_ids. This way
less processing is performed on notification emails.
This is a manual cherry-pick of commit d4a1eb4435
that was not forard ported. Mail has indeed evolved since 8.0 and its
forward port was not an easy task.
This commit also includes the fix of mail.channel recipients. All are now
considered as equal and receive a simple notification email. No distinction
is done between partners and users. The notification emails for channels
should be as simple as possible.
The mixin model factors out code necessary for interacting with mail aliases.
In particular, it initializes aliases upon record creation and delete aliases
upon record deletion. This simplifies the definition of models using aliases.
The web planner should be hidden by default. Now, it is displayed,
then hidden in js after a while (but it can be seen by the user), then
displayed again if necessary
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
Remaining products :
- product_product_0 becomes service_order_01
- product_product_1b becomes service_cost_01
- product_product_43 becomes product_order_01
- product_product_47 becomes product_delivery_01
- prodcut_product becomes product_delivery_02
- Replace product_product_56 by service_delivery
- Replace product_product_59 by consu_delivery_01
- Replace product_product_58 by consu_delivery_02
- Replace product_product_57 by consu_delivery_03
Removed products :
- product_product_53, product_product_57, product_product_55, product_product_54, product_product_52,
product_product_51, product_product_50, product_product_48, product_product_46, product_product_32,
product_product_33, product_product_28, product_product_38, product_product_39, product_product_40,
product_product_41, product_product_34, product_product_29, product_product_30, product_product_44,
product_product_31, product_product_35, product_product_36, product_product_37, product_product_42,
product_product_45, product_product_49, product_product_26, product_product_14, product_product_15,
product_product_18, product_product_19, product_product_21, product_product_23
Removed corresponding binaries.
Removed all Bill of Materials demo data, that were ridiculous and replace them by 2 bom: A complete
computer, and a kit computer. Rewritten the tests accordingly.
Fixed tests :
- sale_mrp/test/cancellation_propagated.yml : The yaml ref function return a id, not a dictionnary
- sale_stock/tests/test_sale_stock.py : The service product invoiced on the delivered quantity was
in fact not invoiced on delivery on the test. As we are in sale_stock, Without timesheet, we
manually set the delivered qty for the product serv_del. If we don't do this, the invoice will
never be fully invoiced.
- The pricelist rules choice is not based on the sequence anymore (Seems to be a bug, reported to
online). By the way, I changed the product to avoid the overlap.
- sale_mrp/test/sale_mrp.yml: The yaml ref function return a id, not a dictionnary
- mrp : Rewritten the tests to be coherent with the new bom data
Quotations and sales search views are udpated. Indeed they share a lot of
common filters. However their use is different and their filters should
therefore be different.
Using a base view, those two now have separate search views allowing to
define custom filters for quotations and sale orders.
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'
Cedric Snauwaert