Since the new QWeb engine, `groups` directives on template
rendered in a route with auth=none is simply ignored, since
all is done as SUPERUSER_ID, it was impossible to instanciate
the webclient to check if the session is valid and to display
meeting info or redirect to event form view.
It seems that we don't want to fix this because routes auth=none
are rare, and special. So it is not considered as a bug.
The fix for calendar is, however, to do redirection or template
rendering server side.
show logo, merchant name, description, currency and amount on the stripe
checkout page.
Add the field stripe_image_url to display the logo that was configured according
to https://stripe.com/docs/checkout
Do not use company logo as there is no guarantee on the image ratio.
Closes#12378
If a user is disabled but in a implied_ids group, it was ignored and
so not added.
Eg: public_user is by default disabled,
So:
<record model="res.groups" id="base.group_public">
<field name="implied_ids" eval="[(4, ref('foo'))]"/>
</record>
will not add the public_user in group foo.
It is coherent with the method execute of resConfig which already use the
active_test=False.
Courtesy of @odony for review
Context in new API is not more a parameter.
Before this fix, context was interpreted has attribute parameter
and so the fields_get return empty dict.
This commit fix tracback when we try to export data in list view from
any model. The wizard try to know the fields from current model and a
traceback is raised (key error for field['string'])
l is not defined, it is line.
Bug introduced with commit odoo/odoo@5f5f8d8.
But it was never detected before because there was
no value for b2b/b2C before commit odoo/odoo@e6184aeb37
so total/subtotal in report was never print.
Before this fix, you was in an 'unknow' mode before to have selected the mode
in the sale res config after the install of sale.
Side effect:
Empty value in ecommerce
Missing column subtotal in 'sale.order' and related report
Now, with fix, mode B2B is set by default (was the only mode in old version)
Using same behavior that the method execute of class resConfigSetting.
Usability: set the default option as the first choice in the res config.
Allow to display price on the website tax included or not.
Price for product is computed with a new function display_price
which one compute an estimated price based on taxex and fiscal
position of the current partner for the current product.
Once the product is in the cart, it is the behaviour of previous commit
odoo/odoo@5f5f8d8 which is used to diplay price with or without taxes.
Allow to set in configuration mode b2b or b2c.
Change the column of order line in sale view and in reports depending of sale.
Fix price_reduce field (wrong if tax was included in price)
and merge with code discounted_price from website_sale.
Change header from reports "Price Tax Excluded' by 'Price' in report.
That is wrong, sometime the amount can haxe tax included in the price.
* Adapt code to handle position/width/padding with pixel-precision
* Adapt overlay to not overflow the screen
* Do not let the content overflow the tip when closed
Sale orders created through the website that have to be automatically
invoiced should ignore the delivery invoicing policy.
Otherwise you can end up with either an invoice not being generated at
all. This means the user has to manually generate and add the payment to
it. Even worse is if only some purchased products have invoice policy
delivery. In this case a partial invoice would be generated to which the
payment would be added, leading to a mismatch between invoice total and
payment amount.
-*- coding: utf-'8' "-*-"
is not a valid encoding. Introduced by
666387a274 I think. It was probably a
typo/replace gone bad and it got copy-pasted everywhere. Emacs complains
every time you try to save changes to files with this invalid encoding.
This changes all of them to
coding: utf-8
adhering to eae045949d.
Done with:
find . -name '*.py' -print0 |\
xargs -0 sed -ie 's/-\*- coding: utf-'"'"'8'"'"' "-\*-"/coding: utf-8/'
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
website_sale and website_quote both did their own
form_feedback. This causes issues because:
1. it would force upcoming features to have to be duplicated as well
2. there's a risk that improvements/bug fixes will only be applied to
one module, an example of this happening is
46c5f93b6c.
NB:
- The option no_delete is not working, a fix will come from chm
- The many2many widget on a sheet creation is not working correctly as
the called command is a (1, id, values) without a (4, id, _) before.
A fix will also come from chm, but a disgusting hack has been
provided for this particular case (to remove after chm fix)
Jérome Maes