Change getLevel(whatever it is called?) to take an optional bool saying that gods should fall into the 'top' level. Vote allocation, for example, would be done with this flag 'flase' (gods don't get extra votes). Most other things would probably want the flag 'true'.

To confuse people (in a fun way, but some may not like it), we could have user display page use the 'true' behavior. Nah, just name the top level 'God' even though it has little to do with gods except that both apply to vroom.

Change getLevel(whatever it is called?) to take an optional bool saying that gods should fall into the 'top' level. Vote allocation, for example, would be done with this flag 'flase' (gods don't get extra votes). Most other things would probably want the flag 'true'.

I think that this type of thing demonstrates that there is a metaphor clash at work here. Levels and Permissions should be in principle orthagonal concepts. And they could/would be too, except for the fact that we would have to maintain groups with 25k members. Since it has historically been unweildy to make the groups handle levels weve ended going the other equally bad but easier to handle route and made level the system handle permissions.

IMO this means that we end up hardcoding lots of exceptions and weird rules into the codebase which then causes problems when we get to situations like right now where we would like to enhance the level system but cant easily becuase the level system isnt just a level system its also a permissions system.

The solution to this mess IMO is the proposal I made earlier about changing how the isApproved() mechanism works. To recap in a paragraph the idea is to add the ability for isApproved() to use logic based rules (via evalling htmlcode style rule nodes) to determine permissions. This simple extension would provide the flexibility to implement pretty much the complete requirements for all of our Approval needs. Thus we would define the level-group Saints as being a rule based on XP like wise for all the other levels. The CanApprove group would then include the rules for all levels above 5 plus gods. Etc etc.

I really think that if we go ahead with the level/experience change it aught to go along with a comprehensive upgrade and reworking of the permissions system as well, so that once and for all the two are disentangled and cleanly interfaced to each other.

Cheers



---
demerphq


First they ignore you, then they laugh at you, then they fight you, then you win.
-- Gandhi

Flux8

Once and for all is a good idea, but doesn't interface well with what free time/interest I have to do certain changes. I've created a patch for getLevel as tye suggested. If it gets applied I would like to go ahead and remove all the hardcoded 11's from code that calls getLevel and isGod. This should make it somewhat easier for you to sweep through and decide which getLevel calls are to determine permissions and which are just level stuff. But I see no need to wait and do everything all at once.

I would like to see your permissions changes implemented though.

TestedTesting this on the test server:

--- Experience.pm.orig    2004-10-26 15:52:49.000000000 -0700
+++ Experience.pm    2004-10-26 16:22:00.571382400 -0700
@@ -37,20 +37,23 @@ sub BEGIN
 #    "level settings" node
 #
 sub getLevel {
-    my ($USER) = @_;
+    my ($USER, $respect_god) = @_;
     getRef($USER);
     
+    my $isGod = $respect_god && isGod($USER);
     my $exp = $$USER{experience};
         my $LSETTINGS = getVars(getNode('level experience', 'setting'
+));
     $LSETTINGS or return;
 
     my $cnt = 1;
-    while (exists $$LSETTINGS{$cnt} and $exp >= $$LSETTINGS{$cnt}) {
+    while (exists $$LSETTINGS{$cnt} and
+        ($exp >= $$LSETTINGS{$cnt} || $isGod)) {
                $cnt++; 
     }
-        #this finds the /next/ level, so we return the one below it.
+        #this finds the /next/ level, so we return the one below it
+        #(but return one more than the highest level for gods if requ
+ested).
 
-    $cnt-1;
+    return $isGod ? $cnt : --$cnt;
 }
 
 #####################################################################
+###
[download]

I think this should be applied.

---
$world=~s/war/peace/g