(temporarily housed here until a better location can be thought of)
New Staff Profile Page
Following on from the work Paul Seiler (Unlicensed) has done here:
WIP-248 - Getting issue details... STATUS
This page will discuss the technical details of the options or providing these services.
A new staff page will look something like this:
It will provide separate areas for the different roles people will have. It will allow for extra roles/contact details for a staff member to add. As well as allowing for custom values such as About Me and links to other websites, it will include automatically generated values such as "Currently Teaching" and "Publications". If any of these values are empty, they will simply not show on the site. (in the picture, Publications hidden is provided simply as an example. This will not show in a live version).
If a person is logged in and they have permissions to edit the page (it is either their page, or they are an administrator of that staff member), they will see an "Edit" button allowing them to edit the page.
The 'Edit Page' will look (very roughly) like this:
Values that cannot be edited on this page will either be greyed out, or surrounded by a red border with a message linking them to information on why these values are not editable, and how they can go about getting them updated.
Our goal is to try and have as few non-editable values as possible, but due to the restrictions on the data sources, it will unfortunately be inevitable.
All other values will be input fields, which will be automatically populated with existing content (or left blank where there is none).
A future feature that is displayed here is the option for a staff member to make certain sections only available to students and staff members, staff members only, or not visible.
Technical Information of new system
Following on from the success of COO, I think Staff Profiles could follow a similar process.
Each staff member page is really a call to the GSA to get a staff profile based on the parameters passed in by the url. E.g. victoria.ac.nz/staff-directory/andrew-bredenkamp would ask the GSA to return the staff profile page for all staff members in the "staff directory" collection matching the name Andrew+Bredenkamp. Putting aside the issue of staff members with the same name (which I will deal with below), this will return either one value with all their staff information to display, or multiple values for each of the roles this person has. The page will then interpret this data and display it accordingly. It will use the 'primary' role as the repository of new custom information, and use any extra returned values to create contact details 'cards'.
Potential issues with this model:
If someone associates all their data with a role, which then later gets removed/turned into another role, all their customisations could dissapear.
- Potential solution: ensure that roles have a grace period before they are removed from the database, and alert a staff member of the issue and make sure they select a new role as their primary so the information is not lost
Requires a new JSON blob to be added to the VicPhone database.
Another potential option for the way staff are stored in the database, is to find a reliable definitive list of all staff members without duplications and use this to create a new clean database of staff members. When a staff page is accessed, do another call to the old database to get the details of the multiple roles they may have. The staff member will then also be able to mark which of these roles is their primary role when they edit their staff page.
E.g. Staff page for Andrew Bredenkamp is loaded - First call goes to vicPhone.cleanDatabase which returns the new information for the Staff Member of Andrew, not including any information about existing roles. The page then calls vicPhone.oldDatabase for a list of all the roles Andrew Bredenkamp is associated with. This returns "Andrew Bredenkamp, Extreme Mountain Boarder. Ph 04 123 4567" as well as "AProf. Andrew Bredenkamp, Deep Sea Roller Blade Enthusiast. Ph. 04 532 2345. Address 12 Ocean Avenue, Pacific Ocean". These are then turned into contact cards and inserted on Andrews Staff Page. Andrew decides that, while his love of roller blade-ing is astounding, it is his work at Mountain Boarding that people will most be interested in, so he selects that as his primary role.
Potential issues with this model:
Requires creating a new database of staff members
- This may also turn out to be a benefit, as it will be a database we have control and access over, meaning we will have complete control over what values are stored and accessed, something we are very limited in with our current model. However, it will increase development time.
A new database means yet another repository of staff information
- Totally valid concern, but this really just taking the blob that would be in vicPhone, and allowing us to have more control over it.
Would require us finding a clean, maintained list of all staff members.
- Does this even exist??
Academic Staff vs General staff vs Postgraduate Students