When a site builder is reliably available for a given site, the creation of custom fields is typically the best way to track additional data for Contacts, Relationships, and other CRM content (leads, opportunities, campaigns, events, cases, etc.).
However, realistically (e.g. due to limited budget), many organizations will have a developer or site builder set up their CRM once and provide minimal/infrequent support on an ongoing basis, which might not include implementing new functionality including fields.
Thus, it often falls on the end users of the CRM (who are not site builders and can't manage configuration) to maintain and categorize its data.
This must be done in the realm of content (as opposed to configuration) and thus can't involve adding fields or even configuring additional taxonomies.
A flexible, scalable, structured, user-managed tagging system could meet some of the needs of these end users.
Many CRMs offer tagging capabilities as a core offering. Drupal CRM should too.
Create an Internal field crm_relationship_statistics.
Relationships have labels for each side. These can be used to 'tag' contacts.
When a relationship is created, or when one the contact references on the relationship is changed the crm_relationship_statistics values are updated.
Create a Field Type for crm_relationship_statistics.
There is no Field Widget since the values are created/update in response to crm_relationship entities being created/updated.
The Field type, if possible, should be compatible with existing list formatters. hook_field_formatter_info_alter(). This may require the relationship type field column being name value.
crm_relationship_statistics
there are two columns. The first is for the relationship type, and the second is for the current count. If someone has two children, they will have a parent and a count of two.
Relationships can be symmetrical or asymmetrical. When the relationship type is symmetrical the machine_name is stored. When the relationship type is asymmetrical the machine_name:a or machine_name:b is stored. When renderd, it should be the label of the corresponding
Add a crm_relationship_statistics field to the base crm_contact entity.
The field should be configurable for the entity view, but should not be configurable for the edit form. It should always be hidden on the edit form.
Show commandsStart within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
changes
Comments
Comment #2
jdleonardJust a quick note that I'd advocate for the use of Tagify as a modern accessible solution (adopted by Drupal CMS) for handling tagging UX.
Aside: this could also be used for entity reference fields targeting Contacts and we could implement a Tagify CRM Contact List module in the same vein as Tagify User List to provide a rich experience:
Comment #3
bluegeek9 commentedWhich vocab(s) do we use?
Would Tagify be a dependency or a dev dependency?
Comment #4
jdleonardIMO the most flexible and powerful tagging system would allow a site builder to manage multiple vocabularies for tagging, including to which entity types and bundles each can apply. This idea is only half-baked...
There could also be one default vocabulary (for each entity type?) for tags that don't require additional context/grouping that could support free-tagging. I'm not convinced it would be best to use Drupal's built-in concept of vocabulary (probably doesn't need to be fieldable, revisionable, or mixed in with the various non-CRM tag vocabs).
I'm also thinking of mutually exclusive labels e.g. GitLab's Scoped Labels.
Examples that a site builder might create:
Probably worth some discussion whether a (non-dev) dependency like Tagify be adopted by CRM. Alternatively there could be a more opinionated, dependency-heavy "CRM Starter" kit that adds these sorts of things, leaving CRM itself very low dependency. Feels like an overall policy would be helpful so that each such thing doesn't require a bespoke debate.
Comment #5
bluegeek9 commentedI think we should talk about sub-bundles/sub-types, and how they can fill the same role, and better than taxonomy terms.
This makes sense.
I am unsure I understand this one. If it is the Eldest child in a household, should this be computed instead of a static tag?
Comment #6
bluegeek9 commentedComment #7
bluegeek9 commentedComment #8
jdleonardRe-opening assigned to me so I can flesh this out.
Comment #9
bluegeek9 commentedIs it possible to make the integration optional?
It is possible that site builders might not have Taxonomy installed, but I am also concerned about the automated tests. It will increase the time and complexity of the tests.
#3540527: Integration: comment
Comments seems easier to make optional as it is its own tab.
Comment #10
jdleonardYes, I think tagging could be optional. I think we should probably have a more robust discussion about criteria for what functionality is required vs. optional (ships with CRM project) vs. separate project and how recipes fit in.
Comment #11
bluegeek9 commentedHi @JDLeonard,
Can you provide more details on what you wish to implement?
Comment #12
jdleonardUpdated IS with my first stab at a rough proposal.
Comment #13
bluegeek9 commentedComment #14
bluegeek9 commentedComment #17
bluegeek9 commented