You are here

Home » API reference » Party 8.2

README.txt in Party 8.2

Same filename in this branch
  1. 8.2 README.txt
  2. 8.2 starterkits/party_starterkit_b2b/README.txt
  3. 8.2 starterkits/party_starterkit_b2b/party_starterkit_b2b_migrate/README.txt
Same filename and directory in other branches
  1. 7 README.txt
Introduction
------------

The Party module provides an extremely flexible CRM solution for Drupal, utilizing
a generic entity (the Party entity) to which other entities (Drupal Users, Nodes,
Profile2 profiles, eCommerce customers, Facebook profiles, etc.) can be attached.

Requirements
------------

PHP 5.3
Drupal greater than 7.14
Dependencies:
 - Entity API
 - CTools
 - Views

Installation
------------

Install and enable the Party module as usual.
For a typical installation, the following Party sub-modules should be enabled:
Party Hat, Party Profile, Party User.

Overview
========

What follows is a brief overview of some of the concepts used in Party. For
more detail, see the Party documentation at http://drupal.org/node/1600330.

The Party
---------

The Party entity is simply a wrapper around other entities representing whatever,
e.g. a Drupal User, CiviCRM Constituent, Facebook account, eCommerce Customer,
Employee profile, etc. A Party may wrap one or more such entities.

A Party can represent an individual or an organization (multiple individuals).
Entity relations are typically used for managing the individual/organization relationship.

A Party entity does not have bundles and normally has no fields, except those used
by the core Party module for tracking the entity attachments, or special purpose
custom modules that enhance party core.


Data Sets
---------

Data sets define where a Party's data is stored. A data set specifies a particular
entity type which may be connected to a party. This may be an entity type provided
by another module, or one defined along with the data set.

Party provides submodules that define data sets for:

- profile2, one data set per type
- user accounts
- commerce module customer profiles

Hats
----

Instead of having bundles, a party can have multiple hats, which can be changed
over time. Each hat allows the party to use one of more data sets.

Hats are organized in hierarchies, with the root level of the hierarchy
normally being occupied by either the 'Group' Hat or 'Individual' Hat. Hats can
be created in code or through the Party UI.

A hat hierarchy for a library might look like:

Individual
--Library Patron
--Donor
--Employee
----Exempt Employee
----Non-exempt Employee
----Volunteer Employee
Group
--Publisher
----Periodicals Publication Publisher
----Books Publication Publisher
----Reference Publications Publisher
--Department
----Administration
----Circulation
----Information Technology
----Legal
----Accounting
----HR

Party Labels
------------

When a party is created in the system, whether manually or programmatically, a
label is generated for it. It is possible to specify how this label is generated
by configuring any number of 'Party Name Label' plugins. Under 'Label Plugins'
in the Party configuration menu, you can sort and modify settings for these
plugins. For example, the 'attached entity field' label plugin will allow you
to use a field from a data set to use for the label - thus a 'Name' field on an
attached profile2 entity could be used. The sorting allows you to choose in
which order these labels are applied - thus, for parties that do not have
attached users, username will not work, but the pid example will.

To create your own Party Label plugins, refer to the Developer Documentation Section.

File

README.txt
View source 
  1. Introduction

  2. ------------

  3. 

  4. The Party module provides an extremely flexible CRM solution for Drupal, utilizing

  5. a generic entity (the Party entity) to which other entities (Drupal Users, Nodes,

  6. Profile2 profiles, eCommerce customers, Facebook profiles, etc.) can be attached.

  7. 

  8. Requirements

  9. ------------

  10. 

  11. PHP 5.3

  12. Drupal greater than 7.14

  13. Dependencies:

  14.  - Entity API

  15.  - CTools

  16.  - Views

  17. 

  18. Installation

  19. ------------

  20. 

  21. Install and enable the Party module as usual.

  22. For a typical installation, the following Party sub-modules should be enabled:

  23. Party Hat, Party Profile, Party User.

  24. 

  25. Overview

  26. ========

  27. 

  28. What follows is a brief overview of some of the concepts used in Party. For

  29. more detail, see the Party documentation at http://drupal.org/node/1600330.

  30. 

  31. The Party

  32. ---------

  33. 

  34. The Party entity is simply a wrapper around other entities representing whatever,

  35. e.g. a Drupal User, CiviCRM Constituent, Facebook account, eCommerce Customer,

  36. Employee profile, etc. A Party may wrap one or more such entities.

  37. 

  38. A Party can represent an individual or an organization (multiple individuals).

  39. Entity relations are typically used for managing the individual/organization relationship.

  40. 

  41. A Party entity does not have bundles and normally has no fields, except those used

  42. by the core Party module for tracking the entity attachments, or special purpose

  43. custom modules that enhance party core.

  44. 

  45. 

  46. Data Sets

  47. ---------

  48. 

  49. Data sets define where a Party's data is stored. A data set specifies a particular

  50. entity type which may be connected to a party. This may be an entity type provided

  51. by another module, or one defined along with the data set.

  52. 

  53. Party provides submodules that define data sets for:

  54. 

  55. - profile2, one data set per type

  56. - user accounts

  57. - commerce module customer profiles

  58. 

  59. Hats

  60. ----

  61. 

  62. Instead of having bundles, a party can have multiple hats, which can be changed

  63. over time. Each hat allows the party to use one of more data sets.

  64. 

  65. Hats are organized in hierarchies, with the root level of the hierarchy

  66. normally being occupied by either the 'Group' Hat or 'Individual' Hat. Hats can

  67. be created in code or through the Party UI.

  68. 

  69. A hat hierarchy for a library might look like:

  70. 

  71. Individual

  72. --Library Patron

  73. --Donor

  74. --Employee

  75. ----Exempt Employee

  76. ----Non-exempt Employee

  77. ----Volunteer Employee

  78. Group

  79. --Publisher

  80. ----Periodicals Publication Publisher

  81. ----Books Publication Publisher

  82. ----Reference Publications Publisher

  83. --Department

  84. ----Administration

  85. ----Circulation

  86. ----Information Technology

  87. ----Legal

  88. ----Accounting

  89. ----HR

  90. 

  91. Party Labels

  92. ------------

  93. 

  94. When a party is created in the system, whether manually or programmatically, a

  95. label is generated for it. It is possible to specify how this label is generated

  96. by configuring any number of 'Party Name Label' plugins. Under 'Label Plugins'

  97. in the Party configuration menu, you can sort and modify settings for these

  98. plugins. For example, the 'attached entity field' label plugin will allow you

  99. to use a field from a data set to use for the label - thus a 'Name' field on an

  100. attached profile2 entity could be used. The sorting allows you to choose in

  101. which order these labels are applied - thus, for parties that do not have

  102. attached users, username will not work, but the pid example will.

  103. 

  104. To create your own Party Label plugins, refer to the Developer Documentation Section.