Purpose
=======
The default invoicing policy should be based on the delivered quantities
by default because:
- In countries with anglosaxon accounting, that's mandatory
- Even for other countries, it's probably as frequent as the "based on ordered"
quantities
Task 2159161
closesodoo/odoo#47526
Related: odoo/enterprise#9355
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
For the model 'sale.order'
- Set the action menu 'Share' only for the form view of model.
- Rename the action menu 'Invoice Order' by 'Create invoices' and set
only for the list view.
- Rename the action menu 'Send a Cart Recovery Email' by
'Send cart recovery email' and set it only for the list view.
Also improved tour 'shop_cart_recovery' as now action menu only
available on the list view.
Linked to task 1984526
Related to PR #33720
Purpose of this commit is to send the order and payment details email to user
when they purchase any order from ecommerce or when do the payment from
portal. Currently it was sending quotation mail when the payment is processed.
Now it send an email for quotation, and one email for sale confirmation that
may contain more detailed content if coming from website (eCommerce).
In sale
* create new confirmation template and set the default template in sales
settings;
* when payment enabled in sales settings then display template option to send
default confirmation mail when payment is processed or order signed;
* add tool method to find the right template to use when sending the
quotation / SO by email;
* ensure email is sent everytime SO is confirmed;
In website_sale
* add option in website setting in order, to set the confirmation mail
template;
* ensure email is sent everytime SO is confirmed;
Related to task ID 1873634
Linked to PR #28781
Reason:
*Sales team configuration is too complex with fields you
don't understand and that bring no added value
*Remove the team type, every team should be able to handle
a POS or a website for example
Contains:
*Removal of the team_type, use_quotations, use_leads fields
*Removal of the graph configuration fields
*Adapting the filters that were based on the team_type
*Clear distinction between the team dashboard behavior in crm
from the one in sales
*Cleansing of now dead code due to the removal of the previously
mentionned fields
Task: #1830105
Enterprise PR: #3006Closes: #28063
Purpose
=======
- Quickly share the url to someone else (a client, a colleague,...)
- Ensure that the recipient can access at least
the portal view of the shared record.
- Typically used when a client cannot retrieve the mail to access his order.
The share link can be used in this case.
Specifications
==============
For any object inheriting form portal.mixin:
- Add a button SHARE (not visible in edit mode)
- When clicking on this button, a popup opens with :
- A warning message for tasks and projects only (see below)
- the link (like in gmail) that can be copied
- Recipients
- mail composer (with preselected template) ==> see below
- button [Send Link] [Copy Link] Discard
- After sharing document, put internal note like
"Document shared to xyz,...." with template message
- Anyone with the link, even anonymous user (not logged in) can have access
to the document with the access token provided in the url.
Impacted models:
- account.invoice (Community)
- project.project (Community)
- project.task (Community)
- purchase.order (Community)
- sale.order (Community)
- helpdesk.ticket (Enterprise)
Warning messages and access rules:
Allowed :
- SO canceled or draft will be accessible with the link
with access_token
- If the customer account is B2B (signup not enabled), the recipient
will anyway see the document as the user specifically wants the
recipient to see the document.
Restrictions :
- For Project and Task, if the privacy is not public, then, there is a
contradiction between the access_token mechanism
and the privacy of the document.
- A warning message will be displayed in the share wizard to inform the
user if the document cannot be visible by the recipients and to
ask him to set the privacy to 'Visible by following customer'.
The send button will, in that case, be hidden.
- To avoid to block the share for a new project, default privacy value
is now set to 'Visible by followong customer'
Technical implementation
========================
- Move the access_token mechanism (field + methods + mail controller)
to the portal.mixin to be able to use it in a generic way for each object
inheriting the portal.mixin
- Generalise a part of the _*model*_get_page_view_values method
into a single one in portal
- Generalize the _*model*_check_access into the portal controller of the
portal module
- Remove the init_column + default value for the access_token
> old records have an access_token,
> new one won't but it will be generated on demand via the get_access_token
Done for performance reasons
- Add share button into action menu separately. + kanban view context menu
(except for task and project where button not in action menu but 'simple'
button for task and project because other modules already provide action
to send documents by email, which is not the case for project and task.)
- Add a sign_token used to authentify the recipient in the portal view chatter,
if any. The message will be posted as if the user was logged in.
- Set the _get_share_url as private for security reason
- Add a redirect parameter to _get_share_url to get
If false : The direct portal view url
If True : The redirect url (mail/view/?)
- Cleaning up unnecessary code
- Bug fix :
- Before, if user was not logged and record had partner_id,
if partner id was null, post message was done as admin.
Now, the post message is done as public user.
- If the user had an uid but had no access_token, he could be able
to gain the access token of the record.
check_access_rights was missing in the get_access_action.
Task ID : 30985
Closes#25629
The goal is to be able to more easily create section and notes on sale order, invoice, and quote.
================================
Problems of the existing feature
================================
The problematic part in the existing feature was that the same section had to be defined again and again for every line, instead of being defined only once where it needed to be. There was also no easy way to move them. Those concerns are solved here.
Moreover, due to the complexity of the feature, it was hidden by default, requiring a setting and multiple overrides. The new feature is simple enough that it will always be present.
==================
New implementation
==================
Sections are lines solely used for display purpose, there is no business logic attached to them. They will show as a nice header at the top of the section, and a subtotal at the bottom of the section.
We also take the opportunity to add notes, which are just like sections except they are displayed differently and don't include a subtotal.
=========
Reasoning
=========
We decided to implement it this way, as opposed to creating a proper section model, because it creates less changes in the code.
Creating a intermediary section model between the sale order/invoice/quote and their lines would have required to rewrite the entirety of the code associated to them. It would also have required to create a new JS widget to handle on the same view a double-level One2many (or a One2many + group by).
The current solution is much easier because it just requires adding 2 buttons, 1 simple field on the corresponding models which even has a NULL default value, and making some business checks (don't apply business to section/note).
We tried our best to impact as less as possible the existing models. Notably we didn't want to add any extra field if this was avoidable. This also makes the migration easier.
No matter the implementation choice the views/reports had to be updated to display the sections and notes correctly, which has been done.
===========
Limitations
===========
The current solution has several limitations:
* since the sections don't have business logic, it's not possible to make any reporting based on them
* any business related to sections has to be computed on the fly by browsing in order all of the lines, notably the subtotal has to be computed on the fly at every display
- when sections are moved (drag&drop) on the back-end, the following lines that are part of the section are not moving with the section
===========
Technically
===========
The commit will:
* update the models to add the display_type field (along with related sql constraints to guarantee integrity)
* add new buttons at the bottom of the lists to allow creating section and note, along with the existing add a line/product button
* add some business checks to not apply business to section/note (product_id and account_id became non-required fields)
!!! The most likely cause of potential bugs introduced in this commit would be to have forgotten to add those checks on some places where they would be needed. This is tedious to check but fortunately easy to fix.
* update the views to display sections and notes correctly, also made various improvements/fixes to those views (notably to apply B2B/B2C setting more consistently)
!!! This is the second likely cause of potential bugs: if the updated views are inherited in a way that is not compatible with the changes. Or if we forgot to apply the changes to some other views. Again this is tedious to check but fortunately easy to fix.
Task #53996
PR #25209
It is simpler to have data split by main model or application like we
already do for models and views. It allows to easily have an overview
of data a module holds.
As we will work on mail related data like adding activities or tweaking
subtypes and templates, having them all in a single file and not lost
between other data helps finding and working with it.
This commit only moves code. No functional change should occur.
Not used since a while, remaining of old res.request. Requests have been
removed at 881a76dbcf . Links have been kept because still
used in some reference fields. It seems the last use was in OpenERP v9.0
in crm_claim module. As links are not used since a while let us get rid of
it.
rename values of selection field to actual model names.
this prevents the need of a separate function to get the sql table
and allows to get direct access to the model.
(needed for the next commit)
Functional
==========
Sales teams become sales channels. Their dashboard cards now include a graph
displaying customizable data for managers (comparable to those in accounting).
By default, you now have the following sales channels (non-demo):
Direct Sales (with installation of crm or sale)
Sales Channel type: Sales
Works same as before, what's changed is:
- their cards display one big button directing to the start of their
workflow
- the links on the right-hand side have been reworked, and are only
displayed when there is at least one item requiring attention.
- 'More' tab remains unchanged.
Website (with installation of website_sale)
Sales Channel type: Website
Differences lies in the links displayed in the dashboard card:
- it displays abandoned carts, awaiting payments and payments to capture
Default Channel linked to all sales made from the eCommerce.
Point of Sale (with installation of sale and point_of_sale
-> auto-installs pos_sale)
Sales Channel type: Point of Sale
Linked to pos.configs and their pos.sessions and pos.orders.
- only links to their linked pos.config dashboard and open sessions
- can't use opportunities, lead or invoicing and can only display
pos.order data in the graph.
Default Channel linked to the default pos.config.
Technical
=========
- Add a channel type: sales, pos, website that have different actions/settings
- Add a graphs to the kanban cards in the sales/crm dashboard, configurable in
the form view in the new dashboard page.
- Rename sales teams to sales channels, rename and add default and demo sales
channels
- Change dashboard links depending on the channel type and add a related
computed fields on crm.team
- Rename strings and improve channel form view.
- Leads are now checked by default once activated for 'sales' type channels
- Disable checking "leads" without using "opportunities".
- Hide invoicing and invoicing target depending on channel type.
- Move currency_id to sales_team
Lucas Lefèvre