Functions can take an attachment as an input parameter and then work with the attachment. TypeScript & Python functions have documentation on how to achieve this, but compute modules do not list attachments as one of their input types.
A compute-module-backed function can take a string as an input parameter, and an attachment RID can be passed to that parameter, but how the function should load the attachment is not clear. Should the function use the authHeader field on the job context? Or the tempCredsAuthToken? If the latter, how should the function interact with the mentioned (but not documented) data sidecar?
And, most importantly, is this even possible?
According to the compute module function mode permissions documentation, a compute-module-backed function can either have no access to Foundry resources, or service-user permissions to Foundry resources. In the case of an attachment that is not yet associated with an object (which a service user could be configured to access), how would a compute module get access to that attachment?
Cheers
Paul
Hi @pwest-northslope, I would recommend using service-user permissions for this use case. On the configure tab of your compute module, you can select to use “application permissions”, at which point you can either provide an existing client ID or have the compute module generate one for you. You can ensure that client ID has access to the attachement(s) in question by sharing access with that client ID.
Then in your compute module code, you can use the oauth helper function to generate an auth token with the configured client ID/secret for your compute module. Based on these docs, it seems you’ll need at least the api:ontologies-read scope to call this endpoint.
@skruyswyk how would the client ID get read permissions for those attachments?
The attachments are uploaded by the user from a front-end when they are fed into an action. The action reads from and writes to zero object types, so object permissions do not apply. The attachment exists as a free-floating resource which does not appear to be subject to any externally-controllable permissions scheme to which the service user could be a party.