- reworked the multi.compose.message model to manage
several documents simultaneously
- Added a letter model for asynchronous processing
- usability improvement of the modal
In the commit 4a40db2. the implementation of read_group_fill_temporal was
simplified during final review and tests needed to be adapted.
Also fix the implementation issues as detected by the tests.
In order to avoid sending mail indefinitely to a wrong email address,
Take the mail statistics for the recipient of the last 3 month :
if more than 5 mails bounced (with interval of more than 1 week)
the email is blacklisted.
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
Purpose
=======
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.
Specifications
===========
This commit is regrouping some main changes on mass mailing.
- Added blacklist : Avoid sending mass mailing to blacklisted recipient
(blacklisted = email address that doens't want to receive mass mailing anymore)
Detailed implementation
===================
Mail :
- Add Blacklist mechanism in mail module (NOT in mass-mailing) :
as we can send mass-mail without the mass-mailing module
- Unicity in email -> To avoid error in import, override the create and return
the existing record if any, else, create the record normally.
- Blacklisting is done by email address and is cross model.
Will apply to model that inherit the blacklist.mixin.
- field 'is_blacklisted' -> computed : check if email is in blacklist
+ search method to be able to filter on is_blacklisted
- When a email address is blacklisted, it will never get mass mailings anymore.
Even if the email address is added to another mailing lists
- Avoid sending notification to blacklisted recipients when sending email
in mass mail mode. If the recipient is blacklisted, we should not even send a
notification in the recipient's chatter for an email that he won't even
receive.
- When a email address is blacklisted, it can still get 'normal' mailings.
- The blacklist shoud be accessible in
Mass Mailing / Configuration / Blacklist
and Settings / Technical / Email / Blacklist
-> Renaming Settings / Technical / White / Black List config menu item
into Channel Moderation to avoid confusion with Mass Mail Blacklist
- Add indexes to the blacklist table (on email) to make it fast for access for
the different use cases
- _primary_email : attribute that must be overriden to specify which field must
be used as email in the blacklist mechanism.
- Filtering the blacklisted recipient in mail composer :
done in mail._get mail value()
In case of real mass mailing, we need the statistics to be computed in order
to know how many recipients were ignored in the mail.
So we cannot avoid sending mail but instead flag the mail as canceled.
Task ID 33224
Before, the line chart was rendered with a right margin of 0 px meaning the
right border of the graph was stucked against the right border of the screen
cutting out the last x-axis label. This was uggly. This commit fix that
situation by adding a right margin of 80 px.
This commit only applies for chart grouped on date or datetime fields.
In that case:
- Line Charts : fill missing groups and doesn't display undefined values.
- Bar Charts : doesn't fill missing groups but display undefined values.
- Pie Charts : doesn't fill missing groups but display undefined values.
This commit is part of task #1835644
This commit add an extra parameter 'fill_temporal' to read_group which allows
the orm to add missing groups for date intervals. This is useful for charts.
Suppose that we are in a use case where data are grouped by a date fields
(typically months but it could be another interval) and displayed in a Bar Chart
or a Line Char.
Let's says a request has to group records by month for August, September
and ...December. If we don't changed anything, we would get a Bar Chart
looking like this :
___
___ | |
| | | |
| | ___ | |
| || || |
|___||___||___|
Aug Sep D
December follows directly after September, it can be unintuitive for the
user, so we change that. We add some fake records for each missing months
between the earliest and the lastest date of the result
___
___ | |
| | | |
| | ___ | |
| || | | |
|___||___| ___ ___ |___|
Aug Sep Oct Nov Dec
This commit is part of task #1835644
Currently when in payment is configure in automatic invoice mode,
customers don't receive anything.
If they want to see their invoice, they have to log into their portal
account.
Task #1866497Closes#25864
* web, web_editor, website, website_theme_install, portal,
theme_default, theme_bootswatch
The purpose of this task is to make the customize dialog as generic as
possible, that is theme-independant:
1) The design is now totally generic (Odoo visuals)
2) The XML definition is form-view like. This allows themes to extend
the dialog without any risk of breaking the style and also allows to
not care about lots of technical details.
3) New options have been included. Those were themes options that are
now generic and which themes can simply adapt without touching the
customize modal (navbar colors, footer color, navbar layout, fonts,
body background, ...).
The color palette can now also be customized with user colors.
Using sass functionnalities, color palettes and fonts integration is now
a lot better.
Thanks to @qha-odoo for the original design.
task-31677
Task id: 1866074
PURPOSE
=======
Creates a QR code which, when scanned, automatically populates a SEPA transfer form.
If your banking app provides this feature, you can populate an entire transfer form
at the touch of a button, just by scanning the QR code.
This was implemented in order to use it in ecommerce or portal payment views of
quotations and invoices.
SPECIFICATIONS
==============
Sepa qr code:
-------------
- Generate the qr code:
- To figure out. a payment can be done on sales orders, invoices or not related to
anything (simple payment form)
- Configuration:
- Add a new settings in the invoicing config menu "SEPA QR Code" to activate QR
Code payments
- Show an explicit warning if the journal is not well configured to manage qr
code (bank account set, etc.)
- Display: show the qr code after the 'Thank you' message (in web page and printed
documents).
מזל טוב
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
This commit brings a new module to handle the automatical
purchasing of services, like stock does but without using
routes.
On a service product, a checkbox need to be check and a
supplier has to be defined. On SO confirmation, a Purchase
Order will be generated.
See commits details for more details.
Task #39340Closes#25221
This commit adds a new module providing the automatically services
purchasing feature ("Service Subcontracting").
The product of 'service' type can be flag (in the purchase tab of
its form view) as "purchase automatically".
When adding an sale order line with that kind of product, it will
generate a Purchase Order for the supplier of the product, on Sales
Order confirmation. The PO will contains one line with the quantity
on the sale line, with the UoM conversion (purchase uom might be
different from the sale uom on product configuration). The generated
PO is in draft state.
Then several cases can happen:
1/ Increasing the quantity on the sale line
- If PO is draft state ('draft', 'sent', 'to approve') : increase
the quantity on the PO
- If PO is confirmed state ('purchase', 'done', 'cancel') : create
a new PO
2/ Decreasing of quantity on the sale line
- in any cases: shedule a next activity on the PO
3/ Cancelling SO: shedule a next activity on the impacted PO
4/ Cancelling PO: shedule a next activity on the origin SO
The introduction of this module required to move the link between
sale.order.line and purchase.order.line from stock_dropshipping to
thie module, and put sale_purchase as a dependency of
stock_dropshipping.
This commit also brings some test cases.
Task #39340Closes#25221
Add a data common for all models have the 'decoration'
type set to 'warning' to schedule alert activities.
This can be usefull when activities are generated on
related model changes.
Task #39340
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.
This commit dissolves module into sale and sale_stock. Indeed
some fields will be needed for services in next development.
- module is replace by a group in sale
- `commitment_date` and `expected_date` are moved into sale
directly, because they are meaningful for purchasing services
- `expected_date` implementation change when sale_stock is
installed, as the picking_policy of the SO determine if the
min or max dates should be chosen.
- `effective_date` is moved to sale_stock
- tests are moved into sale_stock, and tagged to be executed
after install (post install) otherwise it fails (since
sale_order_dates was a leaf module, it makes sense).
From a functionnal point of view, nothing should have changed,
except that user can see `commitment_date` and `expected_date`
even if sale_stock is not installed, by activating a group.
Task #39340
This is done by displaying this field on top of the vendor bills form view and using it as a default value when registering the payment. The use of a sequence on res.partner.bank also allows giving priorities to partner bank accounts directly from the tree view that is contained in res.partner form. In case payments are generated for multiple invoices at once, their account is set as the partner's most prioritary account.
[IMP] account: payment for multiple invoices: option to group + also group on account + hide memo
Add an option in the multiple invoices payment wizard to choose whether or not to group the generated payments. This is useful in case we want to keep one payment by invoice (even if they share the same partner, etc) so that each of them corresponds to a single communication.
The memo field of this wizard is now also hidden in some cases, when displaying it would allow entering wrong communication values (for example, when paying invoices from different partners ; it makes no sense that all the generated payments share the same memo).
[IMP] account: option to sanize invoice communications
The way the bootswatch library import fonts is not the right way so
we must unfortunately apply a fix in the library itself.
Also review the manifest file.
Purpose of this commit is to improve automated activities in fleet.
Currently they are not always updated or rescheduled. Specifically when
updating the expiration date or the responsible automated activities should
be updated accordingly.
This commit is linked to task ID 1838956 and PR #25899.
Purpose of this commit is to improve automated activities in maintenance.
Currently they are not always updated or rescheduled. Specifically when
updating equipment, technician user of schedule date automated activities
should be updated accordingly.
This commit is linked to task ID 1838956 and PR #25899.
Purpose of this commit is to add possibility of rescheduling the assigned
user on automated activities. Currently rescheduling is limited to updating
the deadline. In some cases we want to be able to update the assigned
user of an automated activity.
Tests are added to avoid regression.
This commit is linked to task ID 1838956 and PR #25899.
Make the lunch alerts blocking if ordering a product from a supplier if not
available at the order time
Add mail templates to generate emails to suppliers.
This merge is only a first step before the Big Lunch Refactoring that will
change forever the way peoples are considering eating lunch.
Add a field partner_id on a lunch.alert
If the field is set, the alert becomes blocking and will prevent people from
ordering a lunch.
Add a available field on the lunch.product that will check if any alert forbids
ordering that product at the time of the order.
Pass the lunch.order date in the context to be able to plan a lunch order
another day if the provider is forbidden today.
A simple new view to easily display all activity on a model grouped
by res_id and activity_type_id. Some action are possible like sending
a mail template for all record having an activity with this activity type
and present in the view (depends on the filter).
The view use the Kanban activity view on cells. It could be a good idea
to rename this widget to something like "DropdownActivityView" (maybe
after the freeze)
Task: #1870662
PR: #26272
Cedric Snauwaert