TeamDesk Knowledge Base & Support

Home

FAQ

Forum

Idea Exchange

Ask a Question

My Stuff

Help

Attachment's permanent link

Currently we have two options to get an attachment file - "public" or "private" and couple of options that control the behavior.

You can set the number of file revisions to keep in attachment column. If the number of revisions to keep is greater than 1 and if "Allow Revision History" is checked, we also render "Revisions" button to display the list of revisions stored in database.

In "private" mode the attachment is addressed via column, record and optionally the revision. The revision parameter is in effect only if "Allow Revision History" is checked, otherwise latest revision is always returned regardless of the revision requested.

In "public" mode the attachment is addressed via unique identifier associated with particular file revision. If even if you store single revision and file changes, unique idenitifer also changes rendering the link inaccessible.

This might be good from one point of view and bad from the other.

Public links are extremely useful for notifications sent to arbitrary email addresses. The recipients typically do not have an access to an application. E-Mail notification serves as a snapshot of the data, and the attachment link sent with notification also a part of this snapshot. If we change a record and the file in it, we may want not to send a notification to an email address - with new identifier we effectively invalidate the link preventing an access to file - as recipients specified by email addresses are not application users they are not subject for record access validation and invalidating the link is the only way to prevent them from accessing file's data.

Yet, if you do not need file access restrictions but changing the file constantly, invalid links may simply annoy your customers.

So, the idea is to bring "private" and "public" access logic somewhat in par.

In private mode the revision is ignored when you have "Allow See Revisions" unchecked.

In public mode we want to update the logic to leave file's unique identifier unchanged when you have single revision to store and "Allow See Revisions" unchecked - making the link to a file permanent regardless of the changes made to a file.

This change may relax security level of your application, though to bring security level back all you would need to do is to check "Allow See Revisions" for public-access-enabled columns.

We would be glad to hear your opinions, pro and con.

ID
471

Category
Customization

Author

Kirill Bondar Staff

Date Created
11/21/2011 9:04:43 AM

Date Updated
12/2/2011 4:24:26 PM

Status
New Idea

Score
40

Promoted By

	John INFOHUB I		gerardo garcia		Michael Ver Duin
	Kirill Bondar Staff

Comments

	Michael Ver Duin 11/21/2011 10:44:56 AM I'm excited by the idea of a link option that allows access for anyone with the link.
	Kirill Bondar Staff 11/21/2011 10:51:38 AM Michael, Public access to attachments is already implemented. Here is another question: should the link invalidate itself when new file is uploaded or not (or under what conditions?)
	Michael Ver Duin 11/21/2011 11:11:37 AM I use document uploads only from my customer to me. Once uploaded I don't want them changed. I've never thought about posting a document and sharing it out... I suppose though it would be nice to have four options with every uploaded file: 1. Download 2. Delete 3. Replace with new file. (uses old link, and deletes old file) 4. New version of this file. (creates new link.)
	Philipp Matuschka (MMB) 11/21/2011 12:40:10 PM Not an important issue to me. There are far higher priorities in my humble opinion.
	gerardo garcia 12/2/2011 4:24:26 PM Thanks for the post Kirill! We are about to document processes in our company. For process diagrams we will use an OSSAD based software and teamdesk as the database of procedures, instructions, manuals, brochures, etc related to the process. Database will also give follow-up to the changes and updates on every procedure. Process diagrams will relate to documents stored in teamdesk via link. But if that link changes whenever that file is updated, we would have to go into the process diagram and update all related links which would render it impossible to manage. Sending the users to the record form would mean many open windows and many additional steps that would result in distraction. We can do this today with box.net but If we had this functionality in teamdesk we could close box.net and use that budget to upgrade teamdesk to enterprise.

Feedback

Back to Search Results