Specifically, make sure that the header, footer, and tabs are all
shared code so that they look the same and don't need to be
redefined as we add more tab pages.
* Commits:
Remove explanatory paragraph
Add new Studio/insights links to InstructorToolbar
Add courseId to InstructorToolbar props
Create new config values for Insights/Studio URLs
Fix missing definition of unitId in InstructorToolbar.props
Set NODE_ENV in the test environment
Fix mismatched test BASE_URL
Cleanup PORT config
TNL-7191 - We didn’t fully protect against sequences with no units. The next/previous buttons now check whether there is a unit ID and construct a URL without if one doesn’t exist. When we load a sequence without units, we now show a message to the user so the page doesn’t look broken.
This should fix intermittent bugs in checking block completions. Prior we were checking the completion only for the first unit loaded in a given sequence no matter the current unit.
Fixes TNL-7187 - Adds a no-op useLayoutEffect hook to Unit.jsx to prevent the unit iframe from pausing React’s rendering lifecycle. Very strange bug - see comments in that file for more detail.
* Adding an index.js file for user-messages.
Importing from the module, not its contents.
* Allowing customProps to be passed though AlertList to Alerts.
* UserMessagesProvider can create flash messages.
A flash message is one that will be displayed on the next reload of the page. UserMessagesProvider now provides a “addFlash” function. These messages are stored in localStorage and displayed the next time UserMessagesProvider is mounted, which is generally going to be on the next page refresh.
Once displayed, flash messages are cleared out of localStorage.
* Hooking up Enroll Now button and adding “success” alert.
Success alert is shown as a flash message on next page reload.
* Using ALERT_TYPES constants.
TNL-7171, TNL-7172, TNL-7173, TNL-7174: When a user is denied access to load courseware, redirect them to the appropriate location based upon the error code returned. If the error code is unknown they will be redirected to course home.
TNL-7170
lms_base_url becomes lmsBaseUrl in the app and is then used by the InstructorToolbar to link the user back to the LMS. If it isn’t present, the toolbar hides itself. This puts it back.
- “userHasAccess” becomes “canLoadCourseware”, and is loaded from “can_load_courseware”
- “isStaff” is now loaded from “is_staff” instead of “user_has_staff_access”
Fixes TNL-7175: Redirect to course home if a user is not unenrolled and the course is private.
- Require authentication to use the app while course blocks api requires it
- Gracefully handle course blocks api request failures allowing app to proceed to it redirection logic
Notable changes:
- selectors related to sequences are more resilient to missing models. In the case the course blocks api returns successfully but empty (in this case of enrolled but course not yet started).
- `fetchCourse` thunk handles failures for fetchCourseMeta and fetchCourseBlocks separately using `Promise.allSettled` instead of `Promise.all`
- `denied` is a new `courseStatus`
- Access denied redirect is done using a component at a new route `redirect/course-home/:courseId`
Now handles cases
- User is unauthenticated > redirect to login
- User is authenticated but not enrolled > redirects to lms course home
- When an enrolled user attempts to access courseware before the course start date they will load the sequence (but unable to load the vertical block). This behavior should be fixed in an update to edx-platform
See details in code, but this causes UserMessagesProvider to always use the most “recent” version of its messages and nextId state when its callbacks are called.
This is a separate component because we have no mechanism for passing context/state into these alerts right now, and I’m not sure it’s worth building. Easier to just use different codes for different situations.
TNL-7129
This adds a third clause to our useAccessDeniedRedirect hook, which makes sure the user doesn’t have staff access (instead of normal, enrolled access) prior to redirecting.
As an aside, this redirection approach - irrespective of this PR - is not great. The UI mostly renders prior to this redirect happening. It would be better of this hook returned something that would help prevent the UI from rendering while the redirect is in progress. As it stands, a redirected user will see a flash of the page content prior to being booted. Not wonderful.
