Commit 55549f1e61 changed the way bindings between action and
contextual menu entries are generated. However a typo was introduced
linking Invoice Orders to sale order lines instead of sale orders.
This commit improves the use of mail activities by allowing their
integration with the calendar. Activity types now have a category
field that can be used to trigger some specific behavior. First
specific behavior is to have activity types of meeting category.
Creating activities of this type trigger a jump to the calendar to
schedule the meeting. Meeting activities and calender events are
linked to be able to easily navigate through the document, its activities
and its meetings.
Configuration is done using a category on activity types instead of some
hardcoded "meeting" activity to avoid issues with master data and to be
able to choose which activity type should trigger this behavior.
Linking calendar.event to documents is a good idea to allow searching and
filtering meetings. It also allow to have a link to the document from a
meeting and ease navigation.
There are currently some specific links (opportunity_id for crm.lead and
applicant_id for hr.applicant) but this commit allows some generic
document linking through a res_model_id / res_id fields pair.
As unlinking calendar events leads to separate flows depending on the
event being recurrent some fields are recomputed in cache even if records
have already been deleted. This leads to issues when computing recurrence
and accessing some event data. Let us therefore avoid recomputing fields
when unlinking events.
* fix typo, widged is actually widget;
* support name coming from context for calendar event quick create;
Support of context could be made generic in quick create mechanism but
in the meantime this fix is considered as sufficient for the use case
we have.
- datepicker doesn't default to current date by default
- date string in the input is now selected when clicking the field
- adapted the existing tests to the new changes
When a x2m field is modified, the 'save' rpc doesn't send 'False' as second
argument of the special command that manipulate the set of records.
From now on, the virtual id of the record is sent to the server as second
argument. This commit fixes the tests making the assumption that 'False'
was sent.
- Force vertical margin to 0 in case the class is added to elements
that comes with a default margin (eg. titles tags)
- Move title & subtitle rules at root level
Before this commit, the chatter was rendered as an empty <div/> without
any class while in creation mode. This <div/> was then placed inside
the .o_form_view_bg element by mistake, as it did not match the
'.oe_chatter' selector.
The goal of this review is to have a layout which is correct to
implement the enterprise side-chatter.
This also removes/fixes deprecated community rules and xml templates.
Purpose: When a user print a report, for the first time, if there is
no default template choosen, the user should choose a
template AND should be able to update company information at
the same time.
The company form have to be simplified.
* The company report form now inherits from the company form
* Removing the Curency from the company view
* The choosen template is now highlighted
* Footer and website are moved to the other column to balance the view
base_vat: Removing the VIES VAT check from company form view
base_vat_autocomplete: Move VAT as the first field to fill on the
company form view
Purpose
=======
- Settings are too complex: too long + too many options that shouldn't be suggested with checkboxes
e.g. twitter roller is now suggested as a new snippet to install from website editor
google maps, slides, forum, etc. should show up in the apps store
- When saving the page I expect to stay in the settings -> no redirection to homepage anymore!
Specification
=============
See task 33620
This merge improve account and sale customer portal by
* adding quote confirmation and signature in sale portal;
* adding a signature widget replacing the one in website_quote;
* improving the payment form to support URLs and access token
propagation;
* adding payment support on orders in sale_payment portal with both
server2server and form-based payments;
* adding payment support on invoices in account_payment portal with
both server2server and form-based payments;
* globally improving navigation, display and access token use in
account and sale customer portal;
Please refer to subcommits for more details. Thanks to @jpr-odoo for
preliminary work on those features. Closes#19074.
This commit adds support of payment in the account customer portal. This
is done in the account_payment module. This way customers can now pay
invoices directly on the customer portal and have access to the status
of their invoices. It replaces the old website payment mechanism that
was only allowing to pay without generating payments and reconciliating
them.
Two routes are defined in this commit, one for form-based payments and
one for server2server-based payment. Please refer to commit 1fdb10f0ac
for more details about the new payment form.
Tools methods are added to handle transaction / invoice matching, the
check of invoice and the automatic payment and reconciliation.
Before this commit, the scroll was reset to the top of the calendar after
an event quick create.
This commit fixes this by defining the get/set localState for the calendar
renderer in order to keep the scroll and calling 'reinitView' from the
fullCalendar lib instead of always calling 'render'.
Purpose of this commit is to add a link between invoices and transactions
to store payment data like what is already done for sale orders.
* add payment_tx_id on account.invoice model that stores the last
transaction; also add the acquirer related on the tx;
* add a stat button on invoice with links to all transactions linked
to that invoice;
* add account_invoice_id on payment.transaction model that stores the
link to the invoice;
* add the inverse one2many from invoice to all its transactions so
that we can browse them if necessary;
* keep query on pdf link so that customers have access to the pdf when
using the access token instead of having an access rights error;
* add redirect to record override that allow to take into account
/mail/view links containing an access token for invoices like what
is already supported for sale orders;
* improve action buttons display;
* reduce headers and better display invoice name and customer address;
Purpose is to allow to display error, warning or success messages based
on some user action like payment. This is done using kwargs in the invoice
view route. Codes are added in URL and message display has to be managed
in the template itself. Inheriting modules and/or new features will have
to add their specific message according to the error, warning or success
messages they want to support.
The 'View', 'Accept and Sign', 'Pay Online' buttons are now correctly
computed based on the sales settings or the online quote settings.
Indeed it is now possible to sign and/or pay quotations without having
website_quote module installed.
This commit adds support of payment in the sale customer portal. This
is done in the sale_payment module and uses the settings introduced
previously about online confirmation and payment. This way customers can
now pay orders without having to rely on online quote mechanism.
Two routes are defined in this commit, one for form-based payments and
one for server2server-based payment. Please refer to commit 1fdb10f0ac
for more details about the new payment form.
Some small modifications are done SO confirmation and invoice generation
methods to return error codes that can be used in the customer portal.
As return values were not used in website_sale or website_quote this
should not impact those modules.
Purpose of this commit is to ease the use of the payment widget and
avoid having to perform too much custom code in the various routes used
when doing payments :
* when instantiating the widget give him its parent element data so
that parameters given when calling the payment form template are
automatically present in the widget options;
* support more parameters when calling the route for form-based acquirers
including access_token, URLs and callback method;
* when doing a form-based payment a call to a JSON route returning the
rendered form is done. Payment widget now uses all data from that
form including the URL of the acquirer website. This way form-based
acquirers are really dynamic and values update is easier;
* remove hidden display of form-based acquirers as all data come now
from the called JSON route that returns the form;
* add a warning about partner-id not being set as it is an issue some
people may encounter;
Online quote can now use the generic signature widget already used on
the standard sale customer portal. We therefore remove the custom
widget build in website_quote.
A route already exists to sign quotes; the old route is removed. The
existing route is overridden so that quotations with template requiring
payment cannot be signed. This is the expected behavior.
* website_quote should not override all sale links from the customer
portal to replace them by website_quote specific view. Indeed the
quote view should be used only if the order has an active template
defined on it;
* do not override existing columns of the order page view on portal
with same content;
* implement redirection at route level by overriding the
controller order route;
Customers can access orders using an access token. Order page view may
contain links to invoices linked to that order. However currently the link
does propagate the use of access token and therefore leads to a crash due
to access rights error. This is improved here by adding the invoice access
token in the embedded links.
Purpose is to allow customers to accept and confirm orders on the
customer portal without having to rely on advanced website_quote
(online quotation) features. Including :
* add quote confirmation route;
* add support in customer portal using the newly-introduced signature
widget;
* add action button on the order page view;
Purpose is to allow to display error, warning or success messages based
on some user action like signature or payment. This is done using kwargs
in the order view route. Codes are added in URL and message display has to
be managed in the template itself. Inheriting modules and/or new features
will have to add their specific message according to the error, warning
or success messages they want to support.
Thibault Delavallée