search

18F / dol-whd-14c

The 14(c) system will become a modern, digital-first service. Applicants will be provided an intuitive online experience, guiding them through the information needed to complete their application correctly.
Other
16 stars 17 forks source link

As a Certificate Administrator, I would like the ability to toggle between the role of an applicant and the role of an Admin. #142

Open EStriegel opened 7 years ago

mgwalker commented 7 years ago

Can you say more about what things an applicant can see/do that an admin cannot? This is an interesting user story and I'm curious to know more!

binwang89 commented 7 years ago

@mgwalker I am currently the admin role in 14c, I can see all the existing applications but i can not create an new application.

mgwalker commented 7 years ago

Should an admin be able to create a new application?

binwang89 commented 7 years ago

based on the RoleFeature excel file from 14c phase 1, - Yes.

EStriegel commented 7 years ago

The intended function for this user story is so the certification team can enter paper applications received via mail into the 14c system. The mechanics for how this is done still need to be fleshed out.

From: binwang89 [mailto:notifications@github.com] Sent: Monday, July 10, 2017 11:22 AM To: 18F/dol-whd-14c Cc: Striegel, Elizabeth R - WHD; Author Subject: Re: [18F/dol-whd-14c] As a System Administrator, I would like the ability to toggle between the role of an applicant and the role of an Admin. (#142)

based on the RoleFeature excel file from 14c phase 1, - Yes.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHubhttps://github.com/18F/dol-whd-14c/issues/142#issuecomment-314139782, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ASl-g-mcrP4_wwQRkuTI5puj3AbUEnroks5sMkGjgaJpZM4MYTzA.

mmurthydol commented 7 years ago

This story requires some thought from an implementation perspective:

In my understanding, the ask is: while I am logged in as a System Admin, I would like to be able to submit an application on some employer's behalf as well.

Proposed alternatives: 1) If so, what prevents us from logging out, create an employer Id, EIN & all, and submit the application as an employer ourselves? The proposed step would be a more secure way so we won't accidentally mix up application of one employer with someone else. Need to think issues related to email address (allow email address to be non-unique in security logic - should be ok I think...)

2) If we allow a "System Administartor" to "spoof" a particular applicant as this story is likely to evolve, I believe we will run in to potential data security issues, "spoofing" implementation isn't going to be straight forward, will also need spec/work for Ux pages/workflow to allow this to happen. In short, let's discuss option (1) versus (2) from a business perspective. From IT perspective (1) is recommended/preferred option.

mgwalker commented 7 years ago

Option (1) makes my eyes pop because it's impersonation and I think there may be legal issues. (Mainly around creating an account on their behalf without their consent, not the "impersonation" part.) I think there's also a security concern with creating accounts for ghosts. For me, the risk of error isn't high enough to be a concern, but of course it's up to WHD to decide how much risk to accept. 🙂

My guess is that the risk of getting the EIN wrong is roughly the same no matter how the application is entered into the system. Maybe a good mitigation could be something like a confirmation before the application is saved? I.e., "This is the EIN you entered, please be sure it's correct!"

FWIW, from a purely development perspective, this shouldn't be a difficult story to implement. As a first iteration, it could simply be the same form that employers use, but there'd be one extra step at the beginning where the admin inputs the EIN.

mmurthydol commented 7 years ago

We can check on the legal issues. With option (1) you are only electronically entering paper data. You are not creating an account using user's email address - so not sure what the security implication is from your perspective. Application would note cert team filled out the application.

It's true with option (2) & your proposal, spoofing is not needed. You are allowing data to be entered for employer by allowing as you say additional EIN field. However when entering data for multiple employers in the same session, would like to think through data entry error implications. In a way these error can happen to some extent with option (1) as well.

Likely we'll end up with your suggestion anyways :)

mgwalker commented 7 years ago

I guess I don't understand what you mean in option 1, then! 😄 It wouldn't be the first time I was confused.

mmurthydol commented 7 years ago

You are good Greg! When we discuss the stories we can go in to it a little bit. The tradeoff seems to be enforcing a process for cert team member per employer vs. just making it easier for them to enter data (as well as errors).

I suspect we will go with option 2 as suggested by you when we discuss this with business :)