Problem/Motivation

The contacts, relationships, and details are not entities that are really 'published'

Steps to reproduce

Proposed resolution

Remove the EntityPublishedInterface and EntityPublishedTrait

Remaining tasks

User interface changes

API changes

Data model changes

Issue fork crm-3555583

Command icon Show commands

Start 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:

About issue forks

Comments

bluegeek9 created an issue. See original summary.

svendecabooter made their first commit to this issue’s fork.

svendecabooter’s picture

svendecabooter
he/him
Primary language Dutch
Location Gent
commented

Would this also imply removing the "status" base field from these entities?
I can see a use case where we want to mark a specific contact as active or not (i.e. archived).
But that field should probably not be linked to the publication status of the entity, as suggested.
Maybe it should also rather be a list field, so more than 2 entity states can be defined.

svendecabooter’s picture

svendecabooter
he/him
Primary language Dutch
Location Gent
commented

There is also a bunch of logic regarding relationship status:
- Filter on status in RelationshipListBuilder
- \Drupal\crm\Controller\RelationshipController::getActiveRelationships() vs \Drupal\crm\Controller\RelationshipController::getInactiveRelationships()

This should all be removed then?

bluegeek9’s picture

bluegeek9 commented

We still want the status field.

The EntityPublishedInterface and EntityPublishedTrait add methods about published. Contacts still need a status, just not the publish methods.

jdleonard’s picture

jdleonard
he/him
Primary language English
Location Austin, Texas
commented

I agree with the removal of Remove EntityPublishedInterface here.

I don't like the existence of a field named "status". Too many ways it can be interpreted. For many Drupal content entities such as Node, Comment, and Media, it is publish status (EntityPublishedInterface). For User, it is active/blocked. For File, it is temporary/permanent.

Archive status is a great use case. Created a feature request for that: #3557065: Contact/ContactDetail/Relationship can be archived

Whether a Relationship is active is another great use case. Perhaps that base field could be named "active"?

What is "status" supposed to represent for each of Contact, ContactDetail, and Relationship?

bluegeek9’s picture

bluegeek9 commented

I don't like the existence of a field named "status".

Do you not like the machine name, or do you not like the label?

I am unable to find a core entity that does not have a status field.

Excerpts from baseFieldDefinitions().

Taxonomy

    /** @var \Drupal\Core\Field\BaseFieldDefinition[] $fields */
    $fields = parent::baseFieldDefinitions($entity_type);

    // @todo Remove the usage of StatusItem in
    //   https://www.drupal.org/project/drupal/issues/2936864.
    $fields['status']->getItemDefinition()->setClass(StatusItem::class);

User

$fields['status'] = BaseFieldDefinition::create('boolean')
      ->setLabel(t('User status'))
      ->setDescription(t('Whether the user is active or blocked.'))
      ->setDefaultValue(FALSE);
    $fields['status']->getItemDefinition()->setClass(StatusItem::class);

File

    $fields['status'] = BaseFieldDefinition::create('boolean')
      ->setLabel(t('Status'))
      ->setDescription(t('The status of the file, temporary (FALSE) and permanent (TRUE).'))
      ->setDefaultValue(FALSE);

Node

$fields['status']
      ->setDisplayOptions('form', [
        'type' => 'boolean_checkbox',
        'settings' => [
          'display_label' => TRUE,
        ],
        'weight' => 120,
      ])
      ->setDisplayConfigurable('form', TRUE);
jdleonard’s picture

jdleonard
he/him
Primary language English
Location Austin, Texas
commented

Both. "status" is too abstract of a concept. It exists in all these places in Drupal core for legacy reasons. That core does something poorly is not a great reason for us to do something poorly.

Comments #5 and #6 in #2009958: Introduce EntityStatusInterface to standardize how entities can be disabled echo my concerns.

What is "status" supposed to represent for each of Contact, ContactDetail, and Relationship? What use case(s) does it seek to serve?

bluegeek9’s picture

bluegeek9 commented
Assigned: Unassigned » bluegeek9

bluegeek9 opened merge request !112

  • bluegeek9 committed e9944143 on 1.0.x 
    feat: #3555583 Remove EntityPublishedInterface
bluegeek9’s picture

bluegeek9 commented
Assigned: bluegeek9 » Unassigned
Status: Active » Fixed
//www.flaticon.com/free-icons/thank-you Thank you for your contribution! Your continued support makes this project sustainable.
There are multiple ways to show appreciation for the work contributed to this project including:
  • Triage issues and adding more context to existing issues.
  • Flagging CRM as a favorite on the project page to help others discover it and show your support.
  • Review the Developer Docs for accuracy and clarity.

Now that this issue is closed, review the contribution record.

As a contributor, attribute any organization that helped you, or if you volunteered your own time.

Maintainers, credit people who helped resolve this issue.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.