When creating a SO with a quote template(QT), the website_description
of the QT is transfered with the lang of the partner to the field
website_description of sale.order model(in onchange_template_id on
sale.order model). But when changing the partner_id on the SO, the
lang of the new user was taken into account.
opw:697893
To have the same behavior when the variant is added manually on the SO
or when it's added with a sale.quote.template. The description on the
SO line must include the default_code and the name of the variant.
opw:725072
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
To reproduce:
- Configure an external payment provider (e.g. Ingenico) with "Authorize
& capture the amount, confirm the SO and auto-validate the invoice on
acquirer confirmation"
- Create a quotation with a product linked to a subscription
- Send the link to the customer
- Click on "Accept & Pay", use the configured provider
The SO is confirmed, but the invoice is not generated.
By calling `action_confirm` in the callback of the transaction, we
validate the SO before `form_feedback` is called. Therefore, the method
`_confirm_so` will do nothing since the SO is not in state 'draft' or
'sent' anymore.
The solution is to manually call `_confirm_so`instead of
`action_confirm`. This is necessary to do it at this moment since we
might not go through `form_feedback` (e.g. if we pay thanks to wire
transfer).
opw-694273
Steps to reproduce:
-Install website_quote
-Add a language French
-Create a quotation template
-Add a line with a new prodcut
-Translate the field description
Bug: Traceback becasue the field quote_description was not translatable.
opw:697508
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 user has access to a quote (because he is follower) but he is not
in the same company than the customer, an access error can occur on the
the rendering of the partner field.
We use the tokenized link instead, which will read the SO as a superuser
to avoid this situation.
opw-691740
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
In the frontend customer quote validation,
the company used in the sentence
```
I agree that by signing this proposal,
I accept it on the behalf of
```
was the quotation company, which is the company
which is selling, not the company/customer which is buying,
and this does not make any sense.
Instead, it should use the company of the customer
accepting the sales order, or simply the customer
if he does not have a company set.
The only case which make it a little weird is when
it's the customer himself, without parent company,
who is accepting the quote
"on the behalf of himself", but:
- This isn't possible to correct this without
breaking the translations, because the
sentence "I accept it on the behalf on"
is within the same sentence than
"I agree that by signing this proposal"
- This makes sense if another person than the
customer himself is validating the order
(the customer sent the quote link with the token
to another person).
opw-690837
The options table displays the following columns:
Product name | Description | Price
while the pricing table ommits this first column. This is quite a
good idea as products are not always accessible to portal/public
users depending on what modules are installed (notably website_sale
which introduce the published/unpublished record rule on products).
To avoid introducing an extra-sudo simply for display reasons,
this commit simply remove the product name column and harmonizes
the options display with the main pricing display.
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.
Change color #a24689 to #875A7B
Commit https://github.com/odoo/enterprise/commit/8ac1c19fac7615fecd51e670f798d13158a4e53c
changed the odoo interface violet by changing the main LESS variable
but forgot there was many direct occurences in XML/HTML/... (for
example for the mobile browser color).
Even if it's community the odoo interface violet is used at many places
(module description, XML demo data, ...).
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
mail/view controller is a generic controller that redirects the user to a
given view, depending on the record and the user. Users may be redirected
to the backend form view, or to a website view. This is done notably by
calling get_access_action method that gives the action to perform (act_window
or url).
Previously this method was called using SUPERUSER. However it was therefore
impossible to know who the user was. This method is now called using the
current user. Various overrides of get_access_action have been updated to
add some logic and access rights check directly in the method allowing
more fine-grain behavior of the access action.
Goffin Simon