RFC: credentials

Hi dev

Having had the need to recently use the fine grain
credential control  
i find it a little unintuitive and a little restrictive, i
feel that  
we should allow for normal logical syntax of AND, OR with
brackets to  
map real life scenarios, such as:

root OR admin OR editor OR (supplier AND owner) OR (supplier
AND  
group) OR accounts

currently, the above i do not think is possible with
existing syntax,  
please can someone help if it is.

Is this likely to change for the 1.0 release, even if the
current  
rules were reversed and so [admin, root] was admin OR root,
and  
[root, admin, [suppler, owner]] meant root OR admin OR
(supplier AND  
owner) ???

I realise that this will break BC, but currently the logic
that  
handles this i believe is very restricting.

Please correct me if the above statement can be implemented
with the  
existing syntax.

Many thanks

Joe

--
To unsubscribe, e-mail: dev-unsubscribesymfony-project.com
For additional commands, e-mail: dev-helpsymfony-project.com

It is mathematically possible to write any logical
expression with  
the current implementation, although it would get redundant
and thus  
awkward to write. It is based on the following logical
property: a⋁ 
(b⋀c) = (a⋁b)⋀(a⋁c), so "a OR (b AND c)"
can be coded as "[[a,  
b], [a, c]]".

Your statement could be implemented using the following
identity,  
derived from the property above:
a⋁b⋁c⋁(d⋀e)⋁(f⋀g)⋁h =
(a⋁b⋁c⋁d⋁f⋁h)⋀ 
(a⋁b⋁c⋁d⋁g⋁h)⋀(a⋁b⋁c⋁e⋁f⋁h)⋀ 
(a⋁b⋁c⋁e⋁g⋁h)

So although theoretically all logical expression can be
coded with  
the current system i wholeheartedly agree that it is not
flexible  
enough, although i'm not sure what would be the best
solution.

cheers!

== Olivier

Le 2 oct. 06 à 10:43, Joe Simms a écrit :

> Hi dev
>
> Having had the need to recently use the fine grain
credential  
> control i find it a little unintuitive and a little
restrictive, i  
> feel that we should allow for normal logical syntax of
AND, OR with  
> brackets to map real life scenarios, such as:
>
> root OR admin OR editor OR (supplier AND owner) OR
(supplier AND  
> group) OR accounts
>
> currently, the above i do not think is possible with
existing  
> syntax, please can someone help if it is.
>
> Is this likely to change for the 1.0 release, even if
the current  
> rules were reversed and so [admin, root] was admin OR
root, and  
> [root, admin, [suppler, owner]] meant root OR admin OR
(supplier  
> AND owner) ???
>
> I realise that this will break BC, but currently the
logic that  
> handles this i believe is very restricting.
>
> Please correct me if the above statement can be
implemented with  
> the existing syntax.
>
> Many thanks
>
> Joe
>
> --
> To unsubscribe, e-mail: dev-unsubscribesymfony-project.com
> For additional commands, e-mail: dev-helpsymfony-project.com
>


--
To unsubscribe, e-mail: dev-unsubscribesymfony-project.com
For additional commands, e-mail: dev-helpsymfony-project.com

Hey olivier

Thanks for useful insight, at least i know how it is
possible and can  
be implemented, but that is really gonna take some crunching
 
everytime i need to write a credential!

Maybe, to prevent BC issues, we could add an additional
layer of a  
credential string:

>> root OR admin OR editor OR (supplier AND owner) OR
(supplier AND  
>> group) OR accounts

This then gets converted into the appropriate array required
by the  
existing system.

So in a nutshell, if the credential is a string it tries to
parse  
this into the array property required by symfony, but if it
is an  
array it simply uses the existing system.

So, how do we convert a string into this array structure
required by  
symfony???? I haven't a clue yet? maybe explode OR, check
for  
brackets in each element, check for ANDS, if AND, explode
ands, and  
then do some fancy loop to create arrays. Ummmmmm??

Anyone else any other ideas?

Thanks

Joe


On 2 Oct 2006, at 10:01, chtito wrote:

> It is mathematically possible to write any logical
expression with  
> the current implementation, although it would get
redundant and  
> thus awkward to write. It is based on the following
logical  
> property: a⋁(b⋀c) = (a⋁b)⋀(a⋁c), so "a
OR (b AND c)" can  
> be coded as "[[a, b], [a, c]]".
>
> Your statement could be implemented using the following
identity,  
> derived from the property above:
> a⋁b⋁c⋁(d⋀e)⋁(f⋀g)⋁h =
(a⋁b⋁c⋁d⋁f⋁h)⋀ 
> (a⋁b⋁c⋁d⋁g⋁h)⋀(a⋁b⋁c⋁e⋁f⋁h)⋀ 
> (a⋁b⋁c⋁e⋁g⋁h)
>
> So although theoretically all logical expression can be
coded with  
> the current system i wholeheartedly agree that it is
not flexible  
> enough, although i'm not sure what would be the best
solution.
>
> cheers!
>
> == Olivier
>
> Le 2 oct. 06 à 10:43, Joe Simms a écrit :
>
>> Hi dev
>>
>> Having had the need to recently use the fine grain
credential  
>> control i find it a little unintuitive and a little
restrictive, i  
>> feel that we should allow for normal logical syntax
of AND, OR  
>> with brackets to map real life scenarios, such as:
>>
>> root OR admin OR editor OR (supplier AND owner) OR
(supplier AND  
>> group) OR accounts
>>
>> currently, the above i do not think is possible
with existing  
>> syntax, please can someone help if it is.
>>
>> Is this likely to change for the 1.0 release, even
if the current  
>> rules were reversed and so [admin, root] was admin
OR root, and  
>> [root, admin, [suppler, owner]] meant root OR admin
OR (supplier  
>> AND owner) ???
>>
>> I realise that this will break BC, but currently
the logic that  
>> handles this i believe is very restricting.
>>
>> Please correct me if the above statement can be
implemented with  
>> the existing syntax.
>>
>> Many thanks
>>
>> Joe
>>
>> --
>> To unsubscribe, e-mail: dev-unsubscribesymfony-project.com
>> For additional commands, e-mail: dev-helpsymfony-project.com
>>
>
>
> --
> To unsubscribe, e-mail: dev-unsubscribesymfony-project.com
> For additional commands, e-mail: dev-helpsymfony-project.com
>


--
To unsubscribe, e-mail: dev-unsubscribesymfony-project.com
For additional commands, e-mail: dev-helpsymfony-project.com

Here is an idea. We could agree on the convention that one
switches  
from AND to OR for each depth in the array. In the current  
implementation one starts with AND and then switch to OR,
but why not  
go further? Your statement would thus become:
[[root, admin, editor, [supplier, owner], [supplier, group],
accounts]]

Here is another example:
root OR (supplier AND (owner OR quasiowner)) OR accounts
would become:
[[root, [supplier, [owner, quasiowner]], accounts]]

That approach has several advantages:
- it covers all the basic needs (i think)
- it does not break BC
- it should be fairly easy to implement.

cheers!

== Olivier

Le 2 oct. 06 à 12:10, Joe Simms a écrit :

> Hey olivier
>
> Thanks for useful insight, at least i know how it is
possible and  
> can be implemented, but that is really gonna take some
crunching  
> everytime i need to write a credential!
>
> Maybe, to prevent BC issues, we could add an additional
layer of a  
> credential string:
>
>>> root OR admin OR editor OR (supplier AND owner)
OR (supplier AND  
>>> group) OR accounts
>
> This then gets converted into the appropriate array
required by the  
> existing system.
>
> So in a nutshell, if the credential is a string it
tries to parse  
> this into the array property required by symfony, but
if it is an  
> array it simply uses the existing system.
>
> So, how do we convert a string into this array
structure required  
> by symfony???? I haven't a clue yet? maybe explode OR,
check for  
> brackets in each element, check for ANDS, if AND,
explode ands, and  
> then do some fancy loop to create arrays. Ummmmmm??
>
> Anyone else any other ideas?
>
> Thanks
>
> Joe
>
>
> On 2 Oct 2006, at 10:01, chtito wrote:
>
>> It is mathematically possible to write any logical
expression with  
>> the current implementation, although it would get
redundant and  
>> thus awkward to write. It is based on the following
logical  
>> property: a⋁(b⋀c) = (a⋁b)⋀(a⋁c), so
"a OR (b AND c)" can  
>> be coded as "[[a, b], [a, c]]".
>>
>> Your statement could be implemented using the
following identity,  
>> derived from the property above:
>> a⋁b⋁c⋁(d⋀e)⋁(f⋀g)⋁h =
(a⋁b⋁c⋁d⋁f⋁h)⋀ 
>>
(a⋁b⋁c⋁d⋁g⋁h)⋀(a⋁b⋁c⋁e⋁f⋁h)⋀ 
>> (a⋁b⋁c⋁e⋁g⋁h)
>>
>> So although theoretically all logical expression
can be coded with  
>> the current system i wholeheartedly agree that it
is not flexible  
>> enough, although i'm not sure what would be the
best solution.
>>
>> cheers!
>>
>> == Olivier
>>
>> Le 2 oct. 06 à 10:43, Joe Simms a écrit :
>>
>>> Hi dev
>>>
>>> Having had the need to recently use the fine
grain credential  
>>> control i find it a little unintuitive and a
little restrictive,  
>>> i feel that we should allow for normal logical
syntax of AND, OR  
>>> with brackets to map real life scenarios, such
as:
>>>
>>> root OR admin OR editor OR (supplier AND owner)
OR (supplier AND  
>>> group) OR accounts
>>>
>>> currently, the above i do not think is possible
with existing  
>>> syntax, please can someone help if it is.
>>>
>>> Is this likely to change for the 1.0 release,
even if the current  
>>> rules were reversed and so [admin, root] was
admin OR root, and  
>>> [root, admin, [suppler, owner]] meant root OR
admin OR (supplier  
>>> AND owner) ???
>>>
>>> I realise that this will break BC, but
currently the logic that  
>>> handles this i believe is very restricting.
>>>
>>> Please correct me if the above statement can be
implemented with  
>>> the existing syntax.
>>>
>>> Many thanks
>>>
>>> Joe
>>>
>>> --
>>> To unsubscribe, e-mail: dev-unsubscribesymfony-project.com
>>> For additional commands, e-mail: dev-helpsymfony-project.com
>>>
>>
>>
>> --
>> To unsubscribe, e-mail: dev-unsubscribesymfony-project.com
>> For additional commands, e-mail: dev-helpsymfony-project.com
>>
>
>
> --
> To unsubscribe, e-mail: dev-unsubscribesymfony-project.com
> For additional commands, e-mail: dev-helpsymfony-project.com
>


--
To unsubscribe, e-mail: dev-unsubscribesymfony-project.com
For additional commands, e-mail: dev-helpsymfony-project.com

Chtito/Fabien

I've supplied a patch in r2294, in my branch, that
implements this.

Could you be so kind as to take a look and maybe run some
tests, i  
have run some and it seems to work well (attached).

Fabien, could this be commited to trunk, it doesn't break
BC?  
However, i am on a tight deadline and don't have time to
learn the  
new testing framework, especially without docs, so would you
mind in  
the next week or so if i commit some small patches without
tests  
until some brief docs are published or i have some more time
to get  
on top of this new feature. Hope you understand.


Thanks

Joe

On 3 Oct 2006, at 09:04, chtito wrote:

> Here is an idea. We could agree on the convention that
one switches  
> from AND to OR for each depth in the array. In the
current  
> implementation one starts with AND and then switch to
OR, but why  
> not go further? Your statement would thus become:
> [[root, admin, editor, [supplier, owner], [supplier,
group],  
> accounts]]
>
> Here is another example:
> root OR (supplier AND (owner OR quasiowner)) OR
accounts
> would become:
> [[root, [supplier, [owner, quasiowner]], accounts]]
>
> That approach has several advantages:
> - it covers all the basic needs (i think)
> - it does not break BC
> - it should be fairly easy to implement.
>
> cheers!
>
> == Olivier
>
> Le 2 oct. 06 à 12:10, Joe Simms a écrit :
>
>> Hey olivier
>>
>> Thanks for useful insight, at least i know how it
is possible and  
>> can be implemented, but that is really gonna take
some crunching  
>> everytime i need to write a credential!
>>
>> Maybe, to prevent BC issues, we could add an
additional layer of a  
>> credential string:
>>
>>>> root OR admin OR editor OR (supplier AND
owner) OR (supplier AND  
>>>> group) OR accounts
>>
>> This then gets converted into the appropriate array
required by  
>> the existing system.
>>
>> So in a nutshell, if the credential is a string it
tries to parse  
>> this into the array property required by symfony,
but if it is an  
>> array it simply uses the existing system.
>>
>> So, how do we convert a string into this array
structure required  
>> by symfony???? I haven't a clue yet? maybe explode
OR, check for  
>> brackets in each element, check for ANDS, if AND,
explode ands,  
>> and then do some fancy loop to create arrays.
Ummmmmm??
>>
>> Anyone else any other ideas?
>>
>> Thanks
>>
>> Joe
>>
>>
>> On 2 Oct 2006, at 10:01, chtito wrote:
>>
>>> It is mathematically possible to write any
logical expression  
>>> with the current implementation, although it
would get redundant  
>>> and thus awkward to write. It is based on the
following logical  
>>> property: a⋁(b⋀c) = (a⋁b)⋀(a⋁c), so
"a OR (b AND c)" can  
>>> be coded as "[[a, b], [a, c]]".
>>>
>>> Your statement could be implemented using the
following identity,  
>>> derived from the property above:
>>> a⋁b⋁c⋁(d⋀e)⋁(f⋀g)⋁h =
(a⋁b⋁c⋁d⋁f⋁h)⋀ 
>>>
(a⋁b⋁c⋁d⋁g⋁h)⋀(a⋁b⋁c⋁e⋁f⋁h)⋀ 
>>> (a⋁b⋁c⋁e⋁g⋁h)
>>>
>>> So although theoretically all logical
expression can be coded  
>>> with the current system i wholeheartedly agree
that it is not  
>>> flexible enough, although i'm not sure what
would be the best  
>>> solution.
>>>
>>> cheers!
>>>
>>> == Olivier
>>>
>>> Le 2 oct. 06 à 10:43, Joe Simms a écrit :
>>>
>>>> Hi dev
>>>>
>>>> Having had the need to recently use the
fine grain credential  
>>>> control i find it a little unintuitive and
a little restrictive,  
>>>> i feel that we should allow for normal
logical syntax of AND, OR  
>>>> with brackets to map real life scenarios,
such as:
>>>>
>>>> root OR admin OR editor OR (supplier AND
owner) OR (supplier AND  
>>>> group) OR accounts
>>>>
>>>> currently, the above i do not think is
possible with existing  
>>>> syntax, please can someone help if it is.
>>>>
>>>> Is this likely to change for the 1.0
release, even if the  
>>>> current rules were reversed and so [admin,
root] was admin OR  
>>>> root, and [root, admin, [suppler, owner]]
meant root OR admin OR  
>>>> (supplier AND owner) ???
>>>>
>>>> I realise that this will break BC, but
currently the logic that  
>>>> handles this i believe is very restricting.
>>>>
>>>> Please correct me if the above statement
can be implemented with  
>>>> the existing syntax.
>>>>
>>>> Many thanks
>>>>
>>>> Joe
>>>>
>>>> --
>>>> To unsubscribe, e-mail: dev-unsubscribesymfony-project.com
>>>> For additional commands, e-mail:
dev-helpsymfony-project.com
>>>>
>>>
>>>
>>> --
>>> To unsubscribe, e-mail: dev-unsubscribesymfony-project.com
>>> For additional commands, e-mail: dev-helpsymfony-project.com
>>>
>>
>>
>> --
>> To unsubscribe, e-mail: dev-unsubscribesymfony-project.com
>> For additional commands, e-mail: dev-helpsymfony-project.com
>>
>
>
> --
> To unsubscribe, e-mail: dev-unsubscribesymfony-project.com
> For additional commands, e-mail: dev-helpsymfony-project.com
>


--
To unsubscribe, e-mail: dev-unsubscribesymfony-project.com
For additional commands, e-mail: dev-helpsymfony-project.com

It takes around 12 hours for a message to find its way on
that  
mailing list...

I'd rather discuss on a good old forum: searchable,
archivable, rss- 
able.

What about opening a dev board in the forum?

cheers,

== Olivier

--
To unsubscribe, e-mail: dev-unsubscribesymfony-project.com
For additional commands, e-mail: dev-helpsymfony-project.com

I have actually implemented it. It is shorter and more
elegant than  
the current function. It does not break BC and allows more
logical  
expressions, so i think i will commit it. 

cheers!

== Olivier

Le 3 oct. 06 à 10:04, chtito a écrit :

> Here is an idea. We could agree on the convention that
one switches  
> from AND to OR for each depth in the array. In the
current  
> implementation one starts with AND and then switch to
OR, but why  
> not go further? Your statement would thus become:
> [[root, admin, editor, [supplier, owner], [supplier,
group],  
> accounts]]
>
> Here is another example:
> root OR (supplier AND (owner OR quasiowner)) OR
accounts
> would become:
> [[root, [supplier, [owner, quasiowner]], accounts]]
>
> That approach has several advantages:
> - it covers all the basic needs (i think)
> - it does not break BC
> - it should be fairly easy to implement.
>
> cheers!
>
> == Olivier
>
> Le 2 oct. 06 à 12:10, Joe Simms a écrit :
>
>> Hey olivier
>>
>> Thanks for useful insight, at least i know how it
is possible and  
>> can be implemented, but that is really gonna take
some crunching  
>> everytime i need to write a credential!
>>
>> Maybe, to prevent BC issues, we could add an
additional layer of a  
>> credential string:
>>
>>>> root OR admin OR editor OR (supplier AND
owner) OR (supplier AND  
>>>> group) OR accounts
>>
>> This then gets converted into the appropriate array
required by  
>> the existing system.
>>
>> So in a nutshell, if the credential is a string it
tries to parse  
>> this into the array property required by symfony,
but if it is an  
>> array it simply uses the existing system.
>>
>> So, how do we convert a string into this array
structure required  
>> by symfony???? I haven't a clue yet? maybe explode
OR, check for  
>> brackets in each element, check for ANDS, if AND,
explode ands,  
>> and then do some fancy loop to create arrays.
Ummmmmm??
>>
>> Anyone else any other ideas?
>>
>> Thanks
>>
>> Joe
>>
>>
>> On 2 Oct 2006, at 10:01, chtito wrote:
>>
>>> It is mathematically possible to write any
logical expression  
>>> with the current implementation, although it
would get redundant  
>>> and thus awkward to write. It is based on the
following logical  
>>> property: a⋁(b⋀c) = (a⋁b)⋀(a⋁c), so
"a OR (b AND c)" can  
>>> be coded as "[[a, b], [a, c]]".
>>>
>>> Your statement could be implemented using the
following identity,  
>>> derived from the property above:
>>> a⋁b⋁c⋁(d⋀e)⋁(f⋀g)⋁h =
(a⋁b⋁c⋁d⋁f⋁h)⋀ 
>>>
(a⋁b⋁c⋁d⋁g⋁h)⋀(a⋁b⋁c⋁e⋁f⋁h)⋀ 
>>> (a⋁b⋁c⋁e⋁g⋁h)
>>>
>>> So although theoretically all logical
expression can be coded  
>>> with the current system i wholeheartedly agree
that it is not  
>>> flexible enough, although i'm not sure what
would be the best  
>>> solution.
>>>
>>> cheers!
>>>
>>> == Olivier
>>>
>>> Le 2 oct. 06 à 10:43, Joe Simms a écrit :
>>>
>>>> Hi dev
>>>>
>>>> Having had the need to recently use the
fine grain credential  
>>>> control i find it a little unintuitive and
a little restrictive,  
>>>> i feel that we should allow for normal
logical syntax of AND, OR  
>>>> with brackets to map real life scenarios,
such as:
>>>>
>>>> root OR admin OR editor OR (supplier AND
owner) OR (supplier AND  
>>>> group) OR accounts
>>>>
>>>> currently, the above i do not think is
possible with existing  
>>>> syntax, please can someone help if it is.
>>>>
>>>> Is this likely to change for the 1.0
release, even if the  
>>>> current rules were reversed and so [admin,
root] was admin OR  
>>>> root, and [root, admin, [suppler, owner]]
meant root OR admin OR  
>>>> (supplier AND owner) ???
>>>>
>>>> I realise that this will break BC, but
currently the logic that  
>>>> handles this i believe is very restricting.
>>>>
>>>> Please correct me if the above statement
can be implemented with  
>>>> the existing syntax.
>>>>
>>>> Many thanks
>>>>
>>>> Joe
>>>>
>>>> --
>>>> To unsubscribe, e-mail: dev-unsubscribesymfony-project.com
>>>> For additional commands, e-mail:
dev-helpsymfony-project.com
>>>>
>>>
>>>
>>> --
>>> To unsubscribe, e-mail: dev-unsubscribesymfony-project.com
>>> For additional commands, e-mail: dev-helpsymfony-project.com
>>>
>>
>>
>> --
>> To unsubscribe, e-mail: dev-unsubscribesymfony-project.com
>> For additional commands, e-mail: dev-helpsymfony-project.com
>>
>
>
> --
> To unsubscribe, e-mail: dev-unsubscribesymfony-project.com
> For additional commands, e-mail: dev-helpsymfony-project.com
>


--
To unsubscribe, e-mail: dev-unsubscribesymfony-project.com
For additional commands, e-mail: dev-helpsymfony-project.com

On 10/03/06 chtito wrote:
> It takes around 12 hours for a message to find its way
on that 
> mailing list...
> 
> I'd rather discuss on a good old forum: searchable,
archivable, 
> rss-able.
> 
> What about opening a dev board in the forum?
> 

I hate forum based stuff, and would much rather a mailing
list.  I think
the solution is to use a faster list solution if this list
is slow -
please don't take my dev list away of distil it with online
forums!! 


-- 
Ian P. Christian ~ http://pookey.co.uk

I agree with pookey. I really don't like forums.

What about moving symfony MLs to google groups? It is quite
easy to 
subscribe, search and you have both the advantages of MLs
and of more 
traditional forums.

Fabien

Ian P. Christian wrote:
> On 10/03/06 chtito wrote:
>> It takes around 12 hours for a message to find its
way on that 
>> mailing list...
>>
>> I'd rather discuss on a good old forum: searchable,
archivable, 
>> rss-able.
>>
>> What about opening a dev board in the forum?
>>
> 
> I hate forum based stuff, and would much rather a
mailing list.  I think
> the solution is to use a faster list solution if this
list is slow -
> please don't take my dev list away of distil it with
online forums!! 
> 
> 

--
To unsubscribe, e-mail: dev-unsubscribesymfony-project.com
For additional commands, e-mail: dev-helpsymfony-project.com

Joe, Olivier,

I've commited Joe patch in r2295 with some unit tests based
on your 
examples. It seems to work fine and it does not break BC.

Thanks for that,
Fabien

Joe Simms wrote:
> Chtito/Fabien
> 
> I've supplied a patch in r2294, in my branch, that
implements this.
> 
> Could you be so kind as to take a look and maybe run
some tests, i have 
> run some and it seems to work well (attached).
> 
> Fabien, could this be commited to trunk, it doesn't
break BC? However, i 
> am on a tight deadline and don't have time to learn the
new testing 
> framework, especially without docs, so would you mind
in the next week 
> or so if i commit some small patches without tests
until some brief docs 
> are published or i have some more time to get on top of
this new 
> feature. Hope you understand.
> 
> 
>
------------------------------------------------------------
------------
> 
> <?php
> 
> /**
>  * credentials actions.
>  *
>  * package    test
>  * subpackage credentials
>  * author     Your name here
>  * version    SVN: $Id: actions.class.php 1814
2006-08-24 12:20:11Z fabien $
>  */
> class credentialsActions extends sfActions
> {
>   /**
>    * Executes index action
>    *
>    */
>   public function executeSetup()
>   {
>     $this->getUser()->setAuthenticated(true);
>     $this->getUser()->addCredential('admin');
>     $this->getUser()->addCredential('supplier');
>     $this->getUser()->addCredential('owner');
>     
>     $this->setTemplate('index');
>   }
>   
>   /**
>    * Executes test1 action
>    *
>    */
>   public function executeTest1()
>   {
>      $this->setTemplate('index');     
>   }
> 
>   /**
>    * Executes test1 action
>    *
>    */
>   public function executeTest2()
>   {
>      $this->setTemplate('index');     
>   }
> 
>   /**
>    * Executes test1 action
>    *
>    */
>   public function executeTest3()
>   {
>      $this->setTemplate('index');     
>   }
> 
>   /**
>    * Executes test1 action
>    *
>    */
>   public function executeTest4()
>   {
>     $this->setTemplate('index');      
>   }
> }
> 
> 
>
------------------------------------------------------------
------------
> 
> 
> Thanks
> 
> Joe
> 
> On 3 Oct 2006, at 09:04, chtito wrote:
> 
>> Here is an idea. We could agree on the convention
that one switches 
>> from AND to OR for each depth in the array. In the
current 
>> implementation one starts with AND and then switch
to OR, but why not 
>> go further? Your statement would thus become:
>> [[root, admin, editor, [supplier, owner],
[supplier, group], accounts]]
>>
>> Here is another example:
>> root OR (supplier AND (owner OR quasiowner)) OR
accounts
>> would become:
>> [[root, [supplier, [owner, quasiowner]], accounts]]
>>
>> That approach has several advantages:
>> - it covers all the basic needs (i think)
>> - it does not break BC
>> - it should be fairly easy to implement.
>>
>> cheers!
>>
>> == Olivier
>>
>> Le 2 oct. 06 à 12:10, Joe Simms a écrit :
>>
>>> Hey olivier
>>>
>>> Thanks for useful insight, at least i know how
it is possible and can 
>>> be implemented, but that is really gonna take
some crunching 
>>> everytime i need to write a credential!
>>>
>>> Maybe, to prevent BC issues, we could add an
additional layer of a 
>>> credential string:
>>>
>>>>> root OR admin OR editor OR (supplier
AND owner) OR (supplier AND 
>>>>> group) OR accounts
>>>
>>> This then gets converted into the appropriate
array required by the 
>>> existing system.
>>>
>>> So in a nutshell, if the credential is a string
it tries to parse 
>>> this into the array property required by
symfony, but if it is an 
>>> array it simply uses the existing system.
>>>
>>> So, how do we convert a string into this array
structure required by 
>>> symfony???? I haven't a clue yet? maybe explode
OR, check for 
>>> brackets in each element, check for ANDS, if
AND, explode ands, and 
>>> then do some fancy loop to create arrays.
Ummmmmm??
>>>
>>> Anyone else any other ideas?
>>>
>>> Thanks
>>>
>>> Joe
>>>
>>>
>>> On 2 Oct 2006, at 10:01, chtito wrote:
>>>
>>>> It is mathematically possible to write any
logical expression with 
>>>> the current implementation, although it
would get redundant and thus 
>>>> awkward to write. It is based on the
following logical property: 
>>>> a⋁(b⋀c) = (a⋁b)⋀(a⋁c), so "a
OR (b AND c)" can be coded as "[[a, b], 
>>>> [a, c]]".
>>>>
>>>> Your statement could be implemented using
the following identity, 
>>>> derived from the property above:
>>>> a⋁b⋁c⋁(d⋀e)⋁(f⋀g)⋁h = 
>>>>
(a⋁b⋁c⋁d⋁f⋁h)⋀(a⋁b⋁c⋁d⋁g⋁h)⋀(a⋁b�
�c⋁e⋁f⋁h)⋀(a⋁b⋁c⋁e⋁g⋁h)
>>>>
>>>> So although theoretically all logical
expression can be coded with 
>>>> the current system i wholeheartedly agree
that it is not flexible 
>>>> enough, although i'm not sure what would be
the best solution.
>>>>
>>>> cheers!
>>>>
>>>> == Olivier
>>>>
>>>> Le 2 oct. 06 à 10:43, Joe Simms a écrit :
>>>>
>>>>> Hi dev
>>>>>
>>>>> Having had the need to recently use the
fine grain credential 
>>>>> control i find it a little unintuitive
and a little restrictive, i 
>>>>> feel that we should allow for normal
logical syntax of AND, OR with 
>>>>> brackets to map real life scenarios,
such as:
>>>>>
>>>>> root OR admin OR editor OR (supplier
AND owner) OR (supplier AND 
>>>>> group) OR accounts
>>>>>
>>>>> currently, the above i do not think is
possible with existing 
>>>>> syntax, please can someone help if it
is.
>>>>>
>>>>> Is this likely to change for the 1.0
release, even if the current 
>>>>> rules were reversed and so [admin,
root] was admin OR root, and 
>>>>> [root, admin, [suppler, owner]] meant
root OR admin OR (supplier 
>>>>> AND owner) ???
>>>>>
>>>>> I realise that this will break BC, but
currently the logic that 
>>>>> handles this i believe is very
restricting.
>>>>>
>>>>> Please correct me if the above
statement can be implemented with 
>>>>> the existing syntax.
>>>>>
>>>>> Many thanks
>>>>>
>>>>> Joe
>>>>>
>>>>> -- 
>>>>> To unsubscribe, e-mail:
dev-unsubscribesymfony-project.com
>>>>> For additional commands, e-mail:
dev-helpsymfony-project.com
>>>>>
>>>>
>>>>
>>>> -- 
>>>> To unsubscribe, e-mail: dev-unsubscribesymfony-project.com
>>>> For additional commands, e-mail:
dev-helpsymfony-project.com
>>>>
>>>
>>>
>>> -- 
>>> To unsubscribe, e-mail: dev-unsubscribesymfony-project.com
>>> For additional commands, e-mail: dev-helpsymfony-project.com
>>>
>>
>>
>> -- 
>> To unsubscribe, e-mail: dev-unsubscribesymfony-project.com
>> For additional commands, e-mail: dev-helpsymfony-project.com
>>
> 
> 
> 
>
------------------------------------------------------------
------------
> 
> --
> To unsubscribe, e-mail: dev-unsubscribesymfony-project.com
> For additional commands, e-mail: dev-helpsymfony-project.com


--
To unsubscribe, e-mail: dev-unsubscribesymfony-project.com
For additional commands, e-mail: dev-helpsymfony-project.com