Purpose
=======
- Apply the blacklist implementation to Improve mailing subscription to be more
compliant with the European GDPR law. Keep a list of people who does not want
to receive promotional emails (or mass mailing in general) anymore.
- Allows the recipient to update himself his mailing preferences
Specifications
===========
This commit is regrouping some main changes on mass mailing.
Apply Blacklist for following models through blacklist.mixin :
- crm.lead
- res.partner
- mail.mass_mailing.contact
- mail.channel.partner
- Opt_out per mailing list instead of per mailing contact.
- Replace opt_out by blacklist in crm.lead + res.partner models
- Added 'ignored' state for mass_mailing. Ignored = blacklisted, opted-out
Ignored email are not included into final statistics to avoid confusion.
- Unsubscribe(d) pages migrated from website_mass_mailing to mass_mailing module
as thoses pages should work without having the website module installed
Detailed implementation
===================
Mass-mailing :
- A blacklisted email is notified by the ban icon next to the email field.
(at the left of the email field for display purpose)
- Renaming the '_get_blacklist' method that was actually
searching opt_out list into 'get_opt_out_list'
- Opt out per mailing list : Add opt_out + related fields (for display and
ergonomy reasons) on the relational model
- Display relational model tree view instead of mass_mailing.contact tree
view when clicking on mass_mailing_list in kanban view
-> In order to be align between contact_nbr displayed in kanban tile and
the content of the tree view
-> mass_mailing contact is accesible via the user icon in this tree view
- Remove custom filters 'filter_contact_subscription' and
'filter_contact_unsubscription' as opt_out is not on mass_mailing.contact
model anymore
- Add 'is_public' to mailing list
The name of this mailing list can be seen (or not) by recipient in
the unsubscription page
If the mailing lists used in the mass mailing are not public,
the user in only informed that he has been unsubscribed.
If the mailing lists are public, the user is informed that he has been
unsubscribed from the mailing lists
and he has the choice to modify his subscription to all the public
mailing list he is or was subscribed to.
- Unsubscription Page :
- mass_mailing_contact :
Opt_out per mailing list, done by email and not by id, as multiple
contact can have the same email
The recipient can add/remove himself to/from the blacklist
The recipient can send a feedback about why he unsubscribed
- crm.lead + res.partner :
Once the recipient unsubscribe, he is automatically blacklisted
The recipient can 'Come back' and remove himself from the blacklist
if he changes his mind
- Show blacklist button parameter added in config :
The idea is to enable/disable the fact that the recipient can add
himself to the blacklist by showing or not the 'blacklist me' button
Only applies for mass_mailing.contact. The recipient, once
blacklisted, can always, no matter the value of this parameter,
'come back' and unblacklist himself
crm.lead + res.partner :
- Replace opt_out by blacklist in crm.lead + res.partner models.
As when a res.partner or crm.lead unsubcribe, we assume that the recipient
does not want to receive mass mailing anymore, at all, even if we adds him
to a mailing list afterwards. He is then blacklisted to avoid this.
With this behaviour, if a new lead is created with the same email address,
he won't be able to receive mail in mass_mode.
But he will still be able to receive '1 to 1' direct email.
Task ID 33224
Closes#25966
מזל טוב
The direction parameter will now have a real impact on the web interface and
completly switch the direction of the interface.
Add the dependency rtlcss to switch the direction with a css postprocessor.
Two different assets will be generated for ltr or rtl
/web/content/<...>/web.assets_backend.0.css
and
/web/content/<...>/rtl/web.assets_backend.0.css
to be able to differentiate it easily
Adapt the css and views to be easier to switch direction
Render graph as it is, do not move y-axis right side, as per mathematical rule
value goes left from origin are considered negative, so keep graph as it is
for right to left language
add test cases for language direction specific assets bundle
if language direction is rtl then we also store css files in assets bundle
now we store two assets bundle, one for ltr and one for rtl language direction
test two assets bundles generated, also test two assets bundle generated for en_US and ar_SY
Impacted modules: sale, sale_timsheet, sale_stock, delivery and
event_sale
The commit ee2b9fae35 split the
implementation and the api of the `action_confirm` method of
a Sales Order.
This commit tries to go further:
1/ change this API: the private method is the implementation that
should be extended when the confirmation should generated other
documents. The state change is extract to be sure that in all
override of `_action_confirm` the SO state will be 'sale' (and
not 'done', in case of activating the options).
2/ adapt other module to this new API. Some of them does not required
the change to correctly work, but it can introduce future bugs.
Doing it now is better ;-)
3/ With this new implementation, we can prioritize SO line treatment
on confirmation. We want the stockable lines to be processed before the
service ones. Indeed, the line (service and stockable) that should
create a purchase order (future dev for services) will search for an
existing PO, but stock has more precise criteria than services. So,
service SO line will find the existing PO from stock while the opposite
is not true.
So, this is why we are now calling `_action_launch_procurement_rule`
before the `super`.
The rest of the treatments (event, delivery, ...) depends on the module
loading order.
Task #39340.
Purpose
=======
If a SO is only containing lines for which the product is invoiced on
the delivered quantity, the sales order is marked as 'Nothing to Invoice'.
If I add a delivery line, the SO becomes 'To Invoice'. There is not really
a use case in the real life where you will invoice the delivery fees before
invoicing what has been really delivered.
Specification
=============
If an order:
- contains delivery lines or downpayment lines
- If the product on the other lines are invoiced on the delivered quantity
- Nothing has been delivery or can be invoiced for theses lines
Set the invoice status of the sales order to 'Nothing to invoice' instead
of 'To Invoice'
Task ID : 33126
Odoo made the bad choice of using the 'btn-sm' class for every button
instead of configuring the padding for default 'btn' to be smaller.
In BS4, the style of btn-sm is actually more complex, lowering the
font-size too. Also, btn-xs was removed so we would not have the
possibility to display smaller button than our default ones.
This commit removes btn-sm wherever it was used. Unfortunately, this
might remove it at some places where it made sense but this can be
restored in a second time.
In this commit we improve templates used in delivery. Purpose of this commit
is to have templates that embed or use standard Odoo email layouts to make
them look modern and have a common style across all emails.
Main guidelines
* better use of div / p / br to try to lessen layout issues, especially
when updating templates using the editor;
* correctly sequence the templates fields definition;
* correctly set templates values notably auto_delete and user_signature
fields to avoid confusion;
* correctly layout the email content using light notification email. It
can either propagate the layout choice through various send mail methods
or directly embed the styling in the templates for more technical or
complex templates;
* use email_formatted computed field when possible to avoid having hand-made
from / to addresses;
* fix various typos and improve subjects when necessary;
Content of emails is not necessarily updated as the purpose of this task is
about styling, not content itself.
This commit is linked to task ID 1843376 (and 1868112) and closes PR #25349
(and #25889).
Courtesy of Juan José Scarafía, ADHOC
The quality of the Spanish (Argentina) translations is very poor.
Remove them all and will start from scratch, translating only when needed.
PURPOSE
=======
1. Unified product demo data
2. Less demo: one per use case
3. Demo data for all models
Specification
=============
1. Refactor all the brol in the demo data
2. Adapt the tests to make them green, as some products are
renamed, removed, created in python instead of as demo data
...
The field 'packaging_id' of quant package was displayed in tree view,
even if it was impossible to fullfill it because it is added in the form
in module delivery. So the field in the tree view is moved in the module
delivery to be shown whan you can set it.
When using easypost, it could exist more than one tracking
link. In this case they are stored as a json and the method
open_url try to load it as a list of url. Then it checks if there is
more than one url or not. However in a single case, there is only one
string and the lenght of a string is the number of chracter inside that
is often more than one.
The commitment date is computed using every line from the sale order.
When the picking policy is set to direct, it takes the earliest date
among the sums of the order date and lead time.
However when the delivery is set, is adds a line with an order date of 'now' and
no lead time.
This date thus necessarily becomes the commitment date, bypassing what was
intended by setting a lead times on products.
We simply ignore delivery lines in this computation.
opw 1855646
Deep Patel