Reports for admins, who can run/edit/delete reports.

Xavier Ona shared this idea 3 years ago
Idea Logged

Something that has come up in our environment some times is a question regarding who has access to what.


Admins within Client Orgs usually want to know who has access to reports, for example, if the admin wants to know what reports can be seen by a user, or who can run or edit a report.


Is there an easy way to accomplish this?

Best Answer
photo

Hi Xavier,


I have spoken to the devs on this, and we all agree that this sort of information would be useful for 'super admins'.

However we believe rather than put the info on the user profile, we should have a bunch of reports that can be imported and run to display different info.


A support task has been created #225010 for the creation of these reports.

At the moment, the report/s are noted to return;


-Content owned by user, including private.

-Users & groups they are members of.

-Orgs and which users have access.

-Orgs and what content is specific to that org.

-Security applied to user via role functions.

-Security applied to content categories, and who has access to those categories.

-Reports/Views/Dashboards by security level, grouped by user.

E.g. User B can 'read these reports', 'edit these reports', 'delete these reports'

Same deal with dashboards.


Unfortunately, we have yet to allocate this task, or have a plan when it can be implemented so I cannot actually provide an ETA.

If I'm missing a requirement, or have any further questions on this, please let me know.


Much thanks for the feedback!


Regards,

David

Comments (4)

photo
2

Hi Xavier,

Thanks for the question!


Unfortunately there isn't an easy way to accomplish what you are after currently. With that being said, I do think you have a good idea here. It would be nice to be able to click on a user and receive some feedback concerning what Yellowfin content that user has access to or, in the case of a report, click the information tab and see who has access to a particular report.


Although not exactly what you are after, as an alternative, you can use Yellowfin audit reports (downloaded from our marketplace here) to create reports showing who has accessed a report in the past as seen below (note--this does not show who currently CAN access a report):


b4fc715880c35879a567cc2fb1cdd4d9


Anyway, I do think you have a pretty good idea here, so I'm going to convert this question into an idea for our product development team to review. As soon as I have some feedback, I will be sure to pass it on.


Please feel free to let us know if you have any questions or concerns!


Kind Regards,

Dustin

photo
1

Thanks Dustin, very useful. I have implemented the Audit reports in our Stage environment and will do it soon in our Production environment, I'm sure our admin users will be happy with the new reports and any other that helps them keep track of their reports and permissions associated with them.


Best,

Xavier

photo
1

Nice Xavier,


I'm glad to hear that audit reports tidbit helped. I wasn't sure if you were already aware of them or not. They are pretty useful!


Kind Regards,


Dustin


Kind Regards,


Dustin

photo
1

Hi Xavier,


I have spoken to the devs on this, and we all agree that this sort of information would be useful for 'super admins'.

However we believe rather than put the info on the user profile, we should have a bunch of reports that can be imported and run to display different info.


A support task has been created #225010 for the creation of these reports.

At the moment, the report/s are noted to return;


-Content owned by user, including private.

-Users & groups they are members of.

-Orgs and which users have access.

-Orgs and what content is specific to that org.

-Security applied to user via role functions.

-Security applied to content categories, and who has access to those categories.

-Reports/Views/Dashboards by security level, grouped by user.

E.g. User B can 'read these reports', 'edit these reports', 'delete these reports'

Same deal with dashboards.


Unfortunately, we have yet to allocate this task, or have a plan when it can be implemented so I cannot actually provide an ETA.

If I'm missing a requirement, or have any further questions on this, please let me know.


Much thanks for the feedback!


Regards,

David