Changes in website's ir_http#_handle_exception():
- exception is mandatory, can't be None anymore
- we don't touch non website_enabled requests
- we don't touch explicits plain responses from parent
- logic flow is now easier to read (I hope so)
Change in website's ir_http#_dispatch():
- In case of real 404, instead of returning self._handle_exception(),
just let parent do the job (so we call super())
In t-field, datetime fields (formatted and not formatted versions) are
converted to the context/user's timezone (through
fields.datetime.context_timestamp) when displayed, but were saved without
converting back so the next display would go forward (or back) of the user's
tzoffset.
Fix that by applying context_timestamp's conversion backwards, from the
context/user's timezone back to UTC, before saving the field's value.
If website is installed but not used/enabled for the current controller,
overridden methods like _get_converters will *still run* for the controller's
dispatch.
This means a ModelConverter used in a controller with website installed but
not enabled will use website.models.ir_http.ModelConverter, not
base.ir.ir_http.ModelConverter, and base's args postprocessing will *not* be
able to convert the placeholder object to a real UID, only website's
postprocessing can do so.
And as far as I can see there's no reason to skip the URL building validation
either, only the multilang stuff relies on and requires that the controller be
website enabled (and in fact that it be multilang enabled), so only *that*
should be gated behind a flag.
Also always call super(), there's no reason not to and others might add args
to postprocess on base rather than website, ending up after website in the
MRO.
We always want to escape quotes (") as part of the process of
generating HTML output. This option (quote=True) turned into
an implicit flag with a DeprecationWarning in werkzeug 0.9.0
It is likely to disappear in a future release of werkzeug too.
A wrapper avoids this warning without loss of compatibility
handle_exception() is supposed to try handling an exception and if it cannot,
re-raise it. Overridden methods must therefore call super() within a try/except
block, and only attempt to handle the exception if super() raised.
1st issue:
When an exception was raised, it was badly handled by the website in case of
website_enabled key. The response page was generated without calling super.
The WebRequest object being responsible to rollback the transaction in case
of errors.
2sd issue:
The _failed attribute is required to rollback the transaction in an WebRequest
object. Previously it was only set in the JsonRequest object (which inherit
from WebRequest), replace by call to super. The attribute _failed is now set
in the WebRequest object.
- allow fiscal position change on sale orders
- public user on website
- simplify website_sale sale.order and shopping cart code
- remove preprocess_request
bzr revid: al@openerp.com-20140507153223-q73u5lhyrfw98o3a
Didn't quite work right: on the layout, it would exponentially increase
leading spaces in text nodes. Combined with a bug injecting snippets marks in
the footer (and thus invalidating and re-saving the layout at each snippet
addition) this could blow up the layout template and rendered page to >20MB.
Just keep lxml's standard 2-spaces indent.
LXML is unable to pretty print the layout anyway.
bzr revid: xmo@openerp.com-20140321075419-9w88h232r928xv5f
There is a deduplication in ir.attachment, but it's only for FS-stored content
*and* it only deduplicates storage not models (as there are access rights
issues involved).
The goal here is to always return the same attachment when a user uploads the
exact same image multiple times (because it's simpler or whatever).
Initially tried to use a binary field & digest(), but search() blows up
because it tries to utf-8 encode raw binary data. So use char & hexdigest
instead.
_compute_checksum returns None if the provided attachment data does not look
like a website image attachment.
Unhandled: multiple existing matches, maybe a UNIQUE constraint on the
checksum field would be a good idea just in case.
cherrypicked from saas-3's xmo@openerp.com-20140303153855-5f2l8v0jq2mgb26f
which had to be backed out (as the patch adds a new stored field)
bzr revid: xmo@openerp.com-20140304133117-r88p9zl2tc9tsh75
Attachments ought be removed only if they are not used in an existing page/web
view.
Theoretically this could be set directly in unlink(), but:
* that would make a nice error message significantly harder
* the expenses of performing a text search in all view archs would be a bit expensive
Notes:
* the views set could be reduced to only "web" views
* the search is likely sensible to false negatives e.g. different order of
query parameters. It *will* remove images still being used.
bzr revid: xmo@openerp.com-20140304110716-u14w6uo8fbkfa42i
There is a deduplication in ir.attachment, but it's only for FS-stored content
*and* it only deduplicates storage not models (as there are access rights
issues involved).
The goal here is to always return the same attachment when a user uploads the
exact same image multiple times (because it's simpler or whatever).
Initially tried to use a binary field & digest(), but search() blows up
because it tries to utf-8 encode raw binary data. So use char & hexdigest
instead.
_compute_checksum returns None if the provided attachment data does not look
like a website image attachment.
Unhandled: multiple existing matches, maybe a UNIQUE constraint on the
checksum field would be a good idea just in case.
bzr revid: xmo@openerp.com-20140303153855-5f2l8v0jq2mgb26f
Fabien Meghazi
Christophe Matthieu
Christophe Simonis
Franck Bret
Xavier Morel
Olivier Dony
Denis Ledoux
Richard Mathot
--global
Martin Trigaux
Christophe Simonis
Fabien Pinckaers
Antony Lesuisse
chm@openerp.com
Simon Lejeune
Christophe Simonis