[TYPO3-ect] Party FW: Status and work packages

[David Bruehlmeier]

Hi Ben,

> 
> I noticed the Party Information Framework earlier and it seems interesting. I
> see a lot of tech stuff in the WIKI, but no real functionality. I would like to
> see something like what this would mean for the TYPO3 user. What could you do
> with this extension? Could you get into some practical/functional stuff?

Imagine a church which is running their website with TYPO3. They are 
very pleased with it (of course :-) but they still have a problem: They 
have a hard time managing their members. In the whole church, they have 
ten different Excel/Access solutions to manage the members, which 
creates a lot of redundancy and which makes it hard e.g. to print labels 
for a mass mailing.

So they decide to start a little project to use Party Information 
Framework instead. A good decision! :-) In the first phase, they just 
want one central user to manage all the data in the backend. They are 
pleased by the single source, by the easy way to enter data and by the 
extensive list of fields which are possible to manage. All of their data 
from the different sources could be uploaded by using party_migration.

One of their members gets married. Not a problem, because the Framework 
can store multiple names per person. Another member has two addresses, 
one home and one vacation address. Not a problem either, the Framework 
can store multiple addresses per party, associated with a usage.

But they want more! They want to know which person is married to whom 
and who are their children. The Framework can handle this easily through 
relationships. The church also has cell groups, which are organized 
hierarchically. Such groups can also be handled by the Framework as 
organisations which in turn can have members through relationships. The 
Framework can also visualize this graphically.

OK, nice. But now the guy in charge of managing all this data thinks 
"Why do I have to enter all these address changes?". Yeah, he's right. 
So the church starts phase 2 and installs party_view. Now the logged-in 
user can change his own data.

Then the church realizes that in many places on their website, they are 
referring to persons who are already in the Party Information Framework! 
So they replace the content elements with references to the respective 
parties which are then rendered nicely (and are always up-to-date) 
through party_view.

All of a sudden, some members complain because they don't want their 
personal data displayed "to the world". But others feel that this is 
just great! What can they do? Easy. They just use the Field Visibility 
Concept of party_view. The administrator decides on the basic set of 
data visible on which level but each member can still decide to override 
this. Nice, isn't it? :-)

After all this work, the church management of course wants to make 
better use of this data. How many members are active in a cell group? 
What is the average age of all members? Well, party_reporting gives the 
answer to these questions.

Nearly perfect, but one problem still remains. The church is using an 
extension which still depends on tt_address (hard to imagine... :-) Not 
really a problem, because party_sync takes care of this and makes sure 
the redundant data from tt_address and the Party Information Framework 
stays consistent.

Wow - neat stuff, isn't it? :-)

I hope this gives you an impression on what the Party Information 
Framework is about.

Greetings,
Dave.