How are CFDE portal users associated with a DCC's dashboard?

[lliming]

As part of Epic 1, we need to enable CFDE portal users to "go to the CFDE portal and see a personalized dashboard interface where I can verify the data currently available for my DCC." The user story doesn't specify how an individual portal user is associated with one or more DCCs. We need to decide how that's supposed to work given the mechanisms currently available in the portal.

At present, the portal has a login mechanism that identifies the individual, and it has access to the individual's group memberships in Globus's groups service. It does not have any other persistent profile mechanism. In other words, there's currently no way to store user preferences from one login session to another.

Q1: Are we all OK with any portal user being able to see the "personalized dashboard interface" for any DCC? In other words, we don't care who sees the personalized dashboard interface for each DCC?

If the answer to Q1 is "yes," then it isn't actually personalized at all: it's something every portal user can do. Q2: Is there any reason we can't simply add a navigation link or interface that leads to the dashboards for each DCC?

If the answer to Q1 is "no," then some form of approval/authorization is required. Q3: Is it acceptable for the request & approval to be out-of-band, i.e., not handled in the portal interface, but via some other mechanism?

For this issue to be resolved, we need answers to Q1 and either Q2 or Q3, depending on the answer to Q1.

[ACharbonneau]

In the long term the answer to Q1 will have to be no. For the short term, it might be able to be yes. For the data we have now, I think the only one that might require a no is MoTrPAC, since their data is (or at least was) under embargo. I can check with them to see whether their data needs to be hidden from non-MoTrPAC people.

[lliming]

I'm assuming we're focusing on the short term, in which the answer might be yes with the possible exception of MoTrPAC.

That leads to Q2: Is there any reason we can't simply add a nav link or interface that leads to dashboards for each DCC?

Here's a related question: Even if we don't need to know user identities to give them the right user experience (nav links, etc.), might we perhaps want to restrict access to the DCC dashboards to users who have logged in? I can think of several benefits that might provide, including getting DCC personnel into the habit of logging in...?

[lliming]

In regard to MoTrPAC, do you think they would be amenable to having their dashboard visible to members of a group? The portal user would have to login and belong to a specific group ("MoTrPAC DCC Dashboard Access") in order to have access to the MoTrPAC dashboard? We could manage the group for them or even show them how to do it, though regrettably they would need to use a different web app to manage the group.

[ACharbonneau]

My gut reaction to Q2 is that a nav link per DCC is that it would be fine from a technical standpoint, but that I'm a little worried about it from a user navigation/usability standpoint. Having lots of links on the home page to different views is super confusing and makes it hard to get the right users pointed at their preferred view.

If we made it restricted access, and then the first option after logging in was picking a DCC, that could be a good interim option without adding a bunch of links to the homepage.

[ACharbonneau]

FYI, I contacted MoTrPAC this morning to check on their data release expectations.

[karlcz]

I think the dashboard UX will need feature to choose a scope. I am not sure if it is as simple as a list of static nav targets, or more like a dropdown/selector to filter on a single DCC view, several DCCs, or all CFDE content? I suggest that we are discussing whether/how there can be some authn-based default behavior to configure that UX element for an initial visit for different kinds of user, and where does that authn-based behavior get prioritized in a deliverable schedule.

[owhite]

Lee,

"Q1: Are we all OK with any portal user being able to see the "personalized dashboard interface" for any DCC? In other words, we don't care who sees the personalized dashboard interface for each DCC?"

In response to Q1, my suggestion is we tie one user, to getting data from one DCC. The idea here is they should be someone that is designated to look at data that has been staged, meaning loaded but not yet public, into the catalog. There is not a need for that designate to see results from other DCCs.

In response to Q3, yes, request and approval does not need to be handled in the portal interface.

[karlcz]

For the case of looking at submitted data which is not yet released, I think that corresponds to a step in the ingest flow where the staged data is in a separate catalog produced by the ingest process. The UX needs to be parametric to view this set of statistics or content instead of the main public catalog. This catalog could also quite easily have different access control settings if we wanted to restrict access.

But by nature, I think each DCC submission would be in its own sandboxed catalog at this stage, so there is really a UX/navigation question around getting the user to the relevant "current" submission and/or browsing other submitted versions if they are in a busy phase of interaction with the ingest pipeline?

[lliming]

The user story in this epic doesn’t say anything about reviewing new data. It says the user needs to review the data that’s in the portal now.

We have another planning statement in draft stage for the process of curating additions (updates or additions) to the data in the portal. It’s the “Self-service data ingest for DCCs” statement. I recommend this epic focus on reviewing data that‘s already in the portal, because the alternative is a bigger problem with more moving pieces. (Scope creep, ocean boiling.)

The original question is still open, I think: exactly how will portal users get to the personalized dashboards for their DCC?

I‘m only asking because I want to know if access control is required. If access control isn’t required, then it’s a UI issue, not a security issue, and I don’t have to worry about it. (But the UI team does.)

[karlcz]

It would seems silly to me for us to have an access restriction on statistical summaries for metadata content that is already visible to others in the production catalog.

If/when we have policies to hide content, these policies should apply coherently to all views which represent said content. It would not be a special feature of this DCC-focused view that it have different access controls than other summary views.

Also, I think it may be misleading to describe it as the "DCC's dashboard" as in the issue title and in many conversations. This possessive phrasing presumes some kind of ownership and probably implies (unspecified) control or confidentiality to many people.

So, I would instead think of this as just another instance of the CFDE-wide summary views, where the scope has been narrowed to exclude other DCCs. From that perspective, I definitely think it is a UX defaults and/or navigation task and not an access control task to route some users to different views such as this DCC-focused summary report.

[lliming]

For the time being, the answer I'm taking away from this discussion is:

1) We will handle "registration" (DCCs telling us who their authorized reviewers are) as an offline/out-of-band process. I.e., likely email from the DCC PI. We'll take the info they give us and set things up so it "just works" when an authorized individual logs in. See https://app.zenhub.com/workspaces/cfde-roadmap-board-5f2050f40fc09500139ce760/issues/nih-cfde/training-and-engagement/176 for the issue to make this happen. 2) The most likely implementation seems to be creating a group for each DCC's reviewers. Group membership signifies that one is authorized to view the DCC's reviewable data.