Skip to main content

v1.0.7

· 3 min read
John Renfrew
John Renfrew
Programmer and data architect

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.