Currently, sending a mentor application isn't in the correct object, the "other_info" value is being registered in a new empty key, the "job_help", "industry_knowledge", and "pair_programming" are being sent as false even though I checked them to be true on the application, and the "tech_stack" key is empty, although I checked off every available option. Submitting a filled out application gives a 400 error and states that the "commitment must be a boolean type, but the final value was: \"yes\"."}.

@ryan-hamblin We are currently need of setting global state with current user profile information upon login. This information will be needed for many of the components throughout the application. We likely need to created a BE endpoint that responds with the current users profile_id(from DS) and role upon receiving a request with the user_id(from Auth0) in the body.

After introducing the Mentee/Mentor Matching Modal in the Matching component, a bug was noted where the modal itself jumps off the screen when opened except at one specific screen size, coupled with some visual bugs within the modal itself.

It was noted in our Product Review that this might have something to do with media queries that were implemented for the memo modal, which may be the first place to look.

Issue located at: src/components/pages/TicketsDashboard/TicketsDashboard.js

Upon logging into the application and navigating to /dashboard the protected dashboard route allows us to access and render the dashboard successfully, but none of the data belonging in the table in this view renders.

Logging the axios call's response in this component shows us that we are actually receiving the data successfully, but the if statement inside the .then method is stopping us from rendering it out. This if statement needs to be removed.

The pending applications page requires a new filter that allows the admin user to filter only applications that have been rejected. Currently there is no way to view these applications.

After reviewing several files for the Auth0 cleanup it became apparent that many of the redux files that exist currently are very unnecessary and add to confusion about the codebase. When I think about what needs to be saved to a global state, the biggest item I can think of is the user profile after they've been logged in. There appears to be a lot of duplication (similarly named slices of state that seem to have the same function) and cases where slices of state don't need to be global in the first place (the lifecycle slice that is being set in several places in the code but never used / consumed).

I propose a ticket to clean up the redux files that are not necessary (seemingly everything except for currentUser or userProfile, whichever is preferred)

Currently when trying to submit an application to become either a mentor or a mentee you see the form's error message always being rendered at the bottom of the screen, and find that clicking the submit button doesn't seem to do anything.

Looking deeper, at the browser console's network tab, you'll find that the requests to post that form data to the BE (And further to DS) are in fact not going through. In the console you'll see an error message stating that axios__WEBPACK_IMPORTED_MODULE_0___default(...)(...).post is not a function:

This is due to improper use of axios in the mentor and mentee action files in our Redux ecosystem, seen in the following screenshots.

Mentor:

Mentee:

Correcting these instances of axios().post to axios.post and resolving the BE ticket for this feature allows us to officially post applications through our application to the DS API, which means we can deliver this one feature to Jason and maybe collect some actual data from the UD community! 🔥

Open the app and the console and notice that there is a warning of a method being deprecated by the ReactRouter team in the near future.

The fix here will be trivial. But we should get compliant.

The Design Manager requested that the usability be fixed according to the specifications in this trello card:

Trello: As a user the UI features on the sidebar and nav bar are attractive and easy to find
https://trello.com/c/uUKuzW1H

Add an exit door icon to the Log Out menu item in the account options menu from the nav bar dropdown
Make sure there are icons for all of the menu items from Nav Bar dropdowns.

Accessibility: Make an invisible label on the rightmost div of the Nav Bar with the value "account settings" to make it easy to identify as an element used to reach Log Out to screen readers.

Change the memo link in Nav Bar to an AntD button with an icon.

Remove memo from the sidebar.

When looking at either the mentee or mentor role application forms, if you scroll to the bottom you'll find the error message We're sorry! Something went wrong. Please re-apply and try again later. being constantly displayed.

Take a look at the application form components at components/pages/RoleApply/Applications, find the source of this bug, and squash it! 🐛

The current readme file has a lot of Bob Ross placeholder text in it and could probably stand to have that text changed to be relevant to the project.

As of right now, there are no tickets for an Admin to be able to see mentees and match with a mentor. This is the most important aspect of being able to match users together. The matching dashboard is trying to get from the assignments endpoint but needs to be getting the mentees that need to be matched.

As per the Stakeholder's request @nathancai97 went ahead and implemented some work for UnderDog Devs FE. This issue is set up to capture that work that was done via Jira.

@paulstgermain will you please help ensure that @nathancai97 's work is accounted for via Jira?

@ryan-hamblin re: login/apply/logout buttons displaying on Navbar.

Navbar has some faulty logic around the display of our login/apply/logout buttons. As it stands, even a logged-in user will see the login and apply buttons momentarily while a page is loading. This is happening because the display logic is based on Auth0's isAuthenticated variable, which somehow always defaults to false initially and then switches to true of the user is logged in (is that how it's supposed to work?). This may also be related to the network requests which are firing with undefined tokens.

We can easily fix the display issue by using Auth0's isLoading variable in the display logic. Effectively, it won't check to see which buttons to display until isAuthenticated as been confirmed and set appropriately to true or false.

This ticket is approved by @ryan-hamblin.

As was laid out in the loom video below, there are two separate (but related issues) to bundle together here.

Research what the root of the issues are by following the steps outlined below:

• Reproduce the bug yourself and document the steps it takes to reproduce the issue.

• Truly understand the root of the problem. Don't assume anything. I have only assumptions about why these things are broken right now. I'd need to dig in further to find out what the cause is.

• Fix the issue the way you know how.

• Test the fix.

Auth0 breaks the non-auth landing page when user lands on it.
User unable to navigate back to the landing if not logged in.

Loom video link here

Recommended story points: 5

DS has deployed a breaking change that will require a small rewrite to the FE and possibly BE code. The graph endpoint will now return both the graph object and a paragraph description. Previously it was just returning the graph object. This form provides the unique ability for DS to not only customize the graph based on user interaction, but also reflect those choices in the paragraph, automagically.

{
  'graph': <Altair.Chart>,
  'description': <string>
}

Issue stemming from src>dashboard>dashboard.js lines 72-92, commit here.

This code makes a call to /resource-tickets, and then looks through all the data that is returned and attempts to refactor it. The issue stems from line 91 'dateSubmitted: t.created_at.substring(0, 10),'. dateSubmitted is not a key that is returned from /resource-tickets and thus, an attempt to .substring() null is made.

In my pr here, I had to update the .env file entry for the ds api url from DS_API_URL to REACT_APP_DS_API_URL. Without this change, any attempt to use process.env would result in undefined. It is my assumption this change will be needed to be implemented project wide, as this is the first implementation I could find attempting to parse the .env on the front end.

The stakeholder requested download to csv for this page. It was out of scope for the original ticket, but could be implemented now. I'd like to volunteer Mitchel Crowley and I as tribute.

• Continuing from ticket BL-249 (admin - view all applicants) & BL-847 (BE compatibility), we now need to hook up the FE to access these endpoints through the application modal created on the Admin page when they hit the Review Application button
• An Approve button will hit the /approve endpoint, sending the required info to distinguish between a Mentor and Mentee
• A Reject button will do the same for /reject
• Application table will need to update accordingly on the new validate_status for the Mentors/Mentees

Upon attempting to log in through the breadcrumb, we found that it was showing family promise. We changed the universal login to Bloomtech Labs, and we need to create separate tenants and brand the logins.

Currently, the Backend is working only with dummy data. The backend needs to be able to make an api call to the DS api.

BUG FIX: Currently our implementation of Auth0 is working such that a user can successfully log into the application and be granted a token.

the PrivateRoute component uses a hoc called withAuthenticationRequired. That hook is supposed to check if a user has been authenticated. If a user is anonymous, and the page they're trying to access has been wrapped with <PrivateRoute/> they should then be redirected back to login.

**PROBLEM **: Currently when navigating the app for some reason Auth0 is redirecting and performing what looks like to be a Login attempt. See GIF:

This is a show-stopping bug that needs to be ironed out. However, the app can continue in development alongside the bug, it'll just be annoying.

I'd give anyone willing to tackled this feature (albeit the fix may be simple, it'll require a lot of research and testing) the maximum story points to iron it out.

For ticket BL-1066-be-fe-authentication-and-authorization-hook-ups, I had to modify and add some of the environment variables to configure both BE and FE to create and exchange access tokens instead of id tokens.

@paulstgermain I will send you the updated .env files in a dm on Slack

When scrolling through app, specifically on mobile profile page ( good reference to see ), our navbar on the side does not scroll with you, so you have to scroll back up before you can use navbar to go to another page. Perhaps making the navbar sticky/fixed will help? Would love some insight.

As an admin, it is not possible to get the full slate of information about a Mentor or Mentee(and act on that information if necessary). Part of the challenge is that these are stored in separate endpoints.
By doing the following -

Creating two centralized middlewares to hit the endpoint for each Mentors and Mentees that return the full collection of data from each endpoint, we can then
Build new routes and revise current ones on both the back end and front end that easily access and join this information and return it to the admins who need to act on it.
For importance to the overall project I think this is a 6 to 8 point ticket as it will affect usability across the application.

It appears that a merge that was submitted shortly before the Auth0 PR was merged to main is causing the code on main to crash. It concerns the following closed PR:

BL-859

I've identified the following files as the main problem:

• src\state\actions\applications\setApplicationReject.js
• src\state\actions\applications\setApplicationApprove.js
• src\components\pages\TicketsDashboard\TicketsDashboard.js
• src\components\pages\PendingApplications\ApplicationModal.js

These changes happened around the same time as the auth0 development so it's understandable why the conflict emerged.

Based on what I've seen, it appears that many of the devs are trying to make use of the setFetchStart and setFetchError redux actions when making API calls, which is great. This, however, implements the old axiosWithAuth and we cannot use the new useAxiosWithAuth0 hook in the same way because of how hooks work in React. My suggestion would be to refactor the application modal to use the axiosWithAuth hook directly and have the mentioned redux action functions called directly in the modal, if they're truly necessary.

After reviewing some of the redux slices of state, I'm not sure what is still necessary. The mentioned setFetchStart and setFetchError functions don't really seem to be doing anything on their own and I would argue that this implementation won't have the desired outcome if more than one API call is being made in a component. It appears to be an effort to maybe show some kind of spinner while data is being fetched but that's not even what's happening currently. This functionality could possibly be implemented in the useAxiosWithAuth0 hook directly or perhaps in a more general useApiCall hook that can return the different states/ stages of an API call.

RM EDIT: We'll want to make adjustments to three files:

• src/state/actions/applications/setApplicationApprove.js
• src/state/actions/applications/setApplicationReject.js
• src/components/pages/PendingApplications/ApplicationModal.js

In setApplicationApprove and setApplicationReject we'll want to break down the larger applicationApprove and applicationReject functions into individual functions which dispatch setFetchStart and SET_APPROVAL_SUCCESS or SET_REJECT_SUCCESS respectively.

We'll then want to head into ApplicationModal and, on lines 96 and 114 adjust the approveApplication and rejectApplication to make use of the new axiosWithAuth function pulled from the useAxiosWithAuth0 hook that was recently implemented, rather than making use of dispatch functions to make those axios calls.

To make use of the useAxiosWithAuth0 hook, simply follow these steps:

• import useAxiosWithAuth0 from '../../../hooks/useAxiosWithAuth0';
• const { axiosWithAuth } = useAxiosWithAuth0();
• axiosWithAuth().get('...')...

In discussing this with @ElijahHopkin he suggested that this can be resolved by setting error handling as a slice of state. We have completed the work on the current ticket related to that file - BL-111 so we felt that this would make more sense as a new ticket. Also it might make sense to explore what other files would benefit from a similar fix and make that update across the front end.

In reviewing the Auth0 cleanup code it became clear to me that the flow for logging in has been a bit muddled and isn't very clear - more to the point, doesn't make sense where it's happening and doesn't seem like it will work correctly. Currently the login steps happen in the Navbar component, which doesn't make a lot of sense to me. In my mind, this should be logic that happens in the very beginning of loading the app, before components have started loading (not during the loading of a sub-component). There's also the fact that there is dummy-data being used in the back-end when loading a user profile that should be updated now that Auth0 in the FE should be working.

My proposal:

• FE: Move the login logic from Navbar.js into the App component in index.js.
  • Get the necessary info from useAuth0() to send the profileId to the BE (there's a user object that is made available after the user has authenticated. Make use of isAuthenticated, also provided by Auth0).
• BE: Update the logic in the authRequired.js middleware to actually use the profile, based on the profileId that is passed from the FE
  • This requires receiving the Auth0 profileId or email and retrieving the corresponding profile from the postgres DB, where we have the role recorded, which should be passed back to the FE and saved to state (used for many components)

Helpful reference to what can be destructured from useAuth0(): https://auth0.github.io/auth0-react/modules.html

There is a profileSettings.css file containing Ant-D classnames that is interfering with other modals. Tons of media queries(that I did myself) that need to be removed. Memo.css can be converted to a less file where styles can be nested under container classname for Memo. This will prevent any further interfering with modals. Radio button also needs to be checked for memos, currently using px for radio styling which can be altered or removed.

I would like to suggest an edit to improve the user experience, I did notice that the log-in button on the home page still shows up even after the user is logged in.
I think it will be a simple fix, maybe we can add a ternary to solve this.