Hey folks--

Earlier I was mentioning that I'd like other people to help test out the profile system before it goes live. Here is a guide to doing that on my development server.

Account creation and log in

Right now there are three different ways to log into the site: GitHub, OpenID, and Persona. I am open to adding Twitter/Google/Facebook login support as well, but those are more complicated to set up, so we can start with these I think. Once an account is created, you will be able to add more. All accounts require a username to be given as well as an email, which is verified.

Here is the login page, that also links to the basic registration page.

http://hedynet.audrajohnson.com/accounts/login/

The login link is available in the top menu on the site if you are logged out.

One you are logged in, there are many account management features under the "Accounts" section of the site map:

http://hedynet.audrajohnson.com/sitemap

You can:

Add an email, change primary emails, verify email addresses
Set or change your account's password
Manage offsite logins -- add them, remove them

When you are logged in, the top menu log in button changes to a user menu and a log out button.

Member directory

The member directory is here:

http://hedynet.audrajohnson.com/profiles/directory

The profile system has the ability to restrict access of the profile and/or bits of profile information to different levels of user. Those levels are:

public -- The information will be able to be seen by any visitor or bot, logins not necessary
registered -- The information will show to any logged in user. This is not mega secure, but it will keep information out of Google indexing and discourage drive by information gleaning.
members -- The information will show only to users who are members
admin -- We'll need to figure out who we want to make admins (board members? people with that specific job?), but it will try and limit the information just to who might need to see it. For instance, maybe you do not want everybody to have a certain phone number but would like it to be accessible in emergencies. In this instance, mark it admin access.

You will always be able to see your own information on your own profile, regardless of access level and your membership status on the site.

The profile system has the ability to record multiple methods of contact information--email, phone, and addresses--with the ability to mark one as preferred. (The method of entering in which is preferred could be improved; right now you must create the contact information, then edit the general profile and select which item should be used.)

The about section of the profile takes Markdown syntax, though I need to make the space bigger for entry I think.

Member administration

Folks who could be managing membership (or heck, anybody who just wants to check it out and test right now)--comment or email me! I can set you to an admin and you can test out the member status admin area:

http://hedynet.audrajohnson.com/profiles/admin/memberstatuslist

You will see a list of users, their current status, when they became a member (could be tricky business with people coming/going). You can change their status to one of:

active -- an active member
applying -- somebody who is applying to be an active member
refused -- somebody applied but did not get in this round
inactive -- previously an active member but not currently
revoked -- a person whose membership was revoked; ideally never to be used!

You can make notes about the status. These notes are not displayed anywhere someone who is not an admin can see. I should probably make a page for each member that lists all status changes.

The status of membership and member since shows on a member's profile.

Notes on testing

Try creating/editing/deleting information! Only put in information that is either: fake, okay to be public, unimportant if lost. We want to test the system to make sure that it will work okay for stuff that is real, shouldn't be public, and should be retained.
Feel free to make multiple accounts, so you can have one just registered, one that's been made into a member, one that's an admin. It'll want different emails for each but I know with GMail it is easy to fake with +appendage
Try to see if you can see information that you think you shouldn't be able to see. I can make you a member or an admin for testing purposes.

The code behind the system

Because HedyNet is an open source project that others can work on, I should do a little tour about the code behind this new system in case anybody wants to start looking at it. The main Django app that implements this is here:

https://github.com/akjohnson/HedyNet/tree/develop/HedyNet/profiles

Some notable bits:

constants.py -- fairly comprehensible for all levels of coding ability, it just lays out important constants in the process for the access levels (and their different grouping options), member statuses, and contact methods.
access.py -- the two different important utility functions. It is modularized to be convenient to include in other app models definition code files. The two functions: access_levels determines what access levels can be viewed given a certain viewer and a certain owner; can_access determines if a given access level is valid given a certain viewer and a certain owner. Useful to know Python to review this.
models.py -- This defines the data models behind user profiles; useful to know Django conventions, but gleanable I think in most ways. Upon review, filter_access_levels (which will filter a database query to only show valid items given an access level) should possibly be moved to access.py
tests.py -- Nope, I'm not relying only on all your sharp eyes to catch bugs--this test suite focuses on making sure the access system is working appropriately.
views.py -- Go to a given URL off of DOMAIN.COM/profiles and it will feed into one of these views. Worse than models.py for beginner readability, relies a lot on Django conventions/magic. The URLs get defined in urls.py

A base for future development

This is sort of the groundwork of most other things on the site we would want to make, because it is the part of the site that implements the access system. That's why it's important to test out the sensitive bits, because bugs in this part of the system could be damaging to people who trust it, not just mess up the display of some page or throw up an error.