All page names need to be in English.
en da  de  fr  it  ja  km  nl  ru  zh

Party Information Framework Scenario

From TYPO3Wiki
Jump to: navigation, search
This page belongs to the Extension coordination team (category ECT)
This page belongs to the Framework for all partner-related issues project (category Project)
Components of the Party Information Framework
Core tx_party | View tx_party_view | Syncronizing tx_party_sync | Reporting tx_party_reporting | Migration tx_party_migration

Why use the Party Information Framework?

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.