Nodes may have attached files, and possibility of changing them via comments is a very useful feature.
| Comment | File | Size | Author |
|---|---|---|---|
| #4 | 2010-03-05_filefield[unix].patch | 2.64 KB | arhak |
Nodes may have attached files, and possibility of changing them via comments is a very useful feature.
| Comment | File | Size | Author |
|---|---|---|---|
| #4 | 2010-03-05_filefield[unix].patch | 2.64 KB | arhak |
Comments
Comment #1
sinasalek commented@arhak :
Comment #2
arhak commented+1 subscribing
Comment #3
sinasalek commentedMy first idea : I don't think that timestamp is important , the combination of file path (in case of using FileField Path or similar modules)/filename/fid seems/description enough to me. Unless we can justify a usage for filesize and timestamp for users.
I'm not familiar with filefield module code , but according to the modules i used so far, it's pretty much extensible. So module may extend it and add more fields, and i think comment_driven should be able to consider this new fields as well.
Comment #4
arhak commentedthis is the first approach, it takes into account everything (to be compatible with modules extending functionality)
- fid
- list
- data (array in depth, where description goes)
- uid
- filename
- filepath
- filemime
- filesize
- status
- timestamp
- (an anything another module might add)
needs to be tested with:
- description, and other data that might be associated to the file
- filefield_paths
- file_aliases?
Note that leaving a file untouched but changing its "list" flag is (currently) considered a change and the diff is rendered as the file being removed/added as it is actually rendered by filefield upon "list" flag changes
Comment #5
arhak commentedcommitted to HEAD
Comment #6
arhak commentedshould no longer apply for unstable5