In some rare cases database records have negative IDs,
so the slug URL could look like /foo--20. This could
be mistaken for a slug ending with a `-` and a positive ID.
The latter is not supposed to happned as final hyphens
are stripped by slugify, but has been used in the past
and may be used in old links.
A squashed merge is required as the conversion of the apiculture branch from
bzr to git was not correctly done. The git history contains irrelevant blobs
and commits. This branch brings a lot of changes and fixes, too many to list
exhaustively.
- New orm api, objects are now used instead of ids
- Environements to encapsulates cr uid context while maintaining backward compatibility
- Field compute attribute is a new object oriented way to define function fields
- Shared browse record cache
- New onchange protocol
- Optional copy flag on fields
- Documentation update
- Dead code cleanup
- Lots of fixes
Need to find which controller add ?page= instead of &page= because google find some url with '?page=1?page=2' --> page = '1?page=2'. According to google, the referrer is the old website.
The website module normally tries to render user-friendly
error pages for any error occurring during the processing
of a website-enabled request.
This happens even for werkzeug's HTTPExceptions that have
their own response, because we want the website layout to
be applied on top of the error page.
One special sort of HTTPException should be preserved
without rewriting: the manually-crafted ones generated
with abort(), and usually wrapping a redirect response,
which bears no alteration.
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.
Olivier Dony