This merge changes the way odoo handles notifications. Previously
notifications were sent to the odoo inbox and forwarded by email
depending on a parameter on the partner. Now users choose whether to
use odoo inbox or email but not both. Customers only work using
emails from now on.
This merge also features side commits linked to notifications and mail
like making mail tests less dependent on channels, the removal of auto
read in channels, limitation of assigned emails and project subscription
improvements.
Currently partners have a boolean field to choose whether to receive
notifications only in their Odoo inbox or to receive them in their inbox
and by email. This leads to several issues :
* if a customer is configured to not receive emails he will not receive
any notification on sales orders, leads, ... This is not clearly
indicated to the salesman and it is not easy to know how to change
that behavior
* if an user chooses to receive emails and does not use its inbox a lot
of notifications stay in Odoo. The user has to manually set them as
done to make them disappear which is redundant.
This commit changes that behavior. From now on customers will always
receive all notifications by email. Indeed Odoo is not a customer oriented
mailbox. Moreover sales orders or discussions on leads send to customers
should always be sent by email as it is the standard communication
mechanism. Users will be able to choose to receive notifications in Odoo
or by email. The choice is no longer inbox or inbox + email, but inbox
or email. Choosing one option or the other one depends on the way the
user wants to work.
Technically the field is moved on the users model and selection keys
are renamed. Notification process is modified
* notified_partner_ids contains as before specified recipients as well
as followers matching the subtype
* customers and users working with emails are notified. During that
process customers notifications are marked as done to be able to
track the email state without having needaction. Users notifications
are currently deleted as we do not track their email state.
The removal of partner field implies changes in various addons that
define partner data with this field set in the values.
As picking types aren't always used in a picking context, and picking
aren't really meanigful for a lot of people, we rename this concept as
"operation type" in views and in the planner.
Only allows a manager to unlock a PO. Otherwise, when the option
'Confirmed purchase orders are not editable', any user can unlock a PO
and modify it.
opw-707035
Purpose:
========
A blanket order (it's an agreement with a vendor) is not a call for tenders (you aks several vendor to provide you an offer) but they are regrouped under the category "Calls for tenders" in the Settings of Purchase which should be changed .
Specification:
==============
- Change the setting option for 'Call For Tenders'
- Change 'Purchase Requisitions -> 'Purchase Agreements'
If the data is available in the current context it should be passed to
_select_seller. The calls to _select_seller throughout the lifetime of a
purchase should be consistent (as possible) or the result of
_select_seller could be inconsistent when dealing with multiple sellers
(product_supplierinfo).
Modify a few signature of private methods to pass available information.
Closes#11414
When opening a purchase order shipments using
the given smart button, and attempting a refresh,
it leaded to a "record has been deleted" error,
because the current `active_id` is a purchase.order
id, while the `active_id` in the window action
`action_picking_tree` context expects a picking type
id.
The purpose of using `action_picking_tree` was to use
it as a template instead of having to create a full action
dict, not to actually use it.
By removing the id from the action dict, we prevent
to re-use the action window `action_picking_tree`
on refresh.
opw-706933
To be triggered on the fields that are used inside the computed field.
Was not very problematic before as the fields were not stored and recomputed
at each modification. It could be backported if needed.
Next commit will store these fields for performance reason, fixing the trigger
first is required.
Linked to #15259
When seller_ids are set on a product with a Minimal Order Quantity(MOQ),
the function _select_seller didn't get the ordered quantity so the
sellers with an MOQ were never selected.
opw:704856
This function is only used in purchase_order_change and order_id is a required field
in a purchase.order.line. So this fix has no impact on stable version.
But now it s more generic.
opw:705105
When the quantity of a purchase order line is manually decreased and if
the purchase order line as been generated by more than one procurement.
If the new quantity is lower than the quantity of the smallest
procurement, it is impossible to validate the picking containg the
stock_moves created by the purchase order validation.
It is impossible to validate the picking, because it contains
stock_moves with 'product_qty' set to 0. Those stock_moves are generated
during the validation of a purchase order.
To fix this issue, we avoid the creation of stock moves with a
'product_qty' set to 0 which has no sense.
Set the company rounding policy to "Round Globally". Create the
following SO (or PO), with a 7 % excluded tax:
- Qty Price
- 880.000 5.79
- 120.000 4.36
- 28.000 2.88
- 68.000 11.09
- 35.000 5.20
- 35.000 5.32
The total tax on the SO is 477.48, while it is 477.50 on the invoice
generated from the SO.
FORWARDPORT UP TO 10.0
Fixes#13687
opw-703519
Previous commit was cleaning the orphan and fuzzy translations of all main translations.
This commit does the same for all regional languages (that are not on Transifex).
To keep these files small, keep only the translated strings.
Fixes#14937
Some languages were published on Transifex in v9 but no longer in v10.
These languages were still using the outdated .po files
In some of these po, there were some fuzzy translations that were incorrect
(e.g. 'POS Order %s' - 'Kassa ostud', missing '%s')
These were not erased as still using the old translations.
Regenerate a correct .po file based on the new .pot and remove fuzzy
translations.
Fixes similar issue than raised at #14937
When you activate the use of products packaging in 'stock' module, it
doesn't change anything in the product view if the app 'purchase' is not
installed.
We have this problem because the insert of the product_packaing view in
the product_template form is done in 'purchase' module instead of
'product' module.
To fix this issue, we had to move the page 'Inventory' from 'stock'
moduile to 'product' module. And the group 'packaging' form 'purchase to
'product' module.
Christophe Simonis