feature: fob metadata
Closed this issue · 4 comments
being able to store more information about the fob, the person that fob has been assigned to would be very useful.
Arbitrary key:value pairs would be best, but otherwise fields like:
- firstname
- lastname
- username (ie to key with another system such as an ldap)
- email address
- department
- status (ie permenant, visitor, contractor etc.)
These would be useful when doing things like:
- viewing logs
- searching for a user to block when they loose a fob
- setting expiry on all of 1 type of card, for instance visitor badges.
Given https://www.kalzumeus.com/2010/06/17/falsehoods-programmers-believe-about-names/ I am inclined to go for "fullname" as a simple text field to be honest. But yes, I'll look next week.
Actually, considering the "Arbitrary key:value pairs" and given this is all done as JSON (in logs and on posts to third party servers) it could be a general JSON object format "userdata" field perhaps. Would that make sense?
Actually, considering the "Arbitrary key:value pairs" and given this is all done as JSON (in logs and on posts to third party servers) it could be a general JSON object format "userdata" field perhaps. Would that make sense?
Yes, that's a bit more work to display, filter, update etc. but it does allow more flexibility in the long term.
I have added a general JSON field to the fob (per organisation) which should apply to logs and hooks as data.
The field should be valid JSON, e.g. null, true, false, a number, a quoted string, a JSON object, or a JSON array. If not valid JSON it is treated simply as a simple string field.