Event Managers Lister

[stevejgordon]

Breakout from #1803

Include a page which will lists all authorized event users - might be a filtered view of the page from #1896

This page should allow org admins, campaign managers and event managers to see all of the users who can manage events, including their roles.

@schuback - Should event managers also be able to see this lister / add and remove other event managers? My initial impression would be that that access is limited to the level above, but perhaps a lister is still useful? Also, not sure if we should expose contact details etc in this screen to enable communication outside of allReady, such as phone numbers?

Should also include the link to the invite page for org admins and campaign managers only

[schuback]

@stevejgordon - I agree with keeping it to the upper level for adding managers. I do like the ability of managers seeing a list of other managers in their org. For sure no reveal of contact/personal information.

…

On Thu, Mar 16, 2017 at 11:06 AM, Steve Gordon ***@***.***> wrote: Breakout from #1803 <#1803> Include a page which will lists all authorized event users - might be a filtered view of the page from #1896 <#1896> This page should allow org admins and campaign managers to see all of the users who can manage events, including their roles. @schuback <https://github.com/schuback> - Should event managers also be able to see this lister / add and remove other event managers? My initial impression would be that that access is limited to the level above, but perhaps a lister is still useful? Also, not sure if we should expose contact details etc in this screen to enable communication outside of allReady, such as phone numbers? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1900>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAyqVDyeiuTOc8JmsC3haaLFf12_XfSdks5rmXohgaJpZM4MfrWR> .

-- Pascal Schuback pascal@schuback.com 206.414.8799 @schuback

[stevejgordon]

Thanks @schuback - Will update issues accordingly

[csharpfritz]

I'm investigating this issue and building out the query for the page, and want to verify exactly which credentialed users you'd like to see:

• The explicit managers for the selected event
• The campaign organizers for the campaign managing the event?
• The organization administrators?
• The site administrators?

Should a lower level administrator reviewing the list of Event Managers be able to see the upper level admins who also have access to the event?

Also: to confirm from the description, this is defined as a separate page and not a separate segment of the same /Admin/Event/Details page correct?

[stevejgordon]

@csharpfritz Sorry for the long delay here. I'm trying to get some time on the issues here.

I think we need to list all of the bullets you listed except site admins (last one). I think we can consider those implicit and not something we expose in the UI.

Based on the earlier feedback; let's allow any manager/admin level to see the whole list for now. We'll expose their name and "role" only in the initial lister.

I think a separate page for now might keep the UI less cluttered. As part of our UX review we might need to move some things about later.

If you're still up for tackling this it would be great. If you might fancy trying to schedule this as a live coding exercise at some point I'd be keen to participate with you in some way? I plan to try and do that for some issues I work on in the future.

[csharpfritz]

I like the idea of working on this for a live stream, lets confirm how we want to update the UI so that we can focus on those changes during a live stream. Jeff

…

On Tue, Jan 16, 2018 at 9:41 AM, Steve Gordon ***@***.***> wrote: @csharpfritz <https://github.com/csharpfritz> Sorry for the long delay here. I'm trying to get some time on the issues here. I think we need to list all of the bullets you listed except site admins (last one). I think we can consider those implicit and not something we expose in the UI. Based on the earlier feedback; let's allow any manager/admin level to see the whole list for now. We'll expose their name and "role" only in the initial lister. I think a separate page for now might keep the UI less cluttered. As part of our UX review we might need to move some things about later. If you're still up for tackling this it would be great. If you might fancy trying to schedule this as a live coding exercise at some point I'd be keen to participate with you in some way? I plan to try and do that for some issue I work on in the future. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1900 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAEy8exSCJv9wjdZH_E5MS5lybo3yfwnks5tLLU3gaJpZM4MfrWR> .

[stevejgordon]

Sure. I'm at NDC for the next few days and then straight into the HTbox codeathon Saturday. Perhaps we can figure out a plan of the work sometime early next week and take it from there?

[stevejgordon]

@csharpfritz Sorry for the delay...

I'm thinking what we probably want is a button on the Event details (admin) page (e.g. http://allready-d.azurewebsites.net/Admin/Event/Details/1) called "Permissions".

Clicking that would take you to a page view which lists the users with permissions and their role. Maybe all we need is something like...

We have this requirement for Campaigns also (see #1896) so as per the comments there, something reusable would be good. I've not used them much yet, but this feels like it could be a good use case for a View Component? It could take in the type (event, campaign etc) and an ID and then go fetch a list of the users and their roles.

We might would to abstract the fetching of the user list behind a service since as we go deeper into the object hierarchy we have more places to check for users. In the case of events here for example it needs to look for

1. Org Admins in the same organisation as the event
2. Campaign Managers for the parent campaign
3. Users explicitly given Event Manager access to the event in question