Ok, I've done some more code-digging and it seems there's indeed an unmerged patch.
If you look at file-storage-views-create, the view fs_objects, then you see that fs_objects.name (which is used to construct the urls) is a coalesc of cr_items.name or cr_items.label. In 5.1 its just cr_items.name.
I've made some changes so that:
* fs_objects.name==cr_items.name==file_upload_name
* file_upload_name is removed from fs_objects (its redundant?)
* the cr_revisions.title attribute is added to fs_objects as 'label'
* folder-chunk uses the new fs_objects.label attribute as a label if it is not equal to fs_objects.name, displaying it
below the actual filename.
This way the label ('title') becomes sort of an optional one-line description for the file and in that context the 'artifact' becomes something that actually makes sense.
Do I have to open a bug for this and then submit a patch on this bug?
Another thing, when trying to dl a file from file-storage (head version) I get the following error
Too many positional parameters specified
while executing
"content::item::get_live_revision__arg_parser"
(procedure "item::get_live_revision" line 1)
invoked from within
"item::get_live_revision $item_id"
(procedure "content::init" line 44)
If I explicitly pass a revision_id in the url it goes OK (because get_live_revision is not called). It's probably something small, however, I do not fully understand the error message. I.e. get_live_revision takes exactly one parameter (item_id), it gets exactly one value (item_id), ... what's the problem? In what sense are there 'too many positional parameters'?
Can someone shed some light on that for me? Thanks in advance.
Rgds,
Jeroen
