Our internal users have run into many cases where, within the context of a Release, they want to know the name of the folder and the folder's parents, but are unable to get it.
There is a `release` object available, from which the folder ID could be determined by segmenting the release ID. But from there the release must have a "Run as..." user with sufficient access to use the folderApi to query each of the folder IDs in the chain.
It seems reasonable for the `release` object itself to simply have direct access to the folder that it is contained within. Something like:
release.getFolder()
which would return a Folder object with at least the basic information like folder name. And from there preferably the Folder object itself will also have knowledge of its parent:
folder.getParentFolder()
so the full folder chain could be determined easily, without the need for API interactions.
by: Peter G. | about a year ago | Templates & Releases
Comments
In the 23.1 (May 2023) version, we are releasing support for folder object attributes: getCurrentFolder().title, getCurrentFolder().id, and getCurrentFolder().name.
At this point we do not provide explicit support for accessing the parent object of the current folder, other than through the API.
Could you explain the use case for how users would use it if it was available?
Also, we would like to find out why 'Run as user' within the template cannot be used?
The concern that was brought up with "Run as user" is that a release can be running as a user that does not have access to all the levels of folders under which the release is running. Additionally, it would require that we ensure that there are users that globally have access to view all folders, which goes against our security policy of least access.
The concern is that a release may be running under a folder path: "business_unit1/sub_folder". It sounds like the 23.1.x release will allow the release to access "sub_folder" without issue, but would need to use the API to access the "busines_unit1" folder. If the "Run as user" only has access to "sub_folder" but not "business_unit1", then it still would not be possible to get the name of the "business_unit1" folder.
I believe I have proven out that this is possible by setting the "business_unit1" folder to only allow my username to see it, and then the "sub_folder" to anyone can see it. As another user, the "sub_folder" cannot be seen in the main Folders listing, because the "business_unit1" folder is not visible. But a direct link to "sub_folder" allows any user to see the contents of it.
Once you have obtained the complete folder path, can you please explain how you intend to utilize it?
Retrieving the name of the folder(s) along the path to the Release is then utilized to determine what business unit/org/department/team within our company the release belongs to, and thus would receive tickets or notifications about the status of the Release. This is needed because we have generic Templates that are used company wide (i.e.: 10 templates that generate 3000+ releases in a day across 50+ business units), and it needs to be determined who would receive tickets that are opened for the release.
Please let me know whether our understanding is correct:
You would use user emails in the Notification task, which are resolved from the parent folder name.
How do you currently keep and maintain the mapping of the folder to the team members/email addresses?
No, internally we would be opening ServiceNow or JIRA tickets, but need to know who to direct those tickets to based on the parent folder name.
There is some lookup table that is used for that purpose, though I am not familiar with the contents of it.
Hello,
I vote for this idea because it is true that it is a shame not to have the complete path of a release, because we could also use this data to generate metrics.
I will go even further by also asking to have the path information for the templates.
Today, we can obtain the information by making N API calls ("N" corresponding to the depth of our template/release tree) to obtain the complete path.
Regards,
Jeremy
We're planning to introduce this feature in the upcoming 24.3 (Fuji) release.