Develop "user note" system

[eads]

We need to be able to associate "notes" with volunteers to keep track of sensitive information (like medical conditions that they choose to report) and rather mundane information ("volunteer wants to work on media").

There's a couple ways to do it in Drupal (with a full text field, with a node reference field; one attached note vs. many...). The simpler solutions (basic fields) are easier, the harder solutions (node references) can give us notes that have an associated author, date, etc.

There's also a lot of questions surrounding permissions: Should permissions be on a per-note basis? Can volunteers see their own notes? Basically, who can see what notes associated with a user, and who can create and edit them?

[jimglover]

Is there an option to make notes public or private? There will be issues that volunteers will volunteer to staff but not to everyone. If only the volunteer can see his or her notes then they can be reminded of other issues to add to their notes list or bring up new issues and add them.

Associated author, date, etc sounds good. There will be some responsibility attached to keeping track of notes and it will make it easier to compile and organize them in the long term. If you don't understand the note Dave wrote about said volunteer then you can just ask Dave to clarify.

[eads]

These are great points and they have spurred me to a conclusion: All volunteer notes should be shared with the volunteer and staff people and absolutely no one else. Both volunteers and staff may create such notes on a volunteer's account, and they should be editable but versioned.

We can ask volunteers to provide any personal details they wish to share (including medical information) when signing up, with the assurance that only staff people and the volunteer him or herself will see this information.

Another intersection of technology and policy -- Townsquare is defining (for better and worse) what it means to be staff.

[jimglover]

I thinks it for better. In this manner we have become more dedicated to the volunteers, the most important component of freegeek beyond recycling...lol (it's either us volunteers or palletized CRTs back there). We can show some attention to the individual in this manner and it will give more ease to the volunteering experience. If a volunteer has asthma and a staff person nows this they can remind them to get out of the stuffy basement for a few minutes every now and then to get some air and relax a bit.

Of course, adjustments of every kind will be needed along the way but its and great extension to what staff can be.

[jacobroufa]

I think the requirement that all volunteer notes should be shared with the volunteer and staff but nobody else, as well as the requirement that these notes be versioned, lead me to believe that the notes should be nodes - as both the permissions and versioning are (mostly) built in to Drupal.

Versioning can be extended with Diff and permissions might need an extension with a custom module, as there are currently "edit own" and "edit any" per nodetype, but maybe we can create a simple "Nodetype: View own content" and "Nodetype: View content" per nodetype permission? This way only those with the permissions can view. Staff get the blanket "View content", and Volunteers get the "View own content". At current, I believe other permissions modules (content_access, acl, nodeaccess, etc) are far too complex and granular for this simple use-case. Feel free to suggest one if you feel otherwise.

As to how this should work, I think that each user should have their own list of notes embedded on their user page, using a similar mechanism to how multiple users are added to each event, but with only a simple text field. Notes could also possibly be given a checkbox (use built-in "sticky"?) to designate importance, or a weight/ordering field that could make use of Drupal's drag'n'drop handles. A blank "new note" entry would always exist at the bottom of the list (or the top?) The user entity-reference would happen automatically in the background (grabbing the user via URL arguments? most likely, anyway), as would saving and versioning (also a la the event user precedent mentioned above).

If any or all of this is too complex, feel free to interject and say "Hey! Just add a multi-value field to each user!"

Personally, if potential future extensibility is the object, I think this is a good approach and stays in-line with Eads' original suggestion of the "harder" solution as well as accommodates the needs outlined in the comments above. Also, with a simple view, one could see notes that are tagged important automatically listed out for the staff per-event, based on what volunteers are registered at said event. This way, the staff don't have to dig through each user to find what they need to know!

Double also, this feature can be segmented out and packaged and released to the community as it's own project, which would rule. It doesn't require Townsquare to function, rather it enhances the larger app's user experience. I could definitely see this being useful in it's own right.

So let me know if this sounds good and I'll start building it. :)

[eads]

You may be getting ahead of yourself, and you are definitely not being dumb enough about it, but the general approach is right on. Nodes (which support history and permissions) attached to users. Maybe you should draw of picture of it using Balsamiq.

Also, RedHen CRM says it has something similar. Maybe we just steal it and see what happens. Opensource ftw :D

[jacobroufa]