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

Party Information Framework

From TYPO3Wiki
Jump to: navigation, search
This page belongs to the Framework for all partner-related issues project (category Project)
Party information framework.jpg

Main editor:
Project status:

Party Information Framework
David Brühlmeier
Franz Holzinger is the project maintainer.

notice - Open Content License

This document is published under the Open Content License

The content is related to TYPO3 - a GNU/GPL CMS/Framework available from

The Party Information Framework is a project for the management of party-related data. This project was formerly called Partner Framework. Why the name changed


18.06.2011: move the tests into the new extension party_tests.

10.02.2011: experimental version 0.1.0 published on TYPO3 TER.

30.09.2010: experimental version 0.0.1 published on TYPO3 TER.

30.09.2010: The project was taken over by Franz Holzinger. Subversion is at

10.03.2008: The project was taken over by the Web Empowered Church (WEC) and is now called wec_people. Christoph Koehler (christoph(at)webempoweredchurch(dot)com) is the lead developer. Please refer to the WEC Trac Site for more information.

27.04.2007: Presentation of the current status and discussion at the TYPO3 Developer Days

05.04.2007: Added the new logo of the project.

26.02.2007: Added work packages to all components. If you are interested, please join us in the development!

25.02.2007: Update of class model to 0.30 (PNG)

18.01.2007: Update of class-model to 0.20

15.01.2007: See proposal for the class model It is based on the current version 3.0 of xPIL/xNAL, which is still in draft state. It is expected to be published as final in Q1/2007, so I will update the model later with any changes that might still occur.

For the core extension tx_party, I would like to stay as close to the standard as possible. If the need arises for further classes and/or attributes, I would like to encapsulate those in extra extensions.

I would like to invite you to give feedback on the class model. Please pay special attention to the cardinalities and the completeness of all classes/attributes. What did I miss or misinterpret from the standard? Please note that all the classes are linked to the according xPIL/xNAL elements (click on the class and choose 'file').

The next step will be to build a first version of the data model based on TYPO3 4.1, according to the class model.

Development will be public, I have created a new folder on typo3xdev:

Greetings, Dave (newsgroup)

08.01.2007: You are invited to cast your vote about the future development of the Party Information Framework on the ECT Mailing List.


Definition of a Party

Party is the umbrella term for persons and organizations (e.g. companies, associations, teams, etc.). It has nothing to do with some sort of a celebration... :-)


The Party Information Framework is the central extension in TYPO3 to manage all party-related data (such as names, addresses, e-mail addresses, phone numbers, relationships between parties, etc.).

How can this be useful to me?

Check out this scenario which explains how the Party Information Framework can help you.


  • Quality
    We want to use unit-testing, publish early and often and strictly adhere to CGL
  • Versatility
    The framework must be flexible enough to suit the needs of all extensions using party-data
  • Sustainability
    The framework must be written an maintained by a team, not a one-man show

Issues with the current situation

  • Redundancy
    One problem is that there is no central place in TYPO3 which holds party data. Frontend-users are persons and thus parties, they are saved in fe_users. Backend-users are persons as well, they are saved in be_users. Both tables hold an e-mail address, for instance. If a person is both, a frontend- and a backend-user, his e-mail address is saved twice. If the same person has also subscribed to a newsletter, chances are that his e-mail address is saved for the third time, this time in tt_address.
  • Data model
    The data model of tt_address does not comply with common standards for names and addresses. For instance, there is just one 'name' field, which holds the first, the middle and the last name. This makes it impossible to build a proper address handling, where for instance an application would like to address its customers by their last name only. On top of that, many importants fields of a party - such as the birthday of a person, for instance - are missing.
  • Wide range of extensions
    Due to these facts, there are many extensions trying to improve the situation. Many of them are really good, but the problem is that most of them cover just one aspect and none of them solves to problem as a whole. This makes it impossible for instance to build a solid frontend extension for party-data. For new extensions needing party-data, it is very difficult to decide which solution to build on.


  • In scope of the Party Information Framework is the management of all party-related data.
  • Out of scope are, in particular
    • User Management (e.g. the project is not about combining backend- with frontend users. It will, however, provide solutions to remove redundant party-related data from the users tables, such as the e-mail address)
    • Personalized content (This might be a possible use of the framework, but it is not part of the framework itself)


  • TYPO3 5.0
    The framework is built with the goal of becoming a package of TYPO3 5.0. We surely will support the 4.0 string, especially while 5.0 has not yet been released, but the development focuses on the support of 5.0.
  • OASIS xPIL 3.0 and xNAL 3.0
    We are building on the OASIS standards wherever possible, e.g. the data and the object model follow the standard. The OASIS CIQ V3.0 Committee Specification has been released in November 2007. OASIS CIQ TC FAQ


Core - party

The core is the base for all other party extensions. It contains only the model (with the exception of the basic backend-module). The model is basically an object-oriented API (based on lib/div) to access all data and methods of the framework.

Tests - party


View - party_view

This extension is the 'View' layer of the framework. It contains the view- and controller functions. It can be used to display party-data in the Frontend, but it also contains all the rendering methods e.g. to render an address in a country-specific way.

Syncronizing - party_sync

The syncronization module is in charge of exchanging party-data with other clients, such as another TYPO3 table (e.g. tt_address), other extensions or other systems outside TYPO3.

Reporting - party_reporting

The reporting extension provides all functionality to create reports for party-data or to prepare statistical data.

Migration - party_migration

This extension holds all tools necessary to migrate data to the party information framework.


Please feel free to add feature requests to this wishlist and write an email. We can then decide into which module the feature belongs and how it can be included into the roadmap.


The Roadmap is split to the different components of the Framework. We are currently working on Phase 1.

We have deliberately decided not to commit on any specific dates yet. We will do that as a community effort as soon as the development of the core component has actually started.

Related extensions / projects

Extension to potentially integrate

These extensions are candidates to be integrated into the new party information framework. The goal is to get as many extension developers together to work on the same framework with the long-term vision to drastically reduce the number of extension.

  • tt_address
    The most obvious candidate. The full functionality should be moved to the new party information framework
  • direct_mail_subscription
    Currently, the direct mail subscriptions are saved in extension fields of tt_address. There are two solutions: (1) Integrate it into the party information framework (possibly still as an extension) or (2) move it to the fe_users table (quite certainly as an extension). What should definitely be changed is the way the categories are saved on the database (currently a binary value).
  • sp_directory
    Could probably be completely integrated into party_view.
  • partner
    Many concepts can be used as a basis for the new party information framework and the complete functionality could be integrated, so the extension could become obsolete.
  • partner_fe
    Could be part of party_view and then become obsolete.
  • sa_addressexport
    Could probably be completely integrated into the framework.
  • gb_newsletter
    Could be adapted to use the party information framework in the long run, in the meantime it could still use tt_address which can be syncronized using party_sync.
  • sg_address
    Details need to be checked, but it seems like a perfect fit for the party information framework.
  • ast_addresszipsearch
    Could probably be completely integrated in partner_view.
  • m1address_us
    Could be completely integrated in the core (the state-field is part of the core data model)
  • cl_company_database
    Could probably be completely integrated into the Framework.
  • csextfeadr
    Could be completely integrated in the core (the additional fields are part of the party data model and the field visibilty concept for the frontend should also be part of the core).
  • address
    Could become part of the core API or partner_sync (maps to CSV format)
  • rs_userimp
    Could serve as the basis for all import/migration functionality
  • dmaddredit
    Could probably be integrated in the party information framework.
  • emailimport
    Could probably be integrated in the import/migration functionality
  • dubletfinder
    Could be the basis for an integrated tool for finding and managing duplicate party records.
  • icr_be_addr_dmail_cat
    See comment of Direct Mail Subscription
  • kj_tt_address_mailflag
    Might be worth to integrate in the core party data-model, especially since the format in which the party wants to receive his mails might also need to be available for other clients than direct_mail.
  • contactslist
    Could probably be completely integrated into the party information framework.
  • sg_userdata
  • eu_birthdays
    Adds a birthday-field for a Frontend-User and lists the birthdays on the Frontend. The birthdate is an attribute of the person, the list could be part of party_view.
  • bzd_staff_directory
    Listing of staff members


Other relating projects to Party Information Framework (edit this, in alphabetical order)

  • Commerce Shop Extension This extension use an 1:N relation for addresses and included an own addressmanagement, which should be part of the Party Information Framework.
  • Enhanced Rights Management - a pear class for a RBAC / Role Based Access Control.
  • Inline Relational Record Editing - 1:n relations for BackEnd-Forms -- Oliver Hader
  • Newloginbox development coordination - Ingmar Schlecht and Stefan Strasser
    The User list plugin (pi3) of Newloginbox is related to the Party Framework. If the Party Framework will ship with a user listing plugin, the pi3 of Newloginbox wouldn't be needed any more.
  • Users Addresses - relations between fe_user and tt_address, best practice discussion - Elmar Hinz
  • dkd_feuser_belogin - relation between fe_user and be_user

Current Project Members

Are you an extension developer using party-functionality or are you interested in this project in any other way? Please contact Dave or any other member of the project team and join in!

-- Franz Holzinger 11:25, 3 April 2011 (CEST)