durusmail: qp: deleted Permissions keys that keep coming back
deleted Permissions keys that keep coming back
2007-01-27
2007-01-27
2007-01-28
deleted Permissions keys that keep coming back
mario ruggier
2007-01-27
Strangely, I was getting a deleted Permission (deleting the entire
PersistentDict item (key:str, value:PersistentSet) ) reappearing after
a server restart...

As a simple example that reproduces this, i have added the following 3
exports to the proto example in qp 1.9.1 :

         yield ('grant', 'grant', 'grant', 'grant')
         yield ('ungrant', 'ungrant', 'ungrant', 'ungrant')
         yield ('show_perms', 'show_perms', 'show permissions', 'show
permissions')

that are implemented as below:

     def grant [html] (self):
         header(get_site().get_name())
         publisher = get_publisher()
         user = publisher.get_users()['']
         '

granting: test

' user.permissions.grant('test', True) publisher.commit() self.format_perms(user) footer() def ungrant [html] (self): header(get_site().get_name()) publisher = get_publisher() user = publisher.get_users()[''] '

ungranting: test

' user.permissions.ungrant('test', True) publisher.commit() self.format_perms(user) footer() def show_perms [html] (self): header(get_site().get_name()) '

show permissions

' publisher = get_publisher() user = publisher.get_users()[''] self.format_perms(user) footer() def format_perms [html] (self, user): from qp.lib.spec import persistent_vars perms = user.permissions.items() if not perms: '

no permissions

' else: for key, value in perms: '

%s: %s

' % (repr(key), repr(persistent_vars(value))) To reproduce, start with a clean durus db, on the modified proto demo, then do: 1 - qp proto start 2 - [grant] that grants null_user "test" for True 3 - [show permissions] 4 - [ungrant] that ungrants null_user "test" for True, and since the set is empty, the key is deleted in the Permissions dict. 5 - [show permissions] 6 - qp proto stop 7 - qp proto start 8 - [show permissions] This last action shows me the empty set for the "test" permissions, i.e. u'test': {'s': set([])}, that was not shown in [5]. It seems somehow the last delete action is registered in the durus client but not in the server. Anyone can confirm this behaviour? Here on OS X, python 2.4, qp 1.9.1, durus 3.6. Retaining an empty set in this case is not really a problem, but in another case (that I am unable to reproduce simply) I am also getting back, after server restart, a non-empty set, after having deleted it... in any case i do not see where the problem might be coming from within the qp code, and it may well be a durus issue? mario
reply