| Age | Commit message (Collapse) | Author |
|---|
|
[MOV] move sale_payment into sale
=================================
Almost all use cases of sale require sale_payment down the line.
There is only one case which does not: using sale_management without website_sale or website_quote.
However, since we want to move most of the features of website_quote into sale_management, moving sale_payement first will make the task easier.
[MOV] move website_quote into sale and sale_management
======================================================
We want to use some features of website_quote without having to install the whole module.
The main issue with website_quote was that it had a requirement on website.
What is common to website_sale and sale_management has been moved into sale. This is primarily the sales order portal view.
What is only related to sale_management has been moved into it. This is notably: sales order templates, optional products, sign and pay, ...
Everything that requires website has been moved into a new module named sale_quotation_builder. This is related to using the HTML builder to customize the quotation view.
Models, files and routes have been renamed to better convey their purpose and to follow guidelines more closely.
[IMP] merge sales order portal views
====================================
The old sales order view on the portal has been merged into the one from website_quote. The new view contains features of the two.
A lot of fixes and improvements have also been done, related to BS4 issues but also to improve the sales order view in general.
[IMP] add new settings
======================
The commit adds new settings related to activating the features that previously were activated by installing website_quote.
PR: #26345
Task: 49205, 1838924
|
|
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
|
|
Both features already existed but it was not possible to enable both.
This makes that possible. When both are enabled the quotation first has to be
signed, then it can be paid.
Purpose
=======
No way to combine digital signature and online payments to confirm orders.
A customer signature matters for big deals, in order to keep an official print
of customer agreement.
Specs
=====
- when the customer signs online, a new pdf is generated with the customer
signature on it and posted as a note in the chatter, replacing the current
signature jpg.
- show the signature in the portal view, with both sale_management and
website_quote module
- change in settings: Digital Signature and Electronic Payment are now 2
checkboxes instead of a radio button
- these settings must be company-specific (add company icon if multi-companies,
like other company-specific settings)
- when both modes are activated, it first request the signature, then the
payment
- the order is confirmed after payment
opw-1818837
Closes #24174
|
|
|
|
It was very confusing for the user to distinct account.payment and payment.transaction. From now on, the transactions are
technical objects and, in the backend, we only refer to it in log messages (Front end will be adapted in the same fashion
later on). They are hidden in debug mode in accounting\configuration\payments as their purpose is now purely technical/log
This commit also aims to reduce the gap between the accounting app and the transactions: account.payment objects are
created/validated upon completion of transaction.
To ease the capture/voiding of pending transactions, the related buttons are now displayed directly on the SO/invoice
instead of the transactions.
Was task: https://www.odoo.com/web#id=35857&view_type=form&model=project.task&action=333&active_id=967&menu_id=4720
Was PR #24043
[FIX] add domain based on journal to payment tokens
Was opw: https://www.odoo.com/web?debug#id=1828206&view_type=form&model=project.task&menu_id=5200
|
|
|
|
- When a quotation if viewed by a customer, a note is posted in the quotation's chatter saying "Quotation viewed by customer".
This is causes issues if the quotation is accessed without the access token and by a partner that do not have the rights to write on the model "sale.order".
To address this issue we provide to the "_message_post_helper" function the sale order's access token to bypass the accesses checks.
OPW-1839183
|
|
Commit 542201eed39 added the possibility to configure a set of countries for a
given payment acquirer.
Commit 194d52e8fda35 refactored the payment form, but forgot to take the country
into acount.
opw 1837819
|
|
|
|
- The module 'website_quote' inherit the CustomerPortal class defined in 'portal/controllers/portal.py'.
It does this to override a single method, namely 'portal_order_page'.
The issue here is that 'portal_order_page' is not defined in the module portal, but in sale.
This causes random issues where the inheritance was not done in the correct order.
Which means the original portal_order_page was sometimes called before its child.
Calling the original portal_order_page first means the child is never called.
This commit change the imported CustomerPortal class to the one defined in the module sale.
|
|
|
|
- Create 2 SO for the same customer
- Send them
- As the customer, click on 'Accept and sign online' for both quotes.
The message 'Quotation viewed by customer' is only posted on the first
quote.
opw-1815082
|
|
|
|
notification message for user who are coming back in Odoo after a payment (like in online quotations & e-commerce)
WARNING: To avoid breaking any configuration in stable (11.0), the template payment_confirmation_status has been replicated in each module.
They must be removed before a forward-port in master
|
|
|
|
- When paying with stripe an error occurs because of a callback generating the invoice for the SO which is called now automatically by the payment system
|
|
- Before this patch, stripe doesn't get displayed.
It was a bug related to the fact that stripe doesn't respect how the generic payment form works.
So to make it work, we were relying on small hacks that got broke by changes on the payment form.
To fix the bug we are no longer adding an event to the pay button of the payment form, instead
we listen all the changes made to the DOM and detect if a form with an attribute 'provider' set to
'stripe' is added.
If so, we open up the Stripe payment form.
- Fix ACL issue when trying to pay with Stripe on eCommerce without being logged.
Closes #20202
opw-776200
|
|
Before this commit, trying to pay a sale order from portal would throw an
error
* create an order in back end, set a partner, a product, a quotation
template and 'Online Payment' as Confirmation Mode;
* confirm the order;
* go to the order in portal (/quote/XX) and click on 'Pay Now';
It throws a server error because route is being called with unexpected
keyword arguments like success_url, error_url, callback_method.
|
|
not configured
|
|
After removing the `sha_in` params a while ago, we get rid of
the deprecated `token_field` option.
- Make `token_field` a model attribute, so that each model can easily
define the token field that should be used, and it does not need
to be passed around all the time anymore.
- Rename `_special_access_object()` to `_has_token_access()`, much more
readable since it returns a bool
- Do not forward the `attachment_ids` keyword arg to message_post,
as it sometimes contains unrelated IDs (the helper is not meant
to post attachments anyway)
- Update callers accordingly
|
|
sale_payment method to check or create a new transaction when paying
a sale order should be named _check_or_create_sale_tx and kept private
like account_payment one. Both versions exists. This commit fixes
the typo.
|
|
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;
|
|
|
|
|
|
- Fixed 500 errors when trying to display payment form because of variables partner_id/acquirer_id missing.
- Accepted credit cards are now display next to the acquirer name on the payment form
|
|
- e-commerce and website_quote create a transaction with its reference when the user click on Pay.
So we need to render the inputs when the user click on pay and submit the form with the values
|
|
- Removed an ugly hack that renders s2s forms then display them using t-raw, we're now providing the xml_id of the s2s forms and uses t-call instead.
|
|
- Online quotation and e-commerce now use the new payment form.
- Added the ability to chose on an acquirer if it uses only form/s2s or both.
(Still need some code cleaning)
|
|
|
|
* StringIO removed from stdlib, replace with io
* try to correctly handle BytesIO/StringIO (one is for bytes the other
is for text)
* fix base64: Python 3 removed bytes-encoding and bytes-bytes
codecs (via #encode) so replace all calls to str.encode('base64'),
also b64encode is a bytes->bytes conversion so attempt to properly
handle that
issue #8530
|
|
This split responsiblilies :
- portal provides basic chatter for portal document, and
website documents (slides, blog, ...).
- website_mail provides comments moderation (unpublished mail
message)
- website_rating integrate rating when posting comments
|
|
This commit moves the whole customer portal to the portal module.
It now completely uses portal and http_routing features and is not
dependent on website anymore.
An override of web controller is added in portal in order to redirect
portal users to /my instead of /web. That way once having the customer
portal installed all share users are correctly redirected to their
account.
All modules defining customer portal templates and controllers are
updated accordingly.
|
|
We make the breadcrumbs of the portal uniform and remove them when we
access the document with an access token without being logged in
(for sales orders).
|
|
Online quote now uses JS code from payment module in order to make online
payments. Front-end template is updated to use o_payment_acquirer_button
generic class for payments and data is added to be managed by payment.js.
This allows to remove some strange code parsing the url to find the order
ID and token instead of using rendered values.
A payment controller is removed because it was only a shortcut to another
one. In transaction controller token parameter is renamed to access_token
to avoid confusion with payment token and match the payment and website
sale naming.
Online Quote controller now uses tools method from sale_payment module
like website_sale. This way it is now standardized and moved out of
controllers that should not perform so much model-level computation.
|
|
Move sale and payment bridge code into its own module. This commit mainly
moves (and reorganizes without changes) code from website_sale related
to payment and SO confirmation.
Only change is that payment_acquirer_id field on sale order is now a
related on transaction.acquirer_id . Indeed in website_sale and
website_quote both values were written but only managing transactions
and getting its acquirer is more efficient and ensure values are coherent.
JS part controlling payment form management is moved directly into
payment to reuse later on in future commits. Probably.
|
|
In Python 3:
* various builtins and dict methods were changed to return
view/iterable objects rather than lists
* and the separate Python 2 view/iterable builtins and methods were
removed altogether
This is problematic when using these items as list (which the happens
repeatedly in Odoo), but more viciously when iterating *multiple times*
over them (which also happens, which I've messed up multiple times while
writing this, and which is a pain to debug even when you've just created
the issue).
Convert all code using these to semantics-matching cross-version
helper functions to get the LCD behaviour between P2 and P3, and
forbid the builtins via lint.
issue #8530
|
|
The content of the report module is now dispatched in
the 'base' and the 'web' modules.
|
|
Portal has access (read only) to partner, pricelist,
taxes, ... These access were given to display informations
on portal pages. Since, these are not very secure, we
remove the access right.
Some modifications are required to make the portal work again :
- 'sudo' business document before rendering templates. ir.rule
are still apply to filter the documents do display.
For instance, SO total amount is computed using account.tax.
- a related field has been added on SO line to allow portal user
to see the image of the ordered product (on SO frontend view)
- a new controller is created to display invoice PDF (as 'sudo'),
since the rendering of this document required read access to
taxes, payment terms, ...
|
|
customer
|
|
Currently when the salesman clicks on 'Preview' button of quotation it
is set as 'Viewed by Customer'. This commit improves this behavior by
ensuring it is triggered only by shared users.
|
|
record pager in portal
+ fix re-use websitue_url in get_access_action
|
|
callback_eval is currently a code string that is evaluated directly
at payment confirmation. This commit changes it to have parameters
on the record and method to call on it. Moreover a hash done once at
transaction creation ensure that a modified transaction does not allow
to execute code on other records.
|
|
A side effect of commit b9d1239effb if that the method `sale_get_order`,
which is used to retrieve the SO, will also update information on this
SO (change partner, change pricelist...). We therefore need another way
to retrieve the SO.
opw-692919
|
|
When a quotation is opened from the frontend, set the SO id in the
request. This is necessary in the following use case:
- Receive a website quote
- Pay thanks to Stripe
After commit da82a6b70553e, we call the route
`/shop/payment/transaction/` manually. However, this route expects to
retrieve the SO id thanks to a call to `sale_get_order`. Since we are
not going through the webshop and the user might not be connected, the
method is unable to retrieve the SO id.
opw-692341
|
|
Somehow in the migration to the new api, it was decided that the
acquirers would be browser as sudo only for token access. This caused
portal users to have a crash when trying to view their quotation since
some fields from acquirers are set the specific groups for security.
This commit reintroduces the old behaviour, which was to browse as
SUPERUSER in all cases for the rendering of the buttons.
|
|
|
|
|
|
|
