Open petertgiles opened 1 month ago
@petertgiles The manager home page which would fall under /manager
is linked on the home page. Would it be removed from the home page or include something about having to log in first? It may not great to suddenly get served with the restricted.html
page for links that are feature prominently on the "public" facing site.
The manager home page which would fall under
/manager
is linked on the home page.
Hmm, good catch. @substrae and @brindasasi what are you thinking of as far as URLs for the future dashboards, including the manager dashboard? Is protecting everything under /manager not the right move?
@petertgiles I had always assumed that the URLs would work the way they do for applicants but be restricted based on the current user's role and whether they were on the network or not.
...ca/user/tool
?
To Matt's point, that manager page is a marketing page that should always remain public facing.
Using the dashboards as an example, I was expecting /dashboard
to remain the URL and the dashboard you were served would change depending on your currently selected role (i.e. if you were in your manager role, it would show the manager version of the dashboard, and if you weren't on the network it would show a permission error and prompt the user to switch to the applicant role instead)
✨ Feature
We have a batch of new manager pages coming through. Since these all need elevated privileges we'll need to make sure they're using the protected endpoint. Let's create these pages under the
/manager
path.:question: Questions
Q: Should we ask IMTD to get the F5 to block page loads under /manager as well? It would be consistent with the current setup but doesn't really improve UX or security.
Q: The current setup relies on having a different root layout for the admin site. That solution might not make sense with the new unified site layout that desfam is pursuing. Do we need to think of a new solution?
✅ Acceptance Criteria
/manager
path use the /admin/graphql endpoint🛑 Blockers