Skuid File__c object sharing rights when File__c needs to be set to Private in OWD

  • 1
  • Problem
  • Updated 2 years ago
  • In Progress
Interesting dilemma. The File_c which is used for attaching files at the field level needs some additional functionality to manage who sees what.

The issue is that the object doesn't inheret any sharing rights as it's the record being referenced as a lookup. There really really needs to be some additional considerations to manage this when using this object. Any solution I think of is quite a bit of a hack. Updates to sharing of any kind wouldn't stay in sync with the File__c record.

Really stumped on this one.

Photo of mB Pat Vachon

mB Pat Vachon, Champion

  • 42,714 Points 20k badge 2x thumb

Posted 2 years ago

  • 1
Photo of Skuidward Tentacles (Raymond)

Skuidward Tentacles (Raymond), Champion

  • 17,224 Points 10k badge 2x thumb
so.... You made a custom object File__c and you attach files to it and then reference it from multiple objects?

If I am understanding you correctly, I think the best/fastest solutions would to be to do one or the other:

A) make several of these file__c objects and make each a child of the parent that will be referencing it. You und up with multiple repositories, but each one will follow the permissions of its parent.

Or
B) have a junction object. I haven't fully thought this through, but if you create a junction object, it seems that you could create a snazzy way to create a FileJunction__c record that is a child of the parent object and then create the File__c record as a lookup of FileJunction__c. I think this gets you a quasi many-to-many relationship with inherited sharing that you are looking for, but I haven't thought very much about it, so if it doesn't work don't Skuidshame me! If it does work, then you only eat up one master-child relationship on each object which would be to that objects FileJunction__c object. You would still have a single repository for files in File__c. Each object would need its own junction, though, for you to get inherited sharing.
(Edited)
Photo of mB Pat Vachon

mB Pat Vachon, Champion

  • 42,714 Points 20k badge 2x thumb
Sorry. My mistake. skuid__Image__c is the object that I should be referencing.
Photo of Skuidward Tentacles (Raymond)

Skuidward Tentacles (Raymond), Champion

  • 17,224 Points 10k badge 2x thumb
In either case, the junction object may work. Instead of linking skuid__image__c to a contact, you could link it to Contact_File_Junction__c and make Contact_File_Junction__c a child of Contacts. Then you would have a "gate" between the the contact and the file that would inherit the permissions of the Contact.
Photo of mB Pat Vachon

mB Pat Vachon, Champion

  • 42,714 Points 20k badge 2x thumb
That's my issue. I want to continue using the Skuid field renderer for File Upload as is.
Photo of Skuidward Tentacles (Raymond)

Skuidward Tentacles (Raymond), Champion

  • 17,224 Points 10k badge 2x thumb
I guess what I am thinking is that now you are using that field on the Contact object. Instead, have the contact object open a pop up that creates a new junction record child of that contact. Then have the junction record have the Skuid field for file upload. A bit convoluted, but it may be the easiest way for you to get your sharing model worked out.
Photo of Skuidward Tentacles (Raymond)

Skuidward Tentacles (Raymond), Champion

  • 17,224 Points 10k badge 2x thumb
I edited my response above. I meant A or B not A and B.