Manager Shared to Project

[CalvinFold]

[This one existed at the old community, but couldn't find it here and wanted to re-ping it...so just reposting...]

In our environment, all project managers inherit view-only access to all projects in the system by design. Our organization is simple: a small number of Group Project Managers (GPMs) and Project Managers (PMs) who report to specific GPMs.

Every so often there is a need for a PM to give their GPM Manage access to a project (instead of the inherited View access). The PMs do so without necessarily adding the GPM to a specific task.

Is there a way to generate a report for the GPM that lists projects they are specifically shared to in this manner?

Basically want to filter-out a project list to just those projects the GPM has Manage access to, but does not own.

[skyehansen]

hi @Kevin Quosig‚ , try testing this out with your users. I have a feeling they will be best able to eyeball the resulting report and confirm whether or not it is filtering correctly (this is fancy-speak for "I'm too lazy to figure out what the view column would look like, in order to validate this code")

In your filter area's textmode space:

accessRules:accessorID=$$USER.ID

accessRules:accessorID_Mod=eq

accessRules:coreAction=DELETE

accessRules:coreAction_Mod=eq

[CalvinFold]

I've found myself up to my eyeballs (again) in other urgencies, so I'll try this the first chance I get.

Any chance of an explanation here of what this filter does? Never seen accessRules before, or CoreAction.

THANKS!

[skyehansen]

Hi Kevin,

;-) really the explanation is only relevant if it works, but just so you know which direction I went in, this is an example of how to reference collections in a filter. You would be using directions and the syntax that came from this help article to follow along. https://one.workfront.com/s/article/Referencing-Collections-in-a-Report-779518987?language=en_US

You would pair this syntax with terminology out of the API explorer https://one.workfront.com/s/api-explorer . I used this terminology in a report view first to see what my options were, and then transferred those options I liked into the filter.

This was just a first pass searching for manage access, but I'd be curious about whether or not the managers are inheriting some manage permissions from the portfolio or program (and whether it would show up here). If this were the case, they'd be seeing a lot more results and some may not be relevant. At this point, I/you would have to go back and start running tests on the field I see in the API explorer called "isInherited" to see if you can use it to exclude those. Full disclosure, I wasn't seeing any inherited permissions in my results, so I ignored that field but wondered about its implications.

[CalvinFold]

Hi Skye,

So if I understand what you've done here is that you are using accessRules (didn't even know that existed...took me a while to find it in API Explorer) to pick-out projects that have a certain level of access relative to the current user?

"DELETE" didn't seem to work, but I might be able to figure out which of the coreAction values would pick-up what we need.

I'm trying to find a user or two who have the combination the filter needs to "see" and will test from there. 😄

[CalvinFold]

Skye,

Another related question: how would I make a column on a project list report that shows the coreAction or accessRules associated with a project? Might help me troubleshoot what value I need to use by examining all active projects under that lens.

[skyehansen]

yes, that's correct, a column in your view is what you would use to troubleshoot the filter syntax. Have you looked at the initial link I referred to (the help article on referencing collections)? This one is pretty good. You already found the section in the API explorer so you literally just need to plug in all the terms you found into the sample code they give you in the article. But feel free to post the code if it doesn't work on your end, and we'll take a look at it here.

[CalvinFold]

Seriously late reply, but just getting back to trying this.

I can't seem to figure out how, if possible, to get the "currently viewing user's access level" (coreAction?) into a report column to look at prior to filtering. Feel like I'm missing a step. So far:

• I've figured out Projects have accessorID and accessRule information, though neither lists as such in the API Explorer.
• accessorID is also available in the Share object, as is coreAction.
• coreAction on it's own won't display on a project report. Prefixing with Share: didn't seem to work either, so I'm not sure what the "path" is to coreAction for a project-level report.

Anybody more adept at this know how to get "currently viewing user's access level" into a project report? I'm assuming this is my first step to designing a filter that shows only projects that $$USER has a certain access to.

THANKS!

[Adding @Skye Hansen‚ since I didn't see this show-up in the daily summary updates‚Ķ]

[skyehansen]

Hi Kevin, you didn't include your failed code, so I'm not sure where you would have gone wrong.

However, I think following the link I mentioned above is still the way to go (was this where you started?).

The link gave you the general syntax which is:

valueformat=HTML

textmode=true

type=iterate

listdelimiter=<p>

displayname=Column Name

listmethod=nested(collection object name).lists

valuefield=collection object field

For your report column, the collection you reference would be accessRules

(i.e. the listmethod line should have contained "nested(accessRules).lists")

If you were using the valuefield line as a quick and dirty cheat, you could then go with valuefield=coreAction. Using this would just list out all the permission lines, which is useful for seeing what they all are, but that's about it)

Instead of the valuefield line (which is really only good at listing ONE value at a time), I would suggest a valueexpression line that knits a few values together, e.g.

valueexpression=CONCAT({accessorID}," - ",{coreAction})

But really, either should work and I just put both on a project view to test so I can see that they work in my system.

Can you share a little more of what you're doing, and the results you got?

[CalvinFold]

Hey @Skye Hansen‚, that did the trick, but I'm getting hung-up showing the NAME instead of the ID for accessorID in this case. Tried a few permutations of brackets, periods, colons and just not finding the attribute combo (this part of text mode always trips me up):

valueexpression=CONCAT({accessorID}," - ",{coreAction})

listdelimiter=<p>

listmethod=nested(accessRules).lists

valueformat=HTML

displayname=Permissions Check

textmode=true

type=iterate

Did poke-around in API explorer but found chasing-around in the share/permission objects confusing and seemingly detached from other objects? Couldn't seem to find a way to extract the name instead of the ID…but I assume it has to exist.

Thank you *SO* much for your help. Getting an education on the share/permissions structure behind-the-scenes and I'm sure audit reports for this sort of thing will come up more in the future.

[CalvinFold]

@Skye Hansen‚, Support tells me there is no way to get the user's name from the accessorID short of using IF statements plus researching the user GUID (basically a manually created lookup list).

Which kinda means this report idea died unless you have any other ideas? 😥

I'm also guessing no one but you and I are seeing this conversation based on how the new ONE system works? This doesn't go back into the summaries? Would be nice to tag this back into the public eye to see if the other textmode gurus have ideas.

I do appreciate all your time. 😁

[skyehansen]

hey Kevin,

I think you should refocus your perspective. Here's your ORIGINAL question.

"Is there a way to generate a report for the GPM that lists projects they are specifically shared to in this manner?"

They don't need this column you're trying to build.

Reminder: the reason you started building this column was to find the syntax for what the "manage" permission is called on the back end. (in fact, that's the reason I suggested this column) Once you find that syntax, you just need to plug that back into your filter that you are building. The filter is basically asking "for $$USER.ID, which projects are manage access?"

I hope that helps!

[CalvinFold]

Thanks for your input and explanation.

I needed that column to see what users have what permissions to wrap my head around what WF "sees" to see if some criteria makes sense for my report. I wanted to really look at what granularity it had to offer. But without the user names (or taking alot of time to cross reference to GUIDs), I am blind.

Going to shelve this report; it's beyond my skillset right now vs. the amount of time involved. Or maybe at some point in the future we'll buy a few hours of consulting time to shortcut this and a small list of "how the heck do I..." reporting.

THANKS for all your help. 👍

[skyehansen]

it doesn't take that much time. Create a test project and populate the sharing list with three users -- one view, one contribute, and one manage. For bonus points, use inherited permissions in a test portfolio (3 users at the portfolio level) to see if you are seeing any inherited permissions.

Cross reference those three (or 6) IDs with your three (or 6) users, but really at that point, it should be pretty clear which text goes with which permission.