Has anyone come up with a way to redirect CLM attachments from the database to a file share?
Historically our teams have used attachments heavily. To avoid over burdening the db we would like to redirect the attachments to a file share and link them to artifacts in CLM. We would like to make this as transparent to users as possible by trapping the attachments and redirecting them before they get in the db.
Anyone tried anything like this?
Anyone tried anything like this?
2 answers
this is not possible with the out of the box code. I wrote some product modifications year before last to handle this however. see enhancement 153049
this has a server side component too. the virtual share name associated with the shared folder.
as u can imagine the drive letter (on windows) might be different on every system. this allows the Eclipse
(and web) code to find the right file.
you just use the normal attachment interface, and the code handles it.
I did this because we had large attachments (>250 meg) which cannot be stored in the DB by default (limit set at 50 meg). AND its nearly impossible to delete the darned things from the DB. (and we had a hard requirement for security reasons to certify that all case data was erased after a certain time).
there was one problem I had not solved. when attaching a new file to a workitem from the web, it is no longer possible to tell the actual REAL filename.. so the underlying code could not properly map for web attached files. (the darned virus makers and hackers have ruined making things easy for the rest of us).
I had to modify product source code to make this work. I think less than 150 lines of code total.
and it worked on unix and Windows. (create an attachment on windows, open in *ix, and vice versa)
the prototype client code was posted to that enhancement.
this still stored something in the database. RTC thinks the 'file' is there, but the file contents are changed to the virtual url of the file. I would have used the file reference object, but it was missing a field to use to store the URL, and required significant scope recompile to add the field.
--- edit
you can do it with the out of the box support by using 'related artifact' links, but
1. you cannot navigate to the file in the RTC UI for related artifacts, you have to cut/paste the file URL into the entry field.
2. you cannot prevent a user from using the wrong interface
(I had 5,000 users to support, and figured the phone would ring off the wall with the OOtB capabilities)
I didn't try my code with dropbox, or google drive as a target filesystem. it needs a drive letter on Windows.
this has a server side component too. the virtual share name associated with the shared folder.
as u can imagine the drive letter (on windows) might be different on every system. this allows the Eclipse
(and web) code to find the right file.
you just use the normal attachment interface, and the code handles it.
I did this because we had large attachments (>250 meg) which cannot be stored in the DB by default (limit set at 50 meg). AND its nearly impossible to delete the darned things from the DB. (and we had a hard requirement for security reasons to certify that all case data was erased after a certain time).
there was one problem I had not solved. when attaching a new file to a workitem from the web, it is no longer possible to tell the actual REAL filename.. so the underlying code could not properly map for web attached files. (the darned virus makers and hackers have ruined making things easy for the rest of us).
I had to modify product source code to make this work. I think less than 150 lines of code total.
and it worked on unix and Windows. (create an attachment on windows, open in *ix, and vice versa)
the prototype client code was posted to that enhancement.
this still stored something in the database. RTC thinks the 'file' is there, but the file contents are changed to the virtual url of the file. I would have used the file reference object, but it was missing a field to use to store the URL, and required significant scope recompile to add the field.
--- edit
you can do it with the out of the box support by using 'related artifact' links, but
1. you cannot navigate to the file in the RTC UI for related artifacts, you have to cut/paste the file URL into the entry field.
2. you cannot prevent a user from using the wrong interface
(I had 5,000 users to support, and figured the phone would ring off the wall with the OOtB capabilities)
I didn't try my code with dropbox, or google drive as a target filesystem. it needs a drive letter on Windows.
