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
Indeed unlinking wizard content before actually closing it seems to
cause a crash. Instead of unlinking lines with user - password data
we now write a void value on the new password. The stored content
does not contain valuable data after submitting the form.
bzr revid: tde@openerp.com-20140304115017-posdyri9y1cra4jo
Local URLs are converted into absolute URLs, notably because when using the
email designer, images are added using local URLs. Previously to this fix
the template was analyzed to find local URLs and make them absolute.
However this causes 2 issues :
- mako-based URLs are broken because a scheme is added before the mako that
generated the image src
- when changing the base url, the templates are not updated
The URLs are now converted dynamically when generating the content of the
html. This is done by passing a new parameter that enable the post processing
of the generated content.
Also fixed double body generation when using templates; fields parameter
was not propagated correctly.
bzr revid: tde@openerp.com-20140304112957-l9b10gyjqphs5fgc
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
When delete a record, correctly display the number of remaining items displayed (eg: 1-79 of 99)
When no more items in a page, force switch to previous page
When no more pager, reload the content to display potential items in next page
bzr revid: mat@openerp.com-20140303164114-pzeuu9hxvq17lx02
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
Fixed the implementation of the sorting for inherited
columns, many2one columns, and aggregated columns.
Added corresponding tests with increased coverage of
the read_group() method.
bzr revid: odo@openerp.com-20140228173320-p8l0jc8op7xsgn1x
In some cases the authentication check can fail
for an unknown reason (e.g. connection pool is
temporarily full). This should not be treated
as an authentication failure, as the status is
really unknown. Let those exceptions bubble up
instead.
bzr revid: odo@openerp.com-20140228170712-l8smq6u3cmvjtd5e
When mulitple cron workers get their list of jobs to process at the same time,
some jobs might be executed multiple times. We fix this by keeping the listing
filter when taking the lock.
bzr revid: al@openerp.com-20140228161524-y8nyq5uw9yq9rcc3
Richard Mathot (OpenERP)