Party Information Framework

From TYPO3Wiki

This project/information is related to the Extension coordination team

List Projects	The Framework for all partner-related issues-project list pages	See Current Project Members, Wishlist
		you can help if you like!

Title:
Main editor:
Project status:

Party Information Framework
David Brühlmeier
Stopped. The project was taken over by the Web Empowered Church.

This document is published under the Open Content License

The content is related to TYPO3 - a GNU/GPL
CMS/Framework available from www.typo3.com

The Party Information Framework is an ECT (Extension Coordination Team) project for the management of party-related data. This project was formerly called Partner Framework. Why the name changed

[edit] News

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:

http://typo3xdev.svn.sourceforge.net/viewvc/typo3xdev/tx_party/

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.

[edit] Basics

[edit] 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... :-)

[edit] Vision

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.).

[edit] How can this be useful to me?

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

[edit] Values

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

[edit] 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.

[edit] Scope

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)

[edit] Standards

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.
PHP5
The framework will be built using PHP5. So even if you run it on TYPO3 4.0, you will be required to use PHP5.
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. Currently, the version 3.0 is not yet finalized, so minor changes are still possible and will be included in the framework.

[edit] Components

[edit] Core - party

tx_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.

[edit] View - party_view

tx_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.

[edit] Syncronizing - party_sync

tx_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.

[edit] Reporting - party_reporting

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

[edit] Migration - party_migration

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

[edit] Wishlist

Please feel free to add feature requests to this wishlist and discuss it on the ECT mailing list. We can then decide into which module the feature belongs and how it can be included into the roadmap.

for phase 3: Is PEAR::LiveUser good for Rights Management? (See Enhanced Rights Management) --Daniel Brüßler 13:06, 28 February 2007 (CET)

[edit] 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.

[edit] Project Team Meetings

We should plan some regular project meetings (will be discussed on the mailing list).

Here's a map of germany, another idea is to use quikmaps to find a good meeting-point.

[edit] Related extensions / projects

[edit] 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

[edit] Extensions for Cooperation

Calendar Base - cal
Currently using tt_address for organizer.
Commerce - commerce
Currently using tt_address.
University Manager - jsh_university
Also has a party-entity, so it might be interesting to coordinate the efforts.

[edit] Relations

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

[edit] 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!

David Brühlmeier, typo3(at)bruehlmeier(dot)com
Elmar Hinz, elmar.hinz(at)team-red(dot)net
Peter Kindström
Norman Seibert, seibert(at)entios(dot)de
David Slayback, dave(at)webempoweredchurch(dot)org
Oliver Klee, typo3-coding(at)oliverklee(dot)de
Oliver Hader, oliver(at)typo3(dot)org
Robert Lemke, robert(at)typo3(dot)org
Olivier Dobberkau olivier.dobberkau(at)dkd(dot)de
Peter Kühn
Sven Kalbhenn, sven(at)skom.de
Andreas Wolf, typo3(at)andreaswolf.info