Integrate row-level security

This is a task to track row-level security permissions model for desktop UI. The same permissions data will be used by the web app, but will not be enforced at the database level (as requests will be via the web application user, for authentication and connection pooling reasons).

Current database tables (staging):

Read-only but accessible for normal users

Table	Public	Comments
academicyear	Yes	Stores the year start dates - public information
activitytype	Yes	Stores timetable activity types - internal but non-sensitive
assessment_type	Yes	Turn it in vs studio submission, etc...
buyout_type	Yes	Probably fine, technically on the WAM page
division	Yes	Mapping of divisions to student values - available on website
role	Yes?	Roles are public, the modelling finance numbers probably shouldn't be - but are not meant to be on this table anymore!
week mapping	Yes	How Falmouth week numbers line up with the timetabling system

Division specific read-only tables

Tables which shouldn't be modifiable for day-to-day purposes, but will need to be department aware

Table	Public	Comments	Write access groups	Source
staff	No	Staff names and notes	Managers (if automated: HR/No one)	HR
course	No	Names and codes - available on the website	Managers (if automated: SPA/No one), should change through cause approvals	Records
module	Yes	modules and who owns them, basically on the website	Managers (if automated: SPA/No one), should change through module approvals	Records
module_cohort	No	What cohorts are attached to what module instances	Managers (if automated: Student records/No one), values provided via finance	Records
roompool	Yes?	Room Pools are internal data - can be department specific or general. Courses shouldn't be able to select room pools which aren't relevant to them	Admin/No one - comes from timetabling	Timetabling
roompool_academicyear	No	Room capacities and internal roompool names	Admin/No one - comes from timetabling	Timetabling
cohort	No	Student courses - Department specific	No one - should be automated, if not then managers	Records
cohort_academicyear	No	Student numbers are on RADAR, but probably should be considered confidential	Numbers from TT/Finance (lower/upper bound)	Records, Finance, TT
assessment_method	Yes?	Probably fine, stores known assessment types - some types might be department specific (eg, group working)	No one - should not change without justification	Department, SPA
contract	No	Contract functionality - probably needs to be treated as sensitive information	Should only really change via CVF process	HR
buyout	No	Probably should be considered sensitive information	Changes via university policy	Uni management
role_academicyear	No	Finance modelling numbers	Finance

Division specific read-write tables

Need read/write access for planning - should be module aware

Table	Public	Comments	Source
moduleinstance	No	Contains module leader information, contact hours, etc...	Records, CL
activity	No	Should only be accessible to people in department	HOS/CL
iterations	No	What groups/iterations are on each session, same as activity	HOS/CL
iterations_roompool	No	What rooms are attached to an iteration, same as activity	HOS/CL
iterations_staff	No	What staff are attached to what session, same as iterations	HOS/CL
assessment	No	Attached to modules - some information public (akari), deadlines shouldn't really be as myfalmouth is the source of truth	SPA
assessment_staff	No	What members of staff are attached to each assessment - workload related	HOS/CL

Internal tables

Table	Public	Comments
migrations	No	What database migrations have been applied, internal, but who cares