Redmine

Eric Davis wrote:

I asked Terence Mill to mention the backend storage ideas after talking with him on IRC. It might end up being an separate set of features but still might help this discussion.

As part of the storage idea: if it is SCM backed, that might even let someone git clone or svn checkout the "files" from Redmine. There would be a lot of work to get that working but it would be interesting (e.g. what happens when a client commits, is it a read-only scm...)

Eric Davis

Hmm..if a client commits either new files are created in scm or an existing file is updated to a new version. In both cases no existing links (e.g. in a ticket, a wiki-site) will be harmed, cause the links point to the version before. The cool thing about linking in redmine is, that linking to special versions of a file in scm is already possible:

Repository files
source:some/file -- Link to the file located at /some/file in the project's repository
source:some/file@52 -- Link to the file's revision 52
source:some/file#L120 -- Link to line 120 of the file
source:some/file@52#L120 -- Link to line 120 of the file's revision 52
export:some/file -- Force the download of the file 

If you use that link key as general key, you already have you unique reference for tickets and wiki pages.
Moreover the rights managment to access files in per project scm for docs and files can be reused as already working for redmine+advanced svn integration+webdav. A problem with this approach is, that reusing file&docs overall project, would mean overall repo's. But that can be done in redmine.pm script for advanced svn access via webdav.

Of course you could also take the approach using one repo for complete redmine(all projects) docs and files, but then you must establish rights managment per project, per directory for one central repo (there are already features requests and discussion for this approach beyond this context on going). Here you could reuse std. rights managment of the scm.

Terence Mill wrote:

Eric Davis wrote:

I asked Terence Mill to mention the backend storage ideas after talking with him on IRC. It might end up being an separate set of features but still might help this discussion.

As part of the storage idea: if it is SCM backed, that might even let someone git clone or svn checkout the "files" from Redmine. There would be a lot of work to get that working but it would be interesting (e.g. what happens when a client commits, is it a read-only scm...)

Eric Davis

Hmm..if a client commits either new files are created in scm or an existing file is updated to a new version. In both cases no existing links (e.g. in a ticket, a wiki-site) will be harmed, cause the links point to the version before. The cool thing about linking in redmine is, that linking to special versions of a file in scm is already possible:

[...]

If you use that link key as general key, you already have you unique reference for tickets and wiki pages.
Moreover the rights managment to access files in per project scm for docs and files can be reused as already working for redmine+advanced svn integration+webdav. A problem with this approach is, that reusing file&docs overall project, would mean overall repo's. But that can be done in redmine.pm script for advanced svn access via webdav.

Of course you could also take the approach using one repo for complete redmine(all projects) docs and files, but then you must establish rights managment per project, per directory for one central repo (there are already features requests and discussion for this approach beyond this context on going). Here you could reuse std. rights managment of the scm.

Nice to mention is this thread that there is alreasy a poc for deeper webdav integration as plugin available PluginWebDav.
Till now its "only" missing the versioning access via webdav.

1. plugin is using REDMINE permissions (:view_files, :manage_files, :view_documents and :manage_documents) to grant access to files and folders/documents
2. plugin allows you all files operations (create, delete, rename, move and copy)
3. plugin allows you to create documents (just create a folder inside documents folder) but version creation is not allowed
4. plugin allows repository access through WEBDAV (Read/Write for subversion and filesystem SCM if repositories are on the redmine server, Read only for all others SCM supported in REDMINE)
5. folder names used (ie: files/documents/subversion in the example) can be changed through per project settings

Terence Mill wrote:

Nice to mention is this thread that there is alreasy a poc for deeper webdav integration as plugin available PluginWebDav.
Till now its "only" missing the versioning access via webdav.

1. plugin is using REDMINE permissions (:view_files, :manage_files, :view_documents and :manage_documents) to grant access to files and folders/documents
2. plugin allows you all files operations (create, delete, rename, move and copy)
3. plugin allows you to create documents (just create a folder inside documents folder) but version creation is not allowed
4. plugin allows repository access through WEBDAV (Read/Write for subversion and filesystem SCM if repositories are on the redmine server, Read only for all others SCM supported in REDMINE)
5. folder names used (ie: files/documents/subversion in the example) can be changed through per project settings

the main disadvantage of the plugin in my opinion is that it requires Apache. It is the same problem if we will use external SCM to keep versions of files/documents. Ideally Redmine should not require any specific third party (ie Apache, git, Subversion etc) software to manage files.

Ideally Redmine should not require any specific third party (ie Apache, git, Subversion etc) software to manage files.

Why do you think it is idealy to rinvent the wheel?
I would share your opinion that installation of redmine and setup shall stay as simple as possible. You need a Web Server/Servlet Conatiner in any case, so if not apache which else shall be used.
Maybe the webdav solution is possible without having specific binding to apache but also support for other servers.
Furthermore thet is no need to have an "external" scm, like you say. You can include svn/or library into redmine installation process as standard fpr docs & files repository. Implementing an own file versioning does skip the discussion what scm shall be used, but won't make the whole solution better zhis way. I think redmine is a great software and already brings well known and settled tools and components from software lifecylce together, and shall keep focusing into filling the gap between this toolchain and the lack of features, but not reinventing solutions for problems where are already settled solutions juts in the the "redmine way" Thre are some good exmaples in the core (scm, eclipse,..etc) or in plugins (hudson, chat), which show how to make a bridge to existing software and reusing it.
From my point of view there is enough todo, but not doing an own file versioning concept form scartch, only while loosing some compatbility. Apache is "the Web-Server" and is open source wnd will live a while longer, however i would be the who likes to see redmine can run on asy many plattforms as possible. Maybe thte is a way reusing settles compoents/software but also keeping the compatibility to many plattforms like now.

Terence Mill wrote:

Ideally Redmine should not require any specific third party (ie Apache, git, Subversion etc) software to manage files.

Why do you think it is idealy to rinvent the wheel?
I would share your opinion that installation of redmine and setup shall stay as simple as possible. You need a Web Server/Servlet Conatiner in any case, so if not apache which else shall be used.
Maybe the webdav solution is possible without having specific binding to apache but also support for other servers.
Furthermore thet is no need to have an "external" scm, like you say. You can include svn/or library into redmine installation process as standard fpr docs & files repository. Implementing an own file versioning does skip the discussion what scm shall be used, but won't make the whole solution better zhis way. I think redmine is a great software and already brings well known and settled tools and components from software lifecylce together, and shall keep focusing into filling the gap between this toolchain and the lack of features, but not reinventing solutions for problems where are already settled solutions juts in the the "redmine way" Thre are some good exmaples in the core (scm, eclipse,..etc) or in plugins (hudson, chat), which show how to make a bridge to existing software and reusing it.
From my point of view there is enough todo, but not doing an own file versioning concept form scartch, only while loosing some compatbility. Apache is "the Web-Server" and is open source wnd will live a while longer, however i would be the who likes to see redmine can run on asy many plattforms as possible. Maybe thte is a way reusing settles compoents/software but also keeping the compatibility to many plattforms like now.

I'm not suggesting to reinvent the wheel. What I'm saying is that Redmine is currently fairly agnostic in terms of third party software ie you can run it with Webric, Apapche, Montgrel etc and use whatever SCM you desire. And I believe that we should keep core that way. We can make document versioning as a plugin which requires Apache and SVN installed and it would be just fine with me but we should not make core dependent on 10000 different software packages which will make it nightmare to install therefore limit adoption.

Agreed, we shouldn't add such a dependency, installation is already complicated enough for lambda users. It should be an optional feature or a plugin in my opinion.

+1 - great to see this being discussed!

should note it was brought up here too, for reference - http://www.redmine.org/issues/3995

First - I love the idea of a single file management tool across Redmine!

Since the term "media" is already being used, I might suggest that we can learn from other apps that manage media, specifically music or photos.

Some require you to first upload the media, tag / categorize / describe / caption it, then separately link it to the other content - for us, an issue or a wiki page. Ideally (to me) I would want to do this from the issue or wiki page from a work flow viewpoint.

I might suggest that a first phase would NOT deal with versioning, allowing the feature to at least merge the basic management functions while keeping versionality in mind. This alone would be a substantial improvement in a wonderful tool! A future version could then add versioning support.

Shane,

I think the system you propose is important because the very limited support that Redmine gives for files & documents management (and SCM). I am agree with almost all the suggestions the community has provided. In my opinion the key points are:

• Manage all the files from a single module.
• Create, rename, delete and edit (online would be wonderful) files using the WebDav protocol.
• Management of several versions of the same file (which could share the same metadata).
• Allow multiple references to the same file (from wiki, issues, notices).
• Sort files by type and category (I make an observation below).

I just add a couple of features:

Although the organization of files over the type and category fields (database approach) may be useful, organize files into subdirectories (filesystem approach) could bring some advantages.

Also would be important some mechanism to specify which artifacts (files, documents, code, test) belong to which release (e.g. SRS_1.0, DB_2.3, SDD_1.4 CODE_1.1 TEST_1.0 relate to the release 1.0). A matrix view may be appropriate for this.

I am a programmer but I know nothing about Ruby on Rails framework. But I still like to collaborate in the implementation of this feature, after all Redmine is the tool I use to manage my projects.

Jose

I forgot, it is also important to include a field indicating the status of the file needed to define the baseline in the work of SCM ;)

I wonder, when did Redmine users have this feature?

So what is the status on this project? Are folks still working on it?

Not right now. Personally got buried in another OS task. I might pick is back up if Eric lets me know that there is Dev willpower behind it.

It looks like a very exciting development, for sure. I may be able to mobilize some funding for core development of said feature.

Why don't you ping eric (@edavis10) and I (@justlikeair) on twitter and lets talk out what you have in mind.

I would hold off, it is still at an early stage of possibility. There are several options we are looking at.

I have not read all the discussion, but here is just what I would like to have.

• A central place where all files/documents appear
• One file can have multiple versions… maybe even with the possibilty to mark some versions as obsolete or with other costumisable flags
• Creating a description for a document
• Give per Role/Group/User permission
• Access through WebDAV, FTP or even more
• Organizing through folders
• Dependecies to Tasks/Tickets and Wiki-Pages that also appear there
• Files uploaded with a Ticket or a Wiki-Page are found in the same pool
• Moving files to folders keeps links
• Filter files by task/wiki-page/mime-typ/author and so on

+1

A new document management system would be great :)

+1 NICE!
We need it!

lovely idea. Ok, here are my thoughts:

Version:
I'm not keen on having file versions in the media page, the reason being that Redmine already has 'versions' and I'd quite like to see a certain consistency used for terminology. I'd also like to have the 'project version' (ie the ones you see in the roadmap) being associated with uploaded media files.
That said, keeping past uploads of the same filename available is a good thing, but this history needs to use different terminology (revisions, file-history, or even file-version)

Types:
good that tere will be 1 place for all kinds of 'uploaded stuff', images, documents, pdfs, etc etc etc. I'd also like to see it used for links as well. I would prefer to store my documents (for example) in the SCM that I already use, and then use Redmine as a front-end to direct users to them. I do not want to have to store the same file in my scm and upload it to Redmine as well. This approach would also make sense for links to external tools, or even links to the web. Once in Redmine, they can then be referenced easily by the other parts of Redmine.

'Global' files:
ie ones that are uploaded to a ticket should show up in the 'media list'. I'm not sure I like this proposal, but its certainly a good thing to have. Obviously, there needs to be a filter to show the 'originator' of the uploaded file, so I can see all files if I want, but in day-to-day use, I will only see those files that have been explicitly uploaded to the media list. Alternatively, group files together by their 'originator' - so all uploads from tickets are grouped together (and collapsed by default - I doubt anyone wants to se a big list of screenshots and log file attachments).

Auto-Upload: I like this one a lot, cURL uploads would be great! Then my build server can automatically upload the latest version without any manual interaction from me.

Far, I entitled you all again. After my extended presence in the forum is not, I could not find the watchword to your old profile and started a changed one. I'm pleased as punch that I am again with you.

I'm a big fan of everything discussed in this thread, and I can't help thinking the DMSF project is moving in directions very similar to this. Are there reasons why the DMSF project can't be merged into Redmine canon? It would be fantastic to know such a helpful add-on would no longer be broken with every new Redmine point release.

Hi,
what is the state of this discussion? I'd love to see this.

There's already DMSF, it's quite similar and actively developed. Combining efforts by merging DMSF into core would be great though...