This is the summary of a very long blog post,

Use a <!-- truncate --> comment to limit blog post size in the list view.

Blog posts support Docusaurus Markdown features, such as MDX.

Version 1.0.8 public 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, 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

Version 1.0.7 public 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.

Version 1.0.6 public 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.

Version 1.0.5 public 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 uop 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.

Version 1.0.4 public 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.

Version 1.0.3 public 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.

Version 1.0.2 public 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)

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

Admonitions in Markdown​