Staff and usermanagement

Hi Ross,

Today, I had a closer look at the staff module using the sample data you provide with Gibbon. I noticed that there are many staff entries (gibbonStaff) with no corresponding entry in users (gibbonPerson). I assume that the corresponding data was deleted maybe because the staff left the school. However, fact it that rather important historic data is stored in gibbonPerson, e.g. start date, end date and departure reason. By deleting a user, that historic data is also lost, right?

The staff module has the very interesting option to display all staff including Expected and Left. This can’t work if the corresponding users are deleted, right?

I think, Gibbon should also aid in keeping historic data, right? Does this mean, that users should never be deleted?

What is the common practice to ensure that historic data is not lost?

Could it be, that keeping the history is of no priority to Gibbon but rather to manage day to day operation of the school.

Kind regards,
Roman

Roman,

My policy is to never delete anyone from gibbonPerson, for the important reasons you mention above. Perhaps it is just an error in the demo data. Please can you give me an example user, and I will see what I can do.

Correct on the point about not being able to see deleted users, and again, that is why IRL, I never delete anything (not just gibbonPerson records, but all records). If something needs to be hidden from the system, there is usually a field called status or active that lets you hide it from some views, but access it via admin views.

I have used systems where old information is archived, but Gibbon does not do this. The aim is to keep all historical record available and live, but held in discrete contains through the use of gibbonSchoolYear. The system trys to show only relevant information…but you can always log into a previous or future school year (using Options in the login area) if you need to access non-current information.

Hope this makes sense.

Thanks,

Ross

Hi Ross,

Thanks for these explanations! Your concept fits my needs very well.

Maybe one issue remains. What happens when data is deleted accidentally? In such a case, flagging records using a delete attribute may be helpful, right?

Kind regards,
Roman

Roman,

Hopefully, if there is accidental deletion, you have a backup to fall back on. Can you tell me more about your idea of flagging records using a delete attribute?

Thanks,

Ross

Hi Ross,

You can simply add another field to the table, e.g. gibbonPerson, named e.g. deleted and you set it to true or false depending on whether the record is “deleted” or not. It’s basically a “virtual” delete. I’ve seen this e.g. in opensourcepos available on gibhub.

Once set up you can then add an “undelete” function to restore data quite easily.

Kind regards,
Roman

This isn’t a bad idea, and in our own school’s live system I actually removed the Delete User button entirely for everyone but my own account :wink: It’d be a little tricky because there’s a lot of relational data so you’d have to account for all the layers, but user records would certainly be a good place to start.

This and item 28 from the v13 roadmap “Much more logging of system actions. Every action? Different levels of logging?” is something our school really needs now that we have a live system running, if no one else has started this item I’d be happy to work on it.

Sandra, sounds amazing, if you have time. I was hoping to log every action in the system using the setLog method from functions.php. It might need a cronable option in /cli to purge log options beyond a certain age, or below a certain threshold level (I don’t think setLog supports levels at the moment, but you can add that in if you like). A delete log could hold the contents of the deleted row as a serialised array.

That, combined with Roman’s suggestion for undeleting users, would be a nice solution.

Get stuck in! : )

Thank,

Ross