A side effect of commit b9d1239eff 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 da82a6b705, 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.
When the route /quote/<order_id>
is accessed without token
e.g. through the `View sales Order` button
in the headers of thread mails
the user must be redirected to the login screen
if he's not signed in.
In other words, you must be signed in to access
this route without token.
opw-687931
Currently some customers receive the automatic notification 'Quotation
viewed by customer'. This should not be the case as this notifciation
is purely internal and should only be sent to the quote responsible.
Notification is now a note with the responsible being directly in the
recipients.
Conflicts:
addons/website_quote/controllers/main.py
Backport of 14f07cb96f
opw-687957
Currently some customers receive the automatic notification 'Quotation
viewed by customer'. This should not be the case as this notifciation
is purely internal and should only be sent to the quote responsible.
Notification is now a note with the responsible being directly in the
recipients.
* get_pdf function expects a list of ids since the removal of old api in
this commit: rev 47c67b640b
There were still some wrong calls.
* while get_action can receive ids and recordsets, get_html and get_pdf
are internal methods and still work with list of ids
* Remove dead code
* Clean variable assignation to a record set and use a dedicated variable to
hold the result instead of setting a property on records
Since saas-3, website controllers use `request.website.render`
to render the template of a web page. This was kept for retro
compatibility. It's time to stop using deprecated stuff.
Same for `_render` method on website.
'json' route don't use `request.render` since
`JsonRequest` has no `render` method.
Introduces two new options:
- confirm_so: to confirm the sale order on acquirer confirmation
- generate_and_pay_invoice: confirm_so + generation of invoice and
payment registration
The transaction `type` of an order can depend according
to the order.
For instance, if the order leads to recurring payments,
the transaction type became `form_save`
instead of `form`.
This new method allow to easily override this `type` value
for other modules, so the entire button
rendering code does not have to be
copy/pasted.
Since aae5647988,
the payment transaction ID is set in the session.
Unlike ecommerce carts, this is possible to open multiple
quotations at the same time
(one browser tab on SO001, another one on SO002),
and therefore to pay multiple quotes at the same time.
This revision makes sure to get from the session the transaction
of the right quote.
That way, the message "Your payment has been received, thank you for your trust.",
is not displayed when opening a new quote when another one was paid
just before.
Before this revision,
when a user tried to pay his cart with a first acquirer
e.g. Ogone
then came back to the shop (using the browser back button)
then chose another acquirer
e.g. Paypal
a new transaction is created, due to the change of acquirer
(following revision cb9d798)
and therefore, the transaction has a new reference compared
to the last payment transaction attempt (e.g. the ogone one)
but, the old reference is still referenced within
the `Pay now` form values, because the page wasn't re-rendered,
because the user pressed the browser back button, and this
doesn't refresh/re-render the page, and, therefore,
the old reference was still referenced within the `Pay Now`
form values.
Therefore, the wrong reference was sent to the acquirer
(e.g. paypal) and this prevented the payment validation
at the payment feedback, as the new reference was expected
in the feedback information, while we receive the older one.
This revision makes sure to always re-render the `Pay now`
form, so the transaction reference, as well as the other
possible changes in the values, are correctly set,
before sending the information to the acquirer.
When configuring the payment acquirer with the confirmation
`at_pay_now`, meaning the sale order has to be
confirmed when clicking on the "Pay now" button, instead
of waiting for the payment confirmation,
the confirmation email wasn't not sent.
opw-665697
This revision is related to 7be2403cf5
The payment acquirers must be fetched if the quote
needs a payment.
Besides, as explained in the above revision, the state
`manual` no longer exists sales orders, and therefore
this must no longer be used to determine if a quote
needs a payment or not.
opw-660575
Before this revision, the button "Pay now" on the quotation
in the frond-end was display only if the sale order
was in the state `manual` and that there was not
yet any payment transaction.
The thing is, since the release of 9.0,
the `manual`state no longer exists in `sale.order`,
and the pay now button was therefore never displayed.
From this revision, the condition to display the button
is based on the `invoice_status`, which need to be `to_invoice`,
meaning there is something to pay:
- The sale.order needs to be in states `sale` or `done`
- At least one line has to be invoiced:
- If the product has the `invoice_policy` set to `order`
- or if the product has the 'invoice_policy` set to `delivery`,
and at least one quantity has been delivered.
opw-659931
Commit 7636b51 modifies the route from JSON to HTTP by mistake. Indeed,
the route /quote/accept is called from an ajax.jsonRpc request, not from
the `method="POST" t-attf-action="/quote/accept` which can be found in
website_quotation.xml.
The t-attf-action is actually only used to recover the order_id and the
token in website_quotation.js.
opw-652874
Closes#9227Fixes#9226
The fields "payment_acquirer_id" and "payment_tx_id" were not set in the quotation
when selecting a payment method in the online quote.
Inspired from function payment_transaction in addons/website_sale/controllers/main.py
opw:652733
Before this fix, it was possible to validate then cancel a quote (or the other way around) simply by using two tabs in your browser. From now on, we only validate/cancel a quote if it's the 'sent' state and advise the customer of the situation if he tries to abuse the process.
* make CSRF protection the default on all non-SAFE methods
note: there currently is no way to call a CSRF-protected endpoint
without a form-encoded entity-body as that's the only place we get the
CSRF token from.
* simple CSRF token generation: just use the HMAC'd session id, no
generating a new random token per session then HMAC it
* use constant-time equal function to avoid timing attacks
* assert that a database secret is configured before hashing/validating
the CSRF token
* opt-out database manager from CSRF: The super-admin password serves
the purpose of a CSRF token in the database manager screens.
There is no request database to obtain the
secret and generate a CSRF token.
Somehow, we forgot to change some calls to action_button_confirm the to new action_confirm on the sale.order object
This applies to the following modules:
portal_sale
website_event
website_quote
website_sale
merge *ALL* the dicts
The form rendering used to receive a dict for partner information and a dict for tx information and to transmit another dict to the qweb template; now everything is done in a single dict
- general:
- add payment.method and payment.transaction menu in invoicing
- payment.acquirer:
- add image field
- add stat button to see payment.transaction objects
- payment.transaction:
- language field is now a selection instead of a char
- rename s2s_cb_eval field in callback_eval
- form view cleaning
- on_change_partner_id now fills in the partner details
- add an ir.sequence for transaction name
- add a many2one to payment.method
- country defaults to the country of the company
- payment.method:
- add a one2many to payment.transaction
- add a stat button to see payment.transaction objects
[IMP] website_quote: rename s2s_cb_eval payment.transaction field to callback_eval
[IMP] payment_* (all providers): add image data and rename s2s_cb_eval field to callback_eval
viewport-size was add by 2254a97 (and changed by 0ea94b4) to force
wkhtmltopdf to use `col-md-*` bootstrap css classes. As this argument
change the `window` size and not the screen size, this lead to smaller
fonts and overflow issues in reports.
Only change it for reports that need it.
Closes#7882
f26b94f had as goal to filter the taxes of the product
according to the company when the sale.order
was created/edited as SUPERUSER_ID
(Who ignores the record rules).
Unfortunetaly, to filter the taxes,
it used the company of the customer,
while it's actually the company of the order which
should be used.
Indeed, for instance,
partners can be shared among all companies.
It was way less simple to access the company
of the sale.order, this parameter being
not available in the on_change method signature.
This is the easiest way to solve this issue
without breaking the API / retro-compatibility.
opw-647819
Nicolas Martinelli