2 posts tagged with "Documentation"

Version 2.0.0 documentation release​

• Naming decision for this project
• Code revisions
• User routing
• Docusaurus update

The student portal section is still Portal, but the part that refers to Placement activity recording and marking now has a name!

We are now PRAXIS™

All dev code for the site has been updated with logos and being the scenes folders and paths that referred to /portfolio have been changed to /praxis

There is a playbook for the navigation map based on User definitions. These are linked to the presence of id numbers in fields in the Clerk private metadata as described here

High-Level Routing Logic​

All routing decisions are made server-side in /(auth)/post-login/page.tsx. The resolved private metadata drives a single redirect. No client-side role detection.

On login:
  resolve private metadata from /api/current-user

  if studentId !== ""
    → /dashboard  (Portal — student landing)
    ▶️ action button to /praxis/student (a list of placements)

  else if markerId !== ""  [all markers are staff]
    [markerId sub-role evaluated within Portal, not at login]
    ▶️ action button to /praxis/marker (a list of marking and moderation)

  else if staffId !== ""
    → /staff-dashboard  (Portal — staff landing)
    [sub-roles evaluated within Portal, not at login to cover staff being a supervisor]
    ▶️ action button to /praxis/role (a list of marking and moderation)
    [if tutor has back button on /super route]

  else if superId !== ""
    → /praxis/super  (Praxis — direct federation, no Portal)

  else if observerId !== ""
    → /praxis/super  (Praxis — observer flag set, no Portal)

  else if moderatorId !== ""  [no staffId — external moderator edge case]
    the user will have no Praxis access (26-05_12)
    all moderation done in Sopley Central

  else if externalId !== ""
    → /praxis/external  (Praxis — direct federation, no Portal)

  else
    → /error  (no recognised identity)

Key rule — Marker routing: A marker is normally internal staff and will have a staffId. They land on /staff-dashboard and enter Praxis from there. In the unlikely event that there is a markerId-without-staffId, a branch handles this — they federate directly into Praxis in the same way as a Supervisor.

Key rule — presence checks: All role ID fields are empty strings "" when not held, not null or undefined. All checks must use !== "" not !!value.

Docusaurus version update​

To version 3.10.1, code cleaned and sanitised for new features

Version 1.1.8 documentation release​

• Naming strategy for tasks and groupings of tasks
• Playbook release for comment

The most recent iteration of the playbook (0.2b) has suggestions for the terminology required for task creation and assignment, after a test FM file was created to look at the relationships that would be needed to provide a re-usable interface for getting from a single definition of a task to the individual set that a student needs to interact with on a placement.

The Task creation and entry has two parts, the creation of a surveyjs template saved as JSON, which describes fully the form of questions that will be presented to a student, and the metadata about which module(s), level, course which apply to this - along with some additional flags. The record will show an isActive state, and a date of introduction and also a date of retirement. Once the current date has passed either the introduction or retirement date, the active flag will update.

These tasks may be gathered into a TaskSet, as a convenience holder for multiple similar or parallel Tasks to be carried forwards together. This a re-usable short-hand designed to bring soem time-saving with maximum flexibility. These can be a named group to assist Admins to gather all the tasks that will be required in the next step.

A TaskScheme is a year-scoped record which builds a list of the taskIDs defined by linking to one or more TaskSet records and individual Tasks. Because there is a requirement for all Placements to complete a PlacementExpectation, there will be a method to select from the relevant possibilities. This scheme will have an action button to generate child YearSet records as a one-to-one match for all the referenced Task records linked to the TaskScheme. These will contain a store of deadline dates for each activity for each of the study modes/centres. These form the default date when later instantiated for the Student.

When a student is assigned a Placment record for the current year, the correct TaskScheme link is applied, and all of its YearSet records are used to create all of the StudentTask records that reveal which activities a Student needs to complete during the Placement. These are created with the relevant deadline data from the YearScheme record.

Part of the creation of the records may involve some schema which defines the onward routes allowed - defining who may interact with the record next, and whether or not it is allowable to resubmit the whole thing. It is key that this does not change any already set late flags but will allow the record to return to an 'open' state. This may involve additional stamp fields, but definitely requires audit logging of the action.

Archtitecture is therefore T → TP → TS → YS → ST

Interactions are Role driven, and these have been defined and enumerated for:

• Student
• Supervisor
• Observer
• Marker
• Moderator
• Admin