Moorlands DigiFolio™ Blog

v1.99 Longer sample

2026-12-12T00:00:00.000Z

This is the summary of a very long blog post,

Use a comment to limit blog post size in the list view.

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Pellentesque elementum dignissim ultricies. Fusce rhoncus ipsum tempor eros aliquam consequat. Lorem ipsum dolor sit amet

v1.1.8 Playbook

2026-03-22T00:00:00.000Z

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

v1.1.7

2026-03-20T00:00:00.000Z

Version 1.1.7 internal test release

Writing playbooks
New server

Many of the core technology tests or pipeline requirements are now encapsulated into playbook markdown files. These serve the dual purpose of documenting test assumptions and results, and keeping a record of open or unanswered questions. They will also provide a valuable resource for the eventual documentation of the structure behind production build code.

The most important of these under devlopment, is the DigiFolio_Student, which decribes the interactions with the app from the position of the various defined roles. It also covers the core principles behind how the Student Taksks relate to Placements and Modules. These playbooks enable assumptions to be questioned in advance of writing code, as it is 'cheap' to make amendments at this planning stage, and much more difficult later.

Now that Oracle have stopped being difficult to deal with, there is a dedicated FileMaker server for this project. It is reached at folio.moorlands.ac.uk. This means we can start to scope out the architecture of file relationships, especially communication between Folio FileMaker files and Sopley Central. Testing and build can now proceed with final urls and account settings even during test phases. There is a need for a register of 'users' to feed the Clerk auth, and replicated data on placements.

v1.1.6

2026-03-15T00:00:00.000Z

Version 1.1.6 internal test release

Testing video upload and precessing

Following from conversation about StudentTasks, a technology test was completed to uncover issues and benefits in the requirement to allow video uploads, with later playback (markers and external). In the same way as documents, this needs to allow the re-submission of a file until the task is 'locked'.

Because the upload can be a long running process, then upload status needs to be visible while it is happening, and then encoding to straming formats takes place service-side, and so there is a requirement for the UI to show the stages of progress up to the point of completion. From that point, with the record in locked state the UI would show both a thumbnnail of the video, and button elements to view the video using the service player.

At this stage, all testing was done with a small (32sec) video, but later testing needs to work out timings for upload, encoding, and the storage implications of a years worth of full-size video.

After previous investigation conclusions, this test was done with Bunny -https://bunny.net. Their Stream platform is fully API driven and so highly suitable for the purpose. A playbook is written and fully tested.

Upload → first creates BunnyStream video object, returns videoId (similar to Inspera)
On return the StudentTask record is patched with this into videoID field and status of uploading
Upload → then the file is uploaded to that document record, using TUS resumable upload protocol (automaticlly handles interrupted transfers)
On status complete, the StudentTaks record is updated to show that processing is processing
MetaTags are added to the Stream record, which can be used for search and other API operations
Task record videoStatus updated through lifecycle, videoEmbedUrl populated when encoding complete
Bunny sends webhooks on progress and these are routed through Claris Connect, so that some actions can eaily update Task record, and also forwarded to the node service

Direct upload to Bunny ensure video bytes never touch our server, we only handle metadata and progress or status information. The player format is simple > https://player.mediadelivery.net/embed/{libraryId}/{videoId}

Investigation was made into using signed links for video retrieval but honestly wasted a lot of time on something which still unable to get to work. The files ar enot publicly exposed and the ony way you can get to view is from inside something where you are logged in, so for the moment parked unless there is deemed a need. The player's default behaviours (autoplay, captions, preload) can be set globally in the BunnyStream library dashboard.

Encoding

Encoding is free on the strndard tier but uses a shared queue. Premium encoding is available for a charge : uses Just-In-Time (JIT) technology — video playable within seconds of upload. Cost at $0.05/minute: estimate of max 1,200 minutes × $0.05 = $60/year maximum. Given that the marker is looking at the task records after they are completed it is unlikley that this would be required.

Testing with a 32-second 64MB MOV file completed end-to-end in under 6 minutes, testing with more realistic file will give better benchmarks. This does affect the ability of the student to view the uploaded and encoded file, discussion needed.

Futher development

A student on a mobile device (e.g. recording placement footage on a phone) could receive an SMS or email containing a link to a minimal, standalone upload page from inside the Digifolio. The link contains enough context to identify the StudentTask record without requiring full portal authentication, to be able to view the video. This would be linked to a one-time or short-lived token.

v1.1.5

2026-03-13T00:00:00.000Z

Version 1.1.5 internal test release

Testing .docx and .pdf text extraction

Following from conversation about StudentTasks, a technology test was completed to create a service to be able to ansyncronously retrieve a base64 encoded document from a FileMaker record. This would be triggered after a submit action finalises a student task submission. There is no UI requirement, so status information becomes key to confirm completion, failure or stalled extractions. Paramters are {taskID, fileType}

{
  "text":       "extracted plain text content",
  "charCount":  17961,
  "durationMs": 209,
  "library":    "mammoth",
  "version":    "1.8.0",
  "filename":   "report.docx",
  "lineBreaks": "single",
  "hash":       "c99b32954d120bf62ad818944660275f"
}

This has been extended to provide a micro-service, which can take parameters of type and base64encoded file, along with fileName and returnHash. As this is an open endpoint we shall be adding a state or session parameter to reduce fake attempts.

informacja

cURL https://server/extraction/api/extract/direct {"b64": "${B64}", "fileType": "pdf", "fileName": "test4.pdf", "returnHash": true}

{
    "text": "extracted text",
    "charCount": 2115,
    "durationMs": 241,
    "library": "mammoth",
    "version": "1.12.0",
    "filename": "test.docx",
    "hash": "c99b32954d120bf62ad818944660275f"
}

Response is very fast at sub 300ms for 4 page test docx file, and this covers:

TLS handshake
nginx proxy overhead and routing
base64 decode
mammoth parsing the DOCX XML
JSON serialisation of the response
network latency both ways

A playbook is written and fully tested.

Upload → stores b64 of doc on StudentTask record
(may repeat — each upload overwrites previous b64)
Commit → OData PATCH (answers + timestamp + locked)
→ fire-and-forget POST to extraction service
POST /api/extract

Node Extraction Service (Express)

PATCH StudentTask → extractionStatus: 'processing'
Fetch b64 from StudentTask via OData
Decode → Buffer
Branch: DOCX → mammoth | PDF → pdfjs-dist
Compute MD5 hash of original binary
PATCH StudentTask → extracted text + metadata
POST to FileMaker script → archive b64 to Documents FileMaker StudentTask record — extracted text, status fields Documents record — reconstituted original binary linked to StudentTask

If questions are prefixed with a known character (§) then the text can be extracted with singke carriage returns and then substitute extra lines before teh character for presentation purposes. The extraction is written as a service, so could be called from other places in the FileMaker ecosphere.

v1.1.4 Translation

2026-03-11T00:00:00.000Z

Version 1.1.4 internal test release

Translations tests to docs site
Polish (pl)
Hungarian (hu)
Romanian (ro)
Serbian (hr)

Added frameworks and set up for aditional translation support for Supervisor tutotrial pages. Basic supervisor and student docs pages are now in languages.

Decision needed on which Serbo-Croation flavours to support.

Installed the AWS translation code into Sopley_portfolio on the altdb server, to make it more widely available. Paste the text to be translated into the left field, select the language for the output text, and push the translate button. Once the translation is returned, the copy button will place the output text on the clipboard. You may, of course, copy parts of the output.

There is an indication of the length of the text in the centre, along with an indication of the cost of the action. AWS charges $50 per million characters.

v1.1.3 Tasks interface

2026-03-03T00:00:00.000Z

Version 1.1.3 internal test release

progress on scope documentation, which is mostly complete and released as v1.0
inital clickable demo on the Tasks interface
starter for discussion on how some of the parts need to work with each other

Tasks interface

This is a pseudo-live clickable demo, the code equivalent of wireframes, which serves as a design exploration, decision tree, and technology test all-on-one. From the placment list this outlines the behaviour after a students selects Tasks.

A list of Tasks is presented, with indicators for deadline date, late, and locked. If a user selects a task row, it replaces the placement list with the survey view in place — no page navigation, top navigation stays but back nav button changes label and action. If there is an stored data returned from the query initiated on clicking the row, client code always injects authoritative values for these fields, overriding anything in locally stored data.

The student enters data or selects form a presented choice, and at the footer are three buttons. Save will perform and explicit commit of data (back to FileMaker). Clear will remove all current values from form. Submit will show dialog confirming action, and then both save data and add the finalCommit value. For students, all buttons are hidden when isLocked === true.

Autosave

The Student + open state only — record is debounced at 1500ms after last keystroke to trigger autosave. No autosave for supervisor, marker, or any finalised record. (autocheck needs to only be triggered if there is data, so after clear, it will not overwrite savedData ??)

SurveyJson Hidden Fields

studentID, moduleID, superID remain as hidden questions inside the surveyJson
This preserves the FileMaker Creator approval workflow — question authors can test conditions without code

Because this is a combination of React and SurveyJS, there are behaviours that can be driven from the client as well as the JSON definition. They work at different levels: SurveyJS JSON conditions handle question-level behaviour, React/client code handles the survey-level behaviour in TaskClient.tsx - this the important one for the locked/finalised case (this needs to be always for external, and for student if locked) — which puts the entire SurveyJS instance into a read-only display mode regardless of any individual question conditions. No inputs are rendered, everything becomes plain text.

if (isStudent && task.state !== "locked" || isExternal) {
  survey.mode = "display";
}

The desired behaviour for supervisor and marker requirements need finalising, and a decision about visibility to students of supervisor and/or marker comments.
A TEMPLATE Task is created, with one of each role of question and notes about visibility conditions. Creators start from there and duplicate questions as required, which keeps the settings & conditions. This is easy because you can simply change th question type from the drop-down.

Question Naming Conventions

Prefix	Who	Behaviour
`Q1`, `Q2` etc	Student questions	`enableIf: "{superID} empty"`
`SQ1`, `SQ2` etc	Supervisor questions	`enableIf: "markerID} empty", visibleIf: "{superID} notempty"`
`MQ1`, `MQ2` etc	Marker questions	`visibleIf: "{markerID} notempty"`
`studentID`, `moduleID`, `superID`, `markerID`	Hidden carriers	Always injected by client

v1.1.2

2026-03-02T00:00:00.000Z

Version 1.1.2 internal test release

Echo360 API
Updated SurveyJS to 2.5.13
more

Echo360 has an API, which allows us to manage User accounts (and media). We have tested the API, and have scripts running in FileMaker to query Student users, based on Moorlands Email address. There is also a script to create a user, and Echo then sends them an email invite to the platform. We need to investigate what happens with the MCEE students and time zones on sign-up.

The access token for the API is valid for 1 hour, after which the refresh token can be used to retrieve another, along with a new refresh token. Each refresh token may only be used once, so it there is some failure, the process needs to use the client-credentials workflow as a fallback.

The creation of the Echo360 account could be scripted as part of the initial student comms from Technical Support. With API access, the User accounts could then be removed as part of the end-of year or leaving process.

Echo360 Video

It may be that using the User account to hook to any video uploads is not the right thing to do, as the Student:

would have to manually create a sharing link so that it can be pasted
has the opportunity to delete the file after upload

Next investigations will cover the mechanics of uploads through the DigiFolio, but sent to a holding account, which ensures that students can not see anyone else's work (but also their own)

The Core Problem

The Echo360 public API (/public/api/v1/medias) does not expose raw file download URLs for media. The /medias endpoint returns metadata about media items (title, ID, duration, owner, status, etc.), but there is no field in the response that gives you a direct link to the underlying MP4 file. Echo360's architecture deliberately abstracts away the raw files — they're stored in S3 behind authenticated, signed URLs that are generated on-the-fly by the player, not exposed through the public API.

There are plenty of alternatives for S3 compatible storage, which could provide a signed (time-limited) download link, but the better option might be through a site that offers a stremaing viewer, which also implies a need for encoding. Alternative to investigate is BunnyStream. The pricing for this is micropriced, based on storage volume and playback traffic, so needs some research into the projected volumes.

SurveyJS

We have also updated SurveyJS to the latest version, 2.5.13, which includes some bug fixes and performance improvements. We have tested the new version with our existing surveys, and everything seems to be working fine.
We have also made some minor revisions and corrections to our documentation specifications and codebase, which should improve the overall stability and usability of the system.

v1.1.1

2026-03-01T00:00:00.000Z

Local layouts to copy web app

Investigating how the elements that are web native can be replicated in FileMaker. It is not the same thing, so either we find a way to adapt the web code to show in a single page webviewer or mimic the layout but accept there are some differences in function.

The webcode is not pure js or html, and has a lot of restrictions around login, so feels really too much work to reconstruct just the display elements. The icons from react-lucide are available as SVG downloads, so after some manipulation can be used to match the web UI.

Some old-school tricks here to get highlighting and button visibility to work, but this is (native) FileMaker:

v1.1.0 StudentTask definition

2026-02-28T00:00:00.000Z

Definition of StudentTasks

This article assembles the tech tests undertaken, and review notes for investigations inot the best mechanisms to implement the SurevyJS code for StudentTasks within the DigiFolio application under development. While these are presented as a structured document, and might appear as finalised, it is also for the purpose of discussion of the key decisions represented, to ensure that the right architectural direction is taken.

The core of this document is saved as /

StudentTask Workflow & Implementation

Overview

This document presents the current design patterns and implementation decisions for the StudentTasks, including multi-role handling, autosave, final submission concept, and review workflows.

Actors:

Student – completes one or more survey questions (Task)
Supervisor – reviews and optionally adds comments
Marker – oversight and comments specifically at mid-year/end-of-year
External Examiner – audits combined data from selected student task records

Design Principles:

Separation of student answers (savedData) and reviewer/marker comments (reviewerData, markerData)
Finalised answers pushed to additional log file for audit/ academic governance
Autosave only for students
Final submission triggers addition of timestamp and webhook audit/export
Short reviewer/ marker questions do not require autosave; manual submission only

note: marker/tutor may end up with discrete set of tasks fitted into a student task list, and discussion is needed about additional marker interaction with individual StudentTasks.

Field Definitions

Source: FileMaker records

Field	Purpose	Update Rules
`savedData` (JSON)	Student task answers	Updated on Save or Finalise
`lastSubmit`	Most recent save timestamp	Updated every save
`finalSubmit`	Timestamp of final submission	Updated only on Finalise
`status` (enum)	Workflow stage: 0=Open/Active, 1=Submitted, 2=Viewed, 3=Reviwed, 4=Marked?, 5=Examined	Updated only on Finalise or Submit button by Super, Marker, External
`isLate`	Derived from `finalSubmit > deadlineDate`	Auto-calculated
`superData` (JSON)	Supervisor/Marker comments	Updated by reviewer/marker
`superId`	User ID of Supervisor	Set on review submission
`reviewedAt`	Timestamp of review	Set on super submission
`markerData` (JSON)	Marker comments	Set by marker
`markerId`	Marker ID	Set on moderation
`markedAt` (optional)	Timestamp of review	Set on marker submission
`externalData` (JSON)	External examiner comments (optional)	Set by external
`externalId`	External ID	Set on moderation
`externalAt` (optional)	Timestamp of external view of record	Set on external submission

Student Workflow

Student selects placement, then task record

From placements, student selects button (based on module and/or placement) to open a list of tasks to complete in deadline date order. Ordered by deadline date, oldest at bottom.
Student selects task (restricted if isLocked > 0 or too far in the future?)
Do we want student to see all submission in the past?? Once it is finalised it could be unlocked locally in FileMaker to allow modification - what happens to finalSubmit date?

Open/Active
- SurveyJS renders initial student questions editable, and others hidden
- Autosave triggers write to savedData and lastSubmit

survey.onValueChanged.add(() => {
  debounceSave(survey.data);
});

survey.onValueChanged.add((sender) => {
  if (currentUser.role === "student") {
    autosaveStudentAnswers(sender.data);
  }
});

Finalise Submission
- Sets finalSubmit
- Updates status => 1 (submitted)
- Evaluates isLate
- Triggers webhook for external audit/export

if (currentUser.role === "student") {
  await fetch("/api/student-task/finalise", {
    method: "POST",
    body: JSON.stringify({
      studentTaskId,
      savedData: survey.data
    })
  });
}

Supervisor / Marker Workflow

SurveyJS renders student answers read-only
Supervisor/marker questions are visible and editable, based on role
No autosave; manual submission only

if (currentUser.role === "super" || currentUser.role === "marker") {
  await fetch("/api/student-task/review", {
    method: "POST",
    body: JSON.stringify({
      studentTaskId,
      reviewerData: survey.data,
      reviewerId: currentUser.id,
      reviewedAt: new Date().toISOString()
    })
  });
}

reviewerData or markerData is stored separately from savedData
Short questions mean manual submit is sufficient

External Examiner Workflow

Receives concatenated export snapshot including:
- Student answers from (savedData)
- Reviewer comments from (reviewerData)
- Timestamps (lastSubmit, finalSubmit, reviewedAt) ??
- Late flag (isLate) ??
No SurveyJS rendering required, simpler - could also be a PDF format to download?

Role-Based Save / Submission Rules

Role	Save Target	Autosave?	Submission / Finalise
Student	`savedData`	Yes	Finalise → sets `finalSubmit`, triggers webhook
Supervisor	`reviewerData`	No	Manual Submit → sets `reviewedAt`
Marker	`markerData`	No	Manual Submit → sets `markedAt`
External	N/A (read-only)	N/A	N/A

StudentTask Lifecycle Diagram (ASCII)

        ┌───────────────────────────────────┐
        │   Student Placement Tasks         │
        └───────────────────────────────────┘
                  │
                  ▼
       ┌─────────────────────┐
       │ Open/Active.        │
       │ (savedData updated, │
       │ lastSubmit)         │
       └───────┬─────────────┘
               │
       Save / Autosave (student only)
               │
               ▼
       ┌─────────────────────┐
       │ Finalise Submission │
       │ finalSubmit set     │
       │ status==1           │
       │ isLate evaluated    │
       └───────┬─────────────┘
               │
               ▼
        ┌───────────────┐
        │  ++ Webhook   │
        │ Export Trigger│
        └───────┬───────┘
                │
                ▼
  ┌────────────────────────┐
  │ Role-Based Review      │
  └─────────────┬──────────┘
                │
    ┌───────────┴───────────┐
    ▼                       ▼
┌───────────────┐         ┌───────────────┐
│ Supervisor    │         │ Marker        │
│ Review Task   │         │ Review Task   │
│ (reviewerData │         │ (markerData   │
│ + reviewedAt) │         │ + markedAt)   │
└───────┬───────┘         └───────┬───────┘
        │                         │
        └───────► Manual Submit  ◄┘
                │
                ▼
     ┌─────────────────────┐
     │ Final Marking       │
     │ Done in FileMaker   │
     │ from aggregate +    │
     │ isLate flags +      │
     │ time records data   │
     │ transferred to ARLT │
     └─────────────────────┘
                │
                ▼
     ┌─────────────────────┐
     │ External Examiner   │
     │ Receives full export│
     │ (student answers +  │
     │ reviewerData +      │
     │ timestamps + isLate)│
     └─────────────────────┘

Key Definitions & Conclusions

Student and reviewer/marker answer data stored separately
- savedData → student
- reviewerData → supervisor
- markerData → marker/tutor/admin
Autosave limited to student role
- Prevents overwriting by other roles
- Reduces chance of lost-in-translation transport errors
- Only needed for student editing mode
Finalise submission / Submit button
- Students → triggers finalise + webhook
- Supervisor/marker → manual submit of short answers only
Late flag (isLate)
- Derived from finalSubmit vs deadlineDate in FileMaker
- Students can submit late; flag used for audit/reporting
Workflow metadata tracked via timestamps
- lastSubmit → autosave / last student activity
- finalSubmit → 'finalised' submission
- reviewedAt → supervisor/reviewer submission
- markedAt → marker comments???
External audit/export
- Webhook captures snapshot on finalise, to audit log endpoint
- Supports external Examiner review without SurveyJS

Language

SurveyJS 'questions' we refer to a 'Task', comprising one or more questions A collection of Tasks that is against a student, additionally with an academicYear and deadline, is a 'StudentTask' The StudentTask is considered Open until a second button both saves answer data, and 'finalises' the record by adding a second timestamp value. The submitted answers for a StudentTask is available to be reviewed, firstly by 'Supervisor', and subsequently by a 'Marker' If the submission of a Task is after the Deadline, then it is considered 'Late', based on a field which auto-calculates the

Model considerations

By storing the JSON for the questions on the StudentTask records, then the data will match the related questions. If there is a need to modify (say a question wording) then that is on the Task record until pulled into the StudentTask record(s). Structural changes (particularly modifiying question numbers) should therefore ONLY be done mid-year, for Tasks that are not yet near their deadline. To get the Tasks dynamically runs the risk of an update being prepared for another year then being returned to be answered. This also involves two api calls - one for model and one for data.

If status > 0 (finlised), then:

savedData must never change again
*unless* unlocked by an admin (this will be logged) - what happens to deadline, isLate, finalSubmit??
Only superData can be added
Only markerData can be added

wskazówka

createExternalRecord - present as Markdown?

function createExternalRecord(studentTask) {
  let text = `Student Inputs:\n`;

  for (const [q, a] of Object.entries(studentTask.savedData)) {
    text += `  ${q}: ${a}\n`;
  }

  if (studentTask.superData) {
    text += `\nReviewer Comments (by ${studentTask.superId} at ${studentTask.reviewedAt}):\n`;
    for (const [k, v] of Object.entries(studentTask.superData)) {
      text += `  ${k}: ${v}\n`;
    }
  }

  if (studentTask.markerData) {
    text += `\nModerator Comments (by ${studentTask.markerId} at ${studentTask.markeddAt}):\n`;
    for (const [k, v] of Object.entries(studentTask.markerData)) {
      text += `  ${k}: ${v}\n`;
    }
  }

  return text;
}

Useful code snippets

// App.tsx
} />
// TaskSurvey.tsx
const navigate = useNavigate();

//Express proxy
app.post("/submit", async (req, res) => {
  try {
    const response = await fetch(process.env.ODATA_URL, {
      method: "POST",
      headers: {
        "Content-Type": "application/json",
        "Authorization": `Bearer ${process.env.ODATA_TOKEN}`
      },
      body: JSON.stringify(req.body)
    });

    const data = await response.json();
    res.json(data);
  } catch (err) {
    res.status(500).json({ error: "Submission failed" });
  }
});app.post("/submit", async (req, res) => {
  try {
    const response = await fetch(process.env.ODATA_URL, {
      method: "POST",
      headers: {
        "Content-Type": "application/json",
        "Authorization": `Bearer ${process.env.ODATA_TOKEN}`
      },
      body: JSON.stringify(req.body)
    });

    const data = await response.json();
    res.json(data);
  } catch (err) {
    res.status(500).json({ error: "Submission failed" });
  }
});

//pattern
import { Model } from "survey-core";
import { Survey } from "survey-react-ui";

const TaskSurvey = () => {
  const [model, setModel] = useState();

  useEffect(() => {
    async function loadSurvey() {
      const definition = await fetchSurveyDefinition();
      const savedData = await fetchSavedAnswers();

      const survey = new Model(definition);
      survey.data = savedData;

      survey.onComplete.add(async (sender) => {
        await submitSurvey(sender.data);
      });

      setModel(survey);
    }

    loadSurvey();
  }, []);

  return model ?  : Loading...
;
};

//express
import express from "express";
import fetch from "node-fetch";
import cors from "cors";

const app = express();

app.use(cors());
app.use(express.json());

app.post("/submit", async (req, res) => {
  try {
    const response = await fetch(process.env.ODATA_URL!, {
      method: "POST",
      headers: {
        "Content-Type": "application/json",
        "Authorization":
          "Basic " +
          Buffer.from(
            process.env.ODATA_USER + ":" + process.env.ODATA_PASS
          ).toString("base64"),
      },
      body: JSON.stringify(req.body),
    });

    const text = await response.text();
    res.status(response.status).send(text);
  } catch (err) {
    console.error(err);
    res.status(500).json({ error: "Submission failed" });
  }
});

app.listen(3005, () => {
  console.log("Proxy running on port 3005");
});

const surveyJson = JSON.parse(data.QuestionsField);
const themeJson = JSON.parse(data.ThemeField);
const savedData = JSON.parse(data.SavedField ?? "{}");

//task
import { Model } from "survey-core";
import { Survey } from "survey-react-ui";

const TaskSurvey = ({ surveyJson, themeJson, savedData }) => {
  const survey = new Model(surveyJson);

  survey.data = savedData ?? {};

  survey.applyTheme(themeJson);

  survey.onComplete.add(async (sender) => {
    await submitSurvey(sender.data);
  });

  return ;
};

//at first route load
let globalTheme: any = null;

export async function loadThemeOnce() {
  if (globalTheme) return globalTheme;

  const res = await fetch("/api/theme");
  const data = await res.json();

  globalTheme = JSON.parse(data.themeJson);
  return globalTheme;
}
//inside page
const theme = await loadThemeOnce();
survey.applyTheme(theme);

informacja

Student clicks task
        ↓
React route /task/:taskId
        ↓
Backend fetches StudentTasks record
        ↓
Returns:
    surveyJson
    savedData
        ↓
Frontend:
    Parse JSON
    Load global theme
    Create Survey Model
    Inject saved data
    Render
        ↓
On complete:
    POST to proxy
        ↓
Proxy writes to OData (Basic auth)

//additonal button
survey.addNavigationItem({
  id: "finalise",
  title: "Finalise Submission",
  action: async () => {
    await finaliseSubmission(survey.data);
  },
  css: "sd-btn--action"
});
POST /api/student-task/save
POST /api/student-task/finalise

v1.0.10

2026-02-27T00:00:00.000Z

Version 1.0.10 internal test release

surveyjs theme editor prep work

Theme editor

SurveyJS has a Theme Editor which provides a method to preview a modified theme for the/ elements. This is saved as a JSON definition file, which can then be injected into the code for rendering the page, along with the definition JSON.
It does mean (although I am not going to recommend this), that each task, or similar group of tasks, could have their own theme. The following samples show tasks with the default theme over-ridden.

Sample 1 is for student use, has three buttons for different actions, different colours and hover state
Sample 2 is a simple confirmation task for supervisors, with Czech translation as the 'description'
Sample 3 has a link to a downloadable file, with an upload widget, to demonstrate the idea of offline answers

informacja

Sample 1
Sample 2
Sample 3

v1.0.9

2026-02-27T00:00:00.000Z

Version 1.0.9 internal test release

Discussions about requirent for other core translations to this site
Futher definition of tasks off the student record (StudentTasks) and how they map to actual placements
Consideration of other types of input, or methods of interaction. Example of a downloadable template which can be filled, uploaded with the text extracted and stored.
Investigation of Echo360, which has student accounts, for the purpose of uploading video files (within limits), which returns a link to be added to the task record.

Use cases

A student may be on a single placement a year for one module only. This is the simplest case to programe and manage. [plain]
They may have more than one placment in a year, each attached to one module. [multi]
They may have a placmement that is attached to two modules, and so the task need to be assigned to the module and the placement. [split]
They may do an additional (short) placment for one module. [extra]
THe case may be that there are combinations of number of placements and whether one or more has more than one mudule attached. [complex]
They may change placment during the year which then remains linked to the same module(s) as the one it replaces. [replace]
There may be tasks which are floating to the module, and so may be completed on any placement associated with that module. [float]
There may be tasks which are floating to the placement, and also floating to either module. [free]
This implies that until a StudentTask has been assigned a module, it is available to all, or all in the same placement, but then after that is becomes fixed for the purpose of marking.

The assemblage of StudentTask records allow for those to be marked and entered into the related ARLT record, which imolies that whether this was completed in a single placement or multiple, these records can be filtered down to just those linked to a specific module.

Because all supervisors and some markers will be using the web front-end, it is desirable to not have to download local copies of files to see their content, and that linked video should be shown in new browser window.

v1.0.8

2026-02-21T00:00:00.000Z

Version 1.0.8 internal test release

Decision - this is all going to be available at portal.moorlands.ac.uk and docs.moorlands.ac.uk
After initial demos, we are adding translation to this site, so that MCEE students and supervisors can have documentation in Czech (Čeština)
Base structure creaated for forms, discussion about language below

Alternate language content may be reached from the drop-down top right of the site, with Cestina being the only choice. Notes about this are added to appropriate pages. Translation is done using Amazon Translate from AWS, and we need a mechanism for proof-reading and corrections where appropriate.

The two things a student has to complete during a placement are records of time with activity, and a series of questions that require a typed answer. The first of these will be referred to as Time Records. The second will be called Task Entries. The entry may be a text input, but also any other appropriate control (like a tickbox or radio set, or scale or priority ordering) There may be requirement for additional doument uploads, and the precise nature of these is currently being discussed.

The 'task entries' are a collection of questions created in surveyjs with the describing JSON being saved on a FileMaker record (through the _portfolio file). Each question may have read-only and visibility criteria added, based on data that is added to the student's saved data, modifying the form behaviour. At the 'top' are questions visible and editable by students. Next are questions only visible to supervisors, while the student answers become read-only. After that are questions for markers with all the above noiw read-only. And finally external examiners may have their own question to confirm they have reviewed the record, with all other answers read-only.

The questions are then gathered in a set or bundle that may be common to one or more module placements. They are marked with year(s) for which they are considered active. These template-bundles are then used to create a module-specific template for a specific academic year. The module-specific template may consist of one or more template-bundles and also individual tasks. At this point each of the tasks now in the module-specific template is assigned group visibility (so a task may only be visible to a supervisor or marker, in addition to the behaviour within the task outlined above). Dealine dates are added for each of the (currently 3) centres.

A student placement will be linked to one of these module/year-specific templates, and a scripted process will add an individualised copy of each of the template records (StudentTasks), using the appropriate deadline data based on the Study Centre in Sopley Central and the JSON object which defines the specific questions in the task. These will be first ordered by deadline date before creation, so that the filemaker view will naturally sort to this order. These are the individual endpoints where student/ supervisor/ marker responses will be held, and from where they can be pulled to re-hydrate any tasks.

The relationship graph to enable this currently looks like this in _dev

v1.0.7

2026-02-19T00:00:00.000Z

Version 1.0.7 internal test release

Further work to define the path from task entries to Placements and back out to saved records
Outline in FileMaker to model the required relationships
Consideration to packege tasks into templates, and how they get added to a placement
Additional possibility to add a single task to a placement
Creation of Studio app to be a simple mobile time entry device
Exploratory work with surveyjs to be the enab;ing tech for the task entries

The Placement for each student needs a set of records that to are to be filled over time. Each of these need to store the 'submission' into a record which contains a deadline date, and an indicator of late submission and a locked status. The intent is that the data is stored as JSON, so that a part-filled form can be recreated (to have additional comments added)

This will be well served by defining how to create a collection of tasks into a 'bundle' (plan in OneFile language). These would be stored on records with an acYear indicator, which will allow for then to be used as a starting point for next year. They are also linked to modules, either as a full or partial tenplate. Given that the number of placement enable modules is currently 10, this is envisaged to require moderate effort. Because these bundles are leading to a 'mark' that ends up on an ARLT record, there is need to ensure that the order of record creation is important.

Once the bundle is fixed and dealine dates applied, given that there are (at the moment) 3 different centrea, then the lowest impact way is to enter each of the dates onto the bundle for this current year. Students who are taking the module/placement can then be given their own copy of the bundle of tasks in the template.

There are open questions about where a placement consists of more than one module, the neccessary actions in the case that a placment is changed part-way through the year, and the potentiasl requirement for individual tasks to be added to a placment.

A Studio form was built as a starter for simple date/time entry and can be found here

The surveyjs work has been to explore the mode advanced capabilities, like hidden fileds and ensuring they are passed through to the saved data, locking or showing fields when (for example) a supervisor ID is added to the record. The outlined behaviour is that if the superID is present then the student contributions become locked, and in the absence of a superID their comments are hidden (what about later when you want the student to see what was written?). Initial tests have data flowing into FileMaker records, which is the desired outcome!

There is a concept for both time and task records, to include a status flag, enabling them to act as 'locked' in the UI, but because these are available as FileMaker records, then overriding the behaviour is simole to achieve.

v1.0.6

2026-02-18T00:00:00.000Z

Version 1.0.6 internal test release

Initial ideas for display of student list for external examiners (compact view)
Development on time entries for student portfolio, buttonon placement object
Connection of portfolio models to placement records with eSQL query

Created a new display component to present compact or expanded view of student placments, based on query to return relevant set of placement records. For external examiners this is limited to module, student name, organisation

Added initial idea for time-record component linked to placement records. Function is to display all submitted time records, in reverse order, to indicate which are flagged as locked, and so unable to be ediited ( this could be modified by admin in FMP ), allow for the creation and saving of a new record, or if icon selected to push detail into entry section for updating.

Structure => {"date","time","type","description",ROWID}

Student > course > level (acYear) > module choices > module > ARLT marking records
Module > placement > tasks > marking > ARLT

A placement record is a join between student, acYear, module ++ assignment. It links via record keys to organisations and people. Further elements hang off each one - time/diary records and tasks.

v1.0.5

2026-02-16T00:00:00.000Z

Version 1.0.5 internal test release

Code refactoring to cache metadata IDs server-side
Investigations into speed of invoices retrieval
Moved processing of data containing pre-composed JSON to server-side
Core novigation structure becoming defined

Cache of metatdata can improve performance whenever a page or route needs to use or display items we are storing - like an ID. It is stored in the Clerk API and so request use involves a query, which can be sped up with the used of cached data. This data changes very rarely and so this pattern is used to hide the IDs away, while making them available for server-side routes which are using them as filters or keys in OData queries.

To allow for this to be build out from the Student Portal, the following routes enable that. /login => with a student email => dashboard, with a staff email => staff-dashboard. The student version has a link from there into the Digifolio parent.

If a user logs in with an email associated with a superId then they arrive at portfolio-super, with an email associated with a markerId then portfolio-marker, and if external, then portfolio-external. These are siloed from each other, and in the event that there is a staff portal, then there would be a button to enter the digifolio similar to students.

Students will see a picker for the placements they have active during the year, with action buttons for further sections to manage and enter time-based events, and another to enter task data.

Supervisors would see the students they are supervising in the current year, and on selection of the student the detail as above with additional fields for their commments on the student responses to the task questions.

Markers would see a longer version of the list, based on being assigned as marker for a set or module, and other controlsa vailable as above. Markers would be able to add adidtional comments after the supervisor. This may never happen if it is detirmined that all markers will be accessing the data from FileMaker.

External would see a pre-filtered list simialar to above of the random set assigned to them.

v1.0.4

2026-02-14T00:00:00.000Z

Version 1.0.4 internal test release

Schema for metadata started
Preparation of supervisor dashboard page
Removal of unused and exerimental code to simplify project directory
Error page improved and added Pushover notifications
Experiments with cache for privateMetadata Id values

Changed the components on the trusted contacts and it looks and feels a whole lot better. Now it is using shadcn there is some control over colours and styles, but some things just do not work well as Tailwind seems to take over, and even though shadcn uses Tailwind colours, not all of them will render. I find that white buttons with white text on a white background is probably too minimalist.

WIP

Cache works but is too hard to ensure that it is cleared beween user sessions, not normally a problem for a single user, but makes testing difficult if you change to a staff login, and the cache still thinks you are a student. Potential visibility of values in console logs so shelved until a more robust and secure solution is found. It does make a difference to the overall speed, as it reduces the need to call the Clerk object, which is in itself, defensive coding so that you can not 'jump' to any route endpoint without being logged in.

informacja

public metadata - front and back end

name: string
surname: string
fullName: string
userType: string
isAdmin: int
last_updated: timestamp

informacja

private metadata back-end only, call /api/current-user

uniqueId: string uid
studentId: int
staffId: int
superId: int
moodleId: int
individualId: int
externalId: int
email: string

v1.0.3

2026-02-13T00:00:00.000Z

Version 1.0.3 internal test release

First steps to collecting and displaying Placement data
JSON is pre-composed in the PLC table to simplify the fetch

The information retrieved is based on a year (where there may be more than one placement per year) so the years are displayed acrosst the top, where you can select the data for that year

WIP

Select the Tasks button to see a list of deadline dates relating to tasks - from the start of the placement to (n) days in the future. There are indicators showing if the task is editable or not. If it editable (or empty) then selecting the item opens a card where the specific task inputs are presented.

Select the Time Records button to see a list of the time records that have been entered, showing date, hours recorded and the first nnn characters of the description so it fits in a reduced one-line space. There is a button to create a new record, which opens a card element to add date, time, description and includes a drop-down for the type (based on the Course requirements)

The project includes shadcn UI components, initial work to move some elements to their shadcn alternatives, to give a more consistent feel between pages.

Clerk metadata has been refactored so that all IDs are inside privateMetadata, but a single re-usable route can be used server-side to get any or all of the IDs then cache them, so there will be no need for a route to just get student-id or staff-id. Other code refactoring has simplified the number or round trips just to get an ID.

v1.0.2

2026-02-10T00:00:00.000Z

Version 1.0.2 internal test release

Added staff login and portal page
Preparation for supervisor ID and portal homepage
Code refactoring to ensure navigation directly to any page redirect to login if there is no current session
Added pages for Trusted Contacts (different for staff and students)
Added links to JotForm collection pages for quick access to forms

This publicly accessible test version is hosted on a free instance on Oracle. Work to understand upload, installation and SSL and Nginx configuration.

Trusted Contacts, for student gets information from NXT table and for staff from STF table. Students have one or two, and staff only 1 with no address data. Provision of edit card below data to modify either of the record values - submission to webhook (altdb ottoInbox) to enable review of information sent, to avoid pranks and bad days.

Staff Portal, placeholder layout with buttons to JotForms and Trusted Contacts.

Marking, get data from shadow file as the final field in Sopley Central is a convoluted calculation with the risk of crashing the OData process.

Added the route into empty placeholder files so we can check it is navigating correctly.

Test users, added sam.clement, 2024999 (test user)

informacja

The first time a user logs in from a new device with Clerk, they receive a confirmation email

All links in the login component to use social, forget password,signup are turned OFF

v1.0.1

2026-01-03T00:00:00.000Z

Version 1.0.1 initial private release

Initial work to verify Clerk logins and metadata
Simple student portal with button to navigate to other pages
Investigations into OData connections to pull data into pages

Meals, retrieves data for last week, this week, and any in the future that have been submitted. This is counted from the starting Monday of today, and is displayed as a table

Invoices, retrieves data from _finance for invoices related by uniqueID. Invoice Number, Total, Due Date, Status are displayed as a table

Moodle Tasks, retrieves data (not all students have data, this is for Online and remote), display has summary ring/donut charts, with drilldown when selected

Placeholders for Attendance, DigiFolio, Marking

Test users 2025001, 2025013, matt - login data comes from altdb quicker file