search

keirbowden / sigcapapp

Signature Capture Samples
MIT License
9 stars 5 forks source link

Site Guest Users Permissions #32

Open chrisparkernz opened 2 years ago

chrisparkernz commented 2 years ago

Hi there, the component looks great and works well inside Salesforce, however when I attempt to use this with a Site Guest User they receive an error that they don't have update permission on the parent object (which they don't). Is there any way to work around this?

chrisparkernz commented 2 years ago

I've looked into this some more and don't think it is possible from the apex when invoked by the Site Guest User. A work around I can think of though would be if the code was updated to not create a record attachment if the RecordId input variable was left blank. Then it would be possible to query the created Content Doc and create the link to a record with system context in the flow. Alternatively with a bit more work if the ContentDocId was returned to the flow it would be even easier.

keirbowden commented 2 years ago

Hello,

You are correct that this is not possible with the Site Guest User, at least not in an App Exchange package. It would need to execute the Apex in 'without sharing' mode to bypass the permission checks, but that would lead to a security review failure.

Allowing the component to create an 'orphaned' content document is a possibility, and I think it's straightforward to make the ID available to a flow.

I've tagged this as an Feature Request and I'll take a look when I have some time to work on this - might be a few weeks as I maintain this in my spare time and I'm currently putting together a Dreamforce talk.

CloverWillis commented 2 months ago

Seconding the ability to create orphaned ContentDocuments. This guest user limitation is something that I could work around if only I was able to just get the file somewhere on the org at all. Having that option I believe could take minimal effort to implement and potentially open up this app to a number of other use cases.

keirbowden commented 2 months ago

@CloverWillis @chrisparkernz - thanks for the feedback.

The association with a record is something that is fundamental to the component and the code behind it, so to break the connection entirely would entail quite a bit of work.

What I believe could work is an additional flag to indicate that the created file should be orphaned - i.e. skip the step where the captured image is associated with the record.

This would come with a couple of caveats:

  1. It would only work with Files, as the Parent field on Attachment is mandatory
  2. You'd lose the ability to update an existing file (i.e. add a new ContentVersion to an existing ContentDocument) as this is determined by existing ContentDocumentLinks referencing the parent
  3. The component would still require a valid record id, so it would have to be present on a Lightning Record page, or receive a hardcoded record id as a parameter.

Can you let me know if those caveats would be acceptable for your intended use?

Thanks