Now, I know that we don't want to change 'log' because it's huge. But that's okay. We can live with this one exception.
For everything else, I propose we create a new table:
- userid
- itemtype (char? string?)
- itemid
- security (private, custom, friends only, registered users only, public)
- allowmask (for custom only)
Where "itemtype" can be:
- Location
- Birthdate (day and month)
- Birthyear
- Actual e-mail address
- @lj.com e-mail address
- AIM
- ICQ
- Y!ID
- MSN Username
- Jabber handle
- Friend-of list
- Member-of list
- Posting access list
- [sometime-in-the-future-to-exist] Watched-by list
- Paid time expiry date
- Cluster you're on
[Up to here, for all of these, itemid is blank (NULL)]
- memory (itemid = memid)
- todo-list item (itemid = todoid)
- whatever other features we can think of
Then get rid of all the security-related options on editinfo.bml and make a new page: securities.bml (perhaps edit/securities.bml?). This page will have a nice structured uncluttered well-aligned list of all these options (well, just those without itemids of course) with copies of the same drop-down box next to them: Private, Custom, Friends-only, Registered-only, Public. If Custom is selected in any of them, clicking "Save Changes" brings you to a new page where you can click checkboxes for each of the options you custom'ed.
The same mechanism could be used for permissions:
Who can comment in your journal? Private = nobody; Public = anybody; etc. Just call the entries in the drop-down boxes something else.
Whose comments are screened automatically? Will internally become: Who is allowed to comment unscreened? "Registered users only", then, would mean: Anonymous comments are screened. For example.
Suggestions?
I would definitely like to participate in this; in particular, I would like to create the new "Edit Securities" page.