durusmail: quixote-users: ContactAdmin misnomer?
ContactAdmin misnomer?
2005-10-07
2005-10-07
2005-10-07
2005-10-07
2005-10-08
2005-10-08
2005-10-08
2005-10-08
Re: ContactAdmin misnomer?
2005-10-07
Re: ContactAdmin misnomer?
2005-10-07
ContactAdmin misnomer?
mario ruggier
2005-10-08
On Oct 8, 2005, at 2:57 PM, David Binger wrote:
> On Oct 8, 2005, at 5:09 AM, mario ruggier wrote:
>>
>> For expiring permissions (such as valid paid subscription), one would
>> need to customize is_granted(), e.g. to call a specific function that
>> checks the validity of the permission? So, persisting this info does
>> not seem like such a good idea... Unless, a permissions can be
>> scheduled, e.g., with a start and end date, the is_granted() check
>> can therefore be self-contained. And how the start and end-dates are
>> set will be external application logic.
>
> Permissions won't be appropriate for every situation.
> I would not customize is_granted(), ever.  Instead, I would
> write more narrowly defined predicates like "is_subscribed()"
> that do what is needed in that situation, either using permissions
> or not.

Yes, not everything should be a permission. But, if we be permissive
for a little while... ;)
I had this idea an mind:

class Permissions(PersistentDict):

     data_is = { (string,either(Persistent, True)) :
either(permission_info_obj, True) }

     ...

     def is_granted(self, permission, granter):
         if (permission,granter) not in self:
             return False
         perm_info = self[(permission,granter)]
         if perm_info == True:
             return True
         # process additional perm_info and return True or False

Here, permission_info_obj could be anything, and may be per permission,
with a permission requiring special processing providing also a check
function to be called with the perm_info_obj. For the subscription case
I was thinking of a simple 2-tuple, (startdatetime, enddatetime).

You feeling is that such a way to go would not be a good idea?

mario

reply