[TYPO3-ect] tx_party: Let's get started!

[David Toshack]

Daniel Brüßler wrote:
> Hello,
> 
> the diagram looks very good now!
> 
> Yes it's very good to stick to the standard. So it's compatible for
> exchanging data.
> 
> The standard will get better over the time, so there's no problem, when
> some things are not possible in the moment. Only important is to store
> what _version of the standard_ the data is using.
> 
> 
> ++------
> 
> Is it possible to store usernames, usergroups and to create
> sub-usergroups? If not it would be no problem, so the authentication can

Usernames are stored as the primary key: "handle", in the
"liveuser_users" table. Maybe replacing the "handle" primary key with a
"party_id" foreign key would be a good idea.

I would also suggest mapping liveuser_areas to workspaces.

There are 3 different complexity levels the LiveUser and LiveUser_Admin
packages support:
- The liveuser_users table is used for authentication.
1. The "simple permissions" tables (with the green drop shadow) don't
   make use of groups at all. Only users, rights, user permissions on
   those rights, areas associated with those rights, and "applications"
   in those areas. As well as translations, which might be better
   ignored for use of TYPO3 translation functionality.
2. The "medium permissions" tables include the above, along with groups
   and group rights.
3. The "complex permissions" tables includes all of the above, along
   with subgroups, implied rights (rights hierarchy), and admin areas
   associated with users rather than rights.

Check out the colour coded ER diagram on the wiki page[1] for a visual
explanation.


> be indipendent. The authentication-datatable can have a foreign-key to
> the PartyFramework-data so the name wouldn't be double.
> 
> With indipendent auth-data the type-of-authentication can be different
> so even role-based login "RBAC" could be possible.

I like this idea. Making the Party Framework the foundation and the
roles and responsibilities built on top of that. I have just been
looking into the new Zend_ACL component which it seems has only just
made it out of the incubator directory of the Zend Framework SVN trunk
and into the 0.7 preview release[1]! Not sure if the Zend_ACL is the
same as the proposed one but the proposed one offers much more control,
so here's hoping.

This Zend_ACL implementation proposal is based on the 3rd party PHP
authentication web app, PHPGACL[2]. This is a fairly mature ACL
framework compared to LiveUser. I like them both, so to me it is a toss
up between the two.


Cheers,
David

[1]
http://framework.zend.com/fisheye/browse/Zend_Framework/trunk/library/Zend/Acl
[2] http://framework.zend.com/wiki/display/ZFPROP/Zend_Acl+-+Simon+Mundy

> 
> kind regards
> Daniel Brüßler
> 
> 
> 
> 
> David Toshack schrieb:
>> David Bruehlmeier wrote:
>>>> I see a document can belong to a group, would be also good if it belongs
>>>> to a role, too. (Documentation-Writer, Reviewer, System-Administrator,
>>>> Simpsons-Fan)
>>> The OASIS spec doesn't feature a role:
>>> http://www.bruehlmeier.com/tx_party/oasis/xPIL/xPIL.html#simpleType_DocumentElementEnumeration_Link037F4350
>>>
>>>
>>> The core-extension tx_party should stick to the specs as much as possible.
>> I agree with sticking to standards. However, The Party Framework is such
>> a good model for people and organizations it would be a shame not to be
>> able to replace front and backend users with parties.
>>
>> In order to do this, we need to combine some sort of RBAC with the Party
>> Framework. I created a page[1] on the TYPO3 wiki some time ago regarding
>> TYPO3 Enhanced Rights Management through Role Based Access Control.
>> Would this be something we could combine with the Party Framework?
>>
>>
>> Cheers,
>> David
>>
>> [1] http://wiki.typo3.org/index.php/Enhanced_Rights_Management