Erik Moeller wrote:
Timwi-
What's the point? They'd just log out.
For one thing, we ban offensive usernames.
In this case, the question arises: Do we want the username to continue existing in a banned state? This would leave the offensive username in edit histories. Might we not actually want to delete the account (marking all its edits as from a 'Deleted User') and then make it impossible to re-register it?
For another, we don't give sysops the ability to view IP addresses of signed in users, so they can't ban their IP because they don't know it.
I didn't know that. I guess that makes it possible to keep creating new accounts to overcome any ban.
So, shouldn't there perhaps be a feature that would let sysops ban the IP of a signed-in user without actually displaying that IP?
- While you're at it, you may want to think about a better access rights
system than simple sysop/non-sysop. ACLs would probably work best.
Hm. I'm not very familiar with the concept of ACLs (Access Control Lists, I assume). What in particular can they do that userprops cannot?
Well, the idea is that you can set permissions on a per page basis, and do something like
That sounds like fun. It calls for a new table that describes relations between users and articles:
CREATE TABLE relations ( userid int unsigned NOT NULL, articleid int unsigned NOT NULL, type int unsigned NOT NULL );
Then for the 'type' column we would define readable constants within the source code. So, for example, type 1 means the given user can edit that article. 2 means he cannot. The default is, of course, given by an articleprop ("protected").
But then again, maybe it would be better design to actually think about the different actions you can do with an article (edit, move, delete, etc.) and defining permissions (incl. default permissions) based on that. I'll think about that more, but just now it's too late and I'm gong to bed ;-)
Good night, Timwi