Attachment functionality review

[GoogleCodeExporter]

The attachment functionality needs to be reviewed, since it has the following 
issues : 

-- Attachment type -- an attachment type field is required to identify an 
attachment by type (e.g. 'main', 'annex', 'image' ... )

-- Attachment edit -- There is no user access provided to "edit / replace 
attachments". Ideally a link should be provided to "edit" attachments from the 
main item form (be it a bill, question or motion) - when the main item is in 
edit mode. Secondly there should be a clear visual indicator that an attachment 
can be edited -- See the link below for a proposed way to do this :

http://docs.google.com/document/pub?id=1mFg-5oHN8Q4662IdnnW7XgLyYf1-Co3Knb0AgMMI
kKs

-- Attachment workflow -- Either editing an attachment -- or adding a new 
attachment should generate a new version of the main content item that the 
attachment is associated with.  This is because -- e.g. in the case of the bill 
-- the attachment document is the main content of the item (the content item 
itself defines metadata).

Original issue reported on code.google.com by ashok.ha...@gmail.com on 24 Jun 2010 at 9:01

[GoogleCodeExporter]

Also required is a 'delete attachment' functionality -- that deletes the 
attachment

Original comment by ashok.ha...@gmail.com on 24 Jun 2010 at 11:19

[GoogleCodeExporter]

Original comment by flavio.z...@gmail.com on 29 Jun 2010 at 9:15

• Added labels: Milestone-beta

[GoogleCodeExporter]

Update -- this part of the issue -- 

"-- Attachment workflow -- Either editing an attachment -- or adding a new 
attachment should generate a new version of the main content item that the 
attachment is associated with.  This is because -- e.g. in the case of the bill 
-- the attachment document is the main content of the item (the content item 
itself defines metadata)."

is NOT required.

Original comment by ashok.ha...@gmail.com on 28 Jul 2010 at 8:54

[GoogleCodeExporter]

An optimization that maybe desirable -- 

Currently when a content item is versioned -- any associated attachment objects 
are also versioned -- whether they have changed or not. This leads to data 
volume growth and duplication of the same attachment in the attachment versions 
table. An optimization here should be done to version the attachment only when 
the attachment changes (rather than every-time when the parent content item 
changes) 

Original comment by ashok.ha...@gmail.com on 28 Jul 2010 at 8:57

[GoogleCodeExporter]

Note :

following are the links to the current schema definition, domain configuration 
and descriptor config for the current attached files type and functionality :

http://code.google.com/p/bungeni-portal/source/browse/bungeni.main/trunk/bungeni
/models/schema.py#660

http://code.google.com/p/bungeni-portal/source/browse/bungeni.main/trunk/bungeni
/models/domain.py#444

http://code.google.com/p/bungeni-portal/source/browse/bungeni.main/trunk/bungeni
/ui/descriptor.py#1224

Original comment by ashok.ha...@gmail.com on 6 Aug 2010 at 6:22

[GoogleCodeExporter]

Currently the attachments are stored as "blobs" in the postgres db.

This is not desirable in the long run, as with data growth backing up restoring 
a db with blob content attachments can be problematic and slow.

An alternative solution is to store attachments in either a separate db or on 
the file system.

Also to consider indexing of attachments - in view of the Xapian bungeni search

Original comment by ashok.ha...@gmail.com on 30 Sep 2010 at 7:18

[GoogleCodeExporter]

Updated summary of the Issue :

-- Attachment type -- an attachment type field is required to identify an 
attachment by type (e.g. 'main', 'annex', 'image' ... )

-- Attachment edit -- There is no user access provided to "edit / replace 
attachments". Ideally a link should be provided to "edit" attachments from the 
main item form (be it a bill, question or motion) - when the main item is in 
edit mode. Secondly there should be a clear visual indicator that an attachment 
can be edited -- See the link below for a proposed way to do this :

http://docs.google.com/document/pub?id=1mFg-5oHN8Q4662IdnnW7XgLyYf1-Co3Knb0AgMMI
kKs

-- Currently when a content item containing an attachment is versioned -- any 
associated attachment objects are also versioned -- whether they have changed 
or not. This leads to data volume growth and duplication of the same attachment 
in the attachment versions table. An optimization here should be done to 
version the attachment only when the attachment changes (rather than every-time 
when the parent content item changes). So the attachment object needs to be 
version aware.

-- Optimization of blob storage or moving into the file system 

Original comment by ashok.ha...@gmail.com on 30 Sep 2010 at 7:21

[GoogleCodeExporter]

Changed owner to sterch.net

Original comment by ashok.ha...@gmail.com on 12 Jan 2011 at 8:01

[GoogleCodeExporter]

Original comment by ashok.ha...@gmail.com on 28 Nov 2011 at 6:06

• Changed state: Closed