How are sys_attachment entries created through Catalog Variables related to a Parent Request Item?

[tahnalos]

We have discovered that any time we have a catalog variable of Type attachment, any attachment attached to that variable is sent to sys_attachment table with the table_name of ZZ_YYsc_cart_item after the Request Item is submitted.  This attachment is not visible to non-admin users, and thus anyone trying to open this attachment from the parent Request Item gets a read error.

To get around the limitation for non-admin users, we modified the ACL to make those attachments readable when the table_name is ZZ_YYsc_cart_item.  While this solves the access issue, it was pointed out that this gives blanket access to all attachments saved to catalog variables.  Thus the client's security team is asking if there is a way to limit access based on the information on the attachment entry.  Unfortunately, none of the sys_ids present on the table_sys_id field on the sys_attachment form matches with any entry on either the sc_req_item or sc_task form. 

Does anyone have an idea how this sys_attachment entry is linked to the parent request item?

Thanks

[Mani A]

can you explain little bit more of your use case clearly

[tahnalos]

We have a catalog variables that are used in Multi Row Variable Sets.  For some reason this is defaulting its storage to ZZ_YYsc_cart_item.

Typically, when you store an attachment to a variable, it stores it in either ZZ_YYsc_req_item or ZZ_YY_sc_task.  But because we are using a multi row variable set, it seems to store in ZZ_YYsc_cart_item.

Your scripts concentrate on moving the attachments from one area to the parent Request item or SC_task.  Let me ask you this: how do you isolate the sys_id to get to the parent record?  Because I'm not seeing it in your script, and the table_sys_id is NOT correct.  Trust me, I've tried to look.

[Brad Bowman]

It seems like your environment has customized rules around the use of the attachment variable.  Out of the box attachment variables cannot be added to a MRVS

Maybe by design there is no tie back to the parent record because this isn't a supported use case.

Attachments added via a Catalog Item variable first appear in the sys_attachment table with the Table name ZZ_YYsc_cart_item until the request is submitted, then the Table name changes to ZZ_YYsc_req_item and the Table sys ID is updated to that of the RITM.  You can try to track down the Business Rule and likely Script Include that is doing that and find out why it's not doing the same when using the variable inside a MRVS.  There is likely a reason attachment variables are disallowed in MRVS, but maybe you can make it work, or just accept that they will remain on the ZZ_YYsc_cart_item Table name. 

Since no other attachments use/stay on this Table name you could have a Business Rule run after insert on the sc_req_item table.  The script would do a GlideRecord on the sys_attachment table for any records with the ZZ_YYsc_cart_item Table name,... and update it and/or the Table sys ID from the current.sys_id if that's what you're looking for.

[tahnalos]

Someone did manage to add an attachment to a Multi-Row Variable set in our system.  I don't know how they managed to set it up (it was before I got involved in this environment), but the business requirement is that they want to be able to add an unknown number of attachments to this particular catalog item.  If you're saying that the ZZ_YYsc_cart_item being in the attachments table is a defect, then yes, that's something that I can take back to the business and let them know.  As far as I know, most implementations usually have a maximum number of attachments that they use per request, and they define the number of attachments as part of their requirements.  It just so happens that this particular client says they don't really know how many attachments they will need, and that it ranges from 2 to possibly 20.

The funny thing here is that these attachments are visible in the MRVS from the parent record with certain modifications to the ACLs.  Don't know how this is actually working but as it stands it fits their requirements, its just that they want to ensure that access to these attachments are limited to those who are actually working on them.

Thanks and I will take this back to our client.