Attachments Page Layout

Here’s something I created that will be going on my company’s blog. Skips the need to create a detail page for an attachment.

One key thing that Pat’s video did not mention that may mess people up.  After you have defined the child relationship in the attachments model.  You have to drag that child attachments Icon down into your table in order to get the right kind of template.   If you simply create a template field from the table itself,  or drag a template component into the table from the component list,  your template will not be in the context of the child object.   You can still get the data merges to work against the child records,  but it is more complicated.  

See this tutorial for a step by step instruction on adding child relationship data to Field Editors and Tables.  The tutorial is about Field Editors, but the concepts are exactly the same for Tables. 

Pat has provided one idea. Bypass the attachment detail page alltogether and just show the attachment. (Any valuable metadata about the attachment could be surfaced to an object detail page - in a table showing all the attachments for the object)

But if you do NEED to have an Skuidified attachment detail page - you can still create one. You just won’t be able to use traditional override methods to let your users get to it.

You will need to create an attachment table on your detail record. And instead of including the standard Attachment Name or Attachment ID field - that link to the Standard Layout Attachment Detail page, you will need to add a template field to the table, and use syntax like this:

<a href="/apex/skuid__ui?page=YourSkuidPageName&id={{{Id}}}>{{{Name}}}

• Replace “YourSkuidPageName” with the name of your attachment detail page.
• Make sure the Id and Name fields are in your attachment model.

This link will take you directly to your skuid page.

Thanks guys but I am not either method would work. The problem is that there is a HUGE security hole in Communities. Since Notes and Attachments take on the security controls of the parent object, if a community user has access to an object, even if you remove all their rights to all fields on the object, they can still access the notes and attachments associated with it. Yep, ALL notes and attachments related to those objects as there is zero security on these child documents. The exception is making a file private whereby only admins and file owners have access. This hole is exposed when using the global search on the standard SF communities page. If they have access to say “Services” and Services has Notes and Attachments, they can see any related data and there is NO way to prevent this. For instance, we have a service 2551786 that has multiple files on it, one happens to be Contract.pdf. On the layout, the client can only see 3 fields on the SERVICE and they don’t see the notes and attachments section because it is not in their page layout. But if they search in the global search field for “Contract” the file and any file for that matter with the word Contract is displayed in the search results. AND they can open the Attachment Record AND they can see the file. SF acknowledges this is somewhat problematic; ya think! I was hoping that if we could at least control the UI of the attachment using SKUID, we could remove the actual link and ONLY display something like the description and/or created date or even a template field, like “NO ACCESS”. This certainly does not stop an educated SF admin from getting to the file in the url, but is at least better than what they have now.

Yup…  I don’t think we are going to have an answer at this point.  We cannot change a number of realities:  
1. That attachments show in the search results of global search.  
2. That attachments cannot be overriden with a VF page (so that the layout can be more completely controlled).  




 

I have been searching for a way to do this for awhile now and everything I was trying was failing. For some reason this post just came up for me today… must’ve changed my terms. It solved a major issue for us and will seriously speed up the time my team spends getting files out of SalesForce. Thanks Pat and Rob!!