feat(role based view): implemented a role based view for user groups #175

Walesango2 · 2023-10-24T13:11:11Z

Purpose

The purpose of this ticket was to implement a logic that allows us to control the user's view in the us based on user role

Linked Issues to Close

https://qmacbis.atlassian.net/browse/OY2-25702

Approach

Wrote a logic that restrict dashboard view for users without proper role and directs them to a message to go to IDM upon signing into mako and sign up.

Assorted Notes/Considerations/Learning

List any other information that you think is important... a post-merge activity, someone to notify, what you learned, etc.

hannasage · 2023-10-24T13:17:03Z

src/services/ui/src/api/useGetUser.ts

    }
  } catch (e) {
    console.log({ e });
-    return { user: null };
+    return { user: null } satisfies OneMacUser;


satisfies 😎 TypeScript boss right there!

hannasage · 2023-10-24T13:19:10Z

src/services/ui/src/components/UsaBanner/index.tsx

+        <div className="w-full  px-4 py-1 lg:px-8 text-xs mx-auto flex gap-2 items-center justify-center bg-red-200 ">
+          <p className="text-center text-base">
+            You do not have access to view the entire application.{" "}
+            <span className="text-blue-600">Please visit IDM</span> to request


This should be a link to IDM

link from correct link later.

hannasage · 2023-10-24T13:25:03Z

src/services/ui/src/pages/dashboard/index.tsx

+
+  useEffect(() => {
+    if (data?.user?.["custom:cms-roles"] === "onemac-micro-statesubmitter") {
+      return navigate("/");


I'm not sure if it's worth changing or not, but figured I'd throw a fun fact/tip in. React Router v6 has two ways to navigate! You can use the hook function, or the <Navigate /> element. The way you've done it here is the former, and if you wanted to you could also do something like this:

return data?.user?.["custom:cms-roles"] === "onemac-micro-statesubmitter" ? <Navigate to={ROUTES.HOME} /> : <OsProvider> ... </OsProvider>

Again, not sure there's a benefit of one over the other in this case, but it's a nifty tool!

hannasage · 2023-10-24T13:25:51Z

src/services/ui/src/pages/dashboard/index.tsx

+
+  useEffect(() => {
+    if (data?.user?.["custom:cms-roles"] === "onemac-micro-statesubmitter") {
+      return navigate("/");


Within the navigate() arguments, we should be using the ROUTES constant instead of string paths

Navigate is still using the hard string instead of ROUTES.HOME

hannasage · 2023-10-24T13:28:03Z

src/services/ui/src/components/Layout/index.tsx

-const getLinks = (isAuthenticated: boolean) => {
-  if (isAuthenticated) {
+const getLinks = (isAuthenticated: boolean, role?: string) => {
+  if (isAuthenticated && role !== "onemac-micro-statesubmitter") {


Are we sure this is right? State Submitters will need Dashboard access as far as I know

Thanks Keven, This is absolutely not the role we want, i was using this to test. i have a meet to mike at 10. This was what i needed is thought on regarding users. this is also causing e2e to fail because the test is looking for the dashboard to indicate the user is logged in

hannasage · 2023-10-25T13:58:02Z

src/services/auth/libs/users.json

+    "attributes": [
+      {
+        "Name": "email",
+        "Value": "[email protected]"


Bad football? This must be Sheffield United's email address 😂

hannasage · 2023-10-25T14:08:44Z

src/services/ui/src/components/UsaBanner/index.tsx


 export const UsaBanner = () => {
  const [isOpen, setIsOpen] = useState(false);
  const isDesktop = useMediaQuery("(min-width: 640px)");
+  const userContext = useUserContext();
+  const role = userContext?.user?.["custom:cms-roles"]?false:true;


Since userContext is technically returning a React State item, role would be safer with useMemo. React State is fickle in my experience, so hooks like useMemo allow us to derive values from a piece of state and update that value when the state changes. We can also simplify your later check by including the userContext?.user boolean check from line 66 in the memoized variable.

For example:

const role = userContext?.user?.["custom:cms-roles"] ? false : true; // ... { role && userContext?.user && ( ... )}

can be memoized and used as such

const hasAccess = useMemo(() => // checks both user data is present and user has cms-roles userContext?.user && !userContext?.user?.["custom:cms-roles"], [userContext] // this is the "dependency array", any React State used in memos are dependencies ) // ... { hasAccess && ( ... )}

useMemo React docs

hannasage · 2023-10-25T14:09:18Z

src/services/ui/src/components/Layout/index.tsx

@@ -83,14 +84,16 @@ const ResponsiveNav = ({ isDesktop }: ResponsiveNavProps) => {
  const [prevMediaQuery, setPrevMediaQuery] = useState(isDesktop);
  const [isOpen, setIsOpen] = useState(false);
  const { isLoading, isError, data } = useGetUser();
+  const userContext = useUserContext();
+  const role = userContext?.user?.["custom:cms-roles"]?true:false;


Also a candidate for useMemo

hannasage · 2023-10-25T14:09:40Z

src/services/ui/src/pages/dashboard/index.tsx

+
+  useEffect(() => {
+    if (data?.user?.["custom:cms-roles"] === "onemac-micro-statesubmitter") {
+      return navigate("/");


Navigate is still using the hard string instead of ROUTES.HOME

hannasage · 2023-10-25T14:12:23Z

src/services/ui/src/components/UsaBanner/index.tsx

@@ -59,6 +63,16 @@ export const UsaBanner = () => {
          </div>
        </button>
      )}
+      {role && userContext?.user  &&(


This condition is a bit confusing because at first glance it looks like a user would have a role with access but we're showing a banner communicating they don't have access. Something like { !hasAccess && ( ... )} would represent the intent a lot better. It reads more like "if they don't (!) have access (hasAccess), then render (...)"

hannasage · 2023-10-31T18:55:56Z

src/services/ui/src/pages/dashboard/Lists/spas/consts.tsx

    label: "Status",
-    cell: (data) => (props?.isCms ? data.cmsStatus : data.stateStatus),
+    cell: (data) => (props?.isCms ? data.stateStatus : data.stateStatus),


Lines 46 and 48 here are both saying "If the user is CMS, show them the stateStatus, else, show them the stateStatus". Why wouldn't we want to show them the CMS value if they're CMS?

Based on what we talked about, I think the check should be more like

(props.isCms && !props.user.[cms-roles].includes(UserRole.HELPDESK) ? cmsStatus : stateStatus

That way we still show CMS statuses to everyone at CMS except the helpdesk as the AC says

hannasage · 2023-10-31T18:56:11Z

src/services/ui/src/pages/dashboard/Lists/waivers/consts.tsx

    label: "Status",
-    cell: (data) => (props?.isCms ? data.cmsStatus : data.stateStatus),
+    cell: (data) => (props?.isCms ? data.stateStatus : data.stateStatus),


Same as above

hannasage

Code looks good!

github-actions · 2024-02-15T00:13:38Z

🎉 This PR is included in version 1.5.0-val.1 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀

Adewale Sangobiyi and others added 4 commits October 19, 2023 13:52

feat(Role based users view): configure role based user view

68542bf

feat(role based view): inplimanting a role based view for user groups

d661433

feat(role based view): inplimanting a role based view for user groups

bd6cce9

feat(Role based users view): configure role based user view

a5da740

hannasage reviewed Oct 24, 2023

View reviewed changes

Adewale Sangobiyi added 3 commits October 24, 2023 10:29

feat(Role based users view): configure role based user view

b71c930

feat(Role based users view): configure role based user view

f2c330c

feat(Role based users view): configure role based user view

4eb6b8f

hannasage reviewed Oct 25, 2023

View reviewed changes

Adewale Sangobiyi added 2 commits October 25, 2023 17:57

feat(Role based users view): configure role based user view

987f041

feat(Role based users view): configure role based user view

ff38023

hannasage reviewed Oct 31, 2023

View reviewed changes

Adewale Sangobiyi added 2 commits November 2, 2023 07:45

feat(Role based users view): configure role based user view

f191132

feat(Role based users view): configure role based user view

595f276

hannasage approved these changes Nov 2, 2023

View reviewed changes

Walesango2 merged commit fa0ac18 into master Nov 2, 2023

Walesango2 deleted the user branch November 2, 2023 19:03

github-actions bot added the released on @val label Feb 15, 2024

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

feat(role based view): implemented a role based view for user groups #175

feat(role based view): implemented a role based view for user groups #175

Walesango2 commented Oct 24, 2023

hannasage Oct 24, 2023

hannasage Oct 24, 2023

Walesango2 Oct 24, 2023

hannasage Oct 24, 2023

hannasage Oct 24, 2023

hannasage Oct 25, 2023

hannasage Oct 24, 2023

Walesango2 Oct 24, 2023

hannasage Oct 25, 2023

hannasage Oct 25, 2023 •

edited

Loading

hannasage Oct 25, 2023

hannasage Oct 25, 2023

hannasage Oct 25, 2023

hannasage Oct 25, 2023 •

edited

Loading

hannasage Oct 31, 2023

hannasage Nov 1, 2023

hannasage Oct 31, 2023

hannasage left a comment

github-actions bot commented Feb 15, 2024

feat(role based view): implemented a role based view for user groups #175

feat(role based view): implemented a role based view for user groups #175

Conversation

Walesango2 commented Oct 24, 2023

Purpose

Linked Issues to Close

Approach

Assorted Notes/Considerations/Learning

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

hannasage Oct 25, 2023 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

hannasage Oct 25, 2023 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

hannasage left a comment

Choose a reason for hiding this comment

github-actions bot commented Feb 15, 2024

hannasage Oct 25, 2023 •

edited

Loading

hannasage Oct 25, 2023 •

edited

Loading