Purpose of this commit is to give description more "business oriented"
because those descriptions appears in Odoo Studio which is supposed to be used by end users, not only by developers.
Related Task ID : 37311
Purpose : during a transfer, if some move lines have different
destination locations and the user click on 'put in pack' button, an
warning is triggered. This message, saying : 'You cannot put in the same
pack move lines having different destination location', is replaced by a
wizard allowing the user to choose a unique destination location. This
location will be set as location_dest_id on all transfer's stock move
lines. After that, the wizard calls again the _put_in_pack() method
where all the logic remains the same.
Task : 1872345
In a picking of type 'delivery', hitting the Put in pack button load a wizard
to choose package information. This action that load the package wizard overide
the environement context. the issue is we need 'active_id' later. In a full
python flow, the ORM fill the context with standard values like lang,
timezone, ... and active_id. In a flow using RPCs from JS. The context is
not magically rebuild so we lose the active_id.
With a fixed price delivery method, the error message was not displayed when
the address doesn't match.
Inspired from function base_on_rule_rate_shipment
The error message was not clear enough.
opw:1879204
Regenerate all child translations based on the .pot
Remove the terms that are either equal to the parent, either equal to the
source term.
Remove empty translation files
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 Translation Bot