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?
4) 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