Account created on 24 April 2011, about 14 years ago
#

Merge Requests

More

Recent comments

🇺🇸United States bluegeek9

bluegeek9 changed the visibility of the branch 8.x-1.x to hidden.

🇺🇸United States bluegeek9

If the intention is to have nickname be a part of the individual's base name, it might be better to have nick name as part of the name field. Add more 'parts/fields' to the name Active

Maybe alias is better. Maybe aliases.

🇺🇸United States bluegeek9

I think it is good to be able to lock relationship types.

I don't think any of the current relationships need to be locked.

🇺🇸United States bluegeek9

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

🇺🇸United States bluegeek9

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

🇺🇸United States bluegeek9

I believe this is a duplicate of 📌 Remove "primary" field from Contact Active

The primary on the contact type determines the available bundles for the contact entity.

If one is removed they need to both be removed.

🇺🇸United States bluegeek9

bluegeek9 changed the visibility of the branch 8.x-1.x to hidden.

🇺🇸United States bluegeek9

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

🇺🇸United States bluegeek9

bluegeek9 changed the visibility of the branch 8.x-1.x to hidden.

🇺🇸United States bluegeek9

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

🇺🇸United States bluegeek9

I updated the comment.

🇺🇸United States bluegeek9

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

🇺🇸United States bluegeek9

I made the background transparent. The project page maybe cached.

You can view it hereA https://project.pages.drupalcode.org/crm/

🇺🇸United States bluegeek9

bluegeek9 changed the visibility of the branch 3525637-transparent to active.

🇺🇸United States bluegeek9

bluegeek9 changed the visibility of the branch 3525637-transparent to hidden.

🇺🇸United States bluegeek9

bluegeek9 changed the visibility of the branch 1.0.x to hidden.

🇺🇸United States bluegeek9

bluegeek9 created an issue.

🇺🇸United States bluegeek9

bluegeek9 created an issue.

🇺🇸United States bluegeek9

bluegeek9 created an issue.

🇺🇸United States bluegeek9

New Release message_subscribe 8.x-1.5.

🇺🇸United States bluegeek9

New Release message_subscribe 2.0.1

🇺🇸United States bluegeek9

bluegeek9 created an issue.

🇺🇸United States bluegeek9

I was able to reproduce the error after deleting 'name.generate.examples'.

📌 | Iconset | Add logo
🇺🇸United States bluegeek9
📌 | Iconset | Add logo
🇺🇸United States bluegeek9

Since 2.0.x is the default branch, the changes need to be merged for the logo to appear on the project page.

🇺🇸United States bluegeek9

Updating my organization credit attribute.

🇺🇸United States bluegeek9

Updating my organization credit attribute.

🇺🇸United States bluegeek9

Updating my organization credit attribute.

🇺🇸United States bluegeek9

Updating my organization credit attribute.

🇺🇸United States bluegeek9

Updating my organization credit attribute.

🇺🇸United States bluegeek9

Updating my organization credit attribute.

🇺🇸United States bluegeek9

bluegeek9 changed the visibility of the branch 3196193-remove-boundary-setting to hidden.

🇺🇸United States bluegeek9

bluegeek9 changed the visibility of the branch 8.x-1.x to hidden.

🇺🇸United States bluegeek9

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

🇺🇸United States bluegeek9

I kinda like the idea of the bundle's machine name being the same as the primary field type, as with address and email.

Telephone is better for translation, it is has no other contexts. Phone is used in Anglophone. Francophone, etc.

🇺🇸United States bluegeek9

We should get rid of the uid column. We should consider retaining the status field.

The Contact Details, email/telephone/address can all be temporarily unavailable. I can also see scenarios were the contact detail is no longer correct, but you do not want to delete it; to have a last known address/email/telephone bit also indicate that it should not be used.

I think this will be useful in more advanced features like mailing, auto dialer, or email campaign.

The Contact Relationship, I think this most of all needs the status field. In addition to having inactive relationships, e.g. past employment.

We have discussed having workflows for contacts, potentially multiple workflows on the same contact. I think the same results can be achieved by putting the workflow on the relationship.

It should be status, not active; it is a Drupalism.

I also think the contacts should have a status field. It functions as a soft delete; people die, and organizations cease to exist.

🇺🇸United States bluegeek9

I think this is a duplicate of 📌 External Identifier field Active

📌 | Iconset | Add logo
🇺🇸United States bluegeek9

bluegeek9 created an issue.

🇺🇸United States bluegeek9

Does a user need the 'administer crm contact detail types' to create an address?

🇺🇸United States bluegeek9

Does a use need the 'administer crm contact detail types' to create an address?

🇺🇸United States bluegeek9

Any permissions for a user to view/update/delete their own contact should not be done with crm_contact_access.

We need to add permissions the allow a user to view/update/delete own contact. Then update Drupal\crm\ContactAccessControlHandler

So, yes a user could have a contact and not have access.

I think grants will be given via relationships. There could be other ways, but relationship are the only current use case.

The Group module handles access differently.

ContactAccessControlHandler needs to be update to check the grant table.

  /**
   * Checks access to a contact via crm_contact_access table.
   *
   * @param int $user_contact_id
   *   The ID of the contact trying to access.
   * @param int $contact_id
   *   The ID of the contact being accessed.
   * @param string $operation
   *   The operation being checked: view, update, delete.
   *
   * @return bool
   *   TRUE if access is granted, FALSE otherwise.
   */
  public function checkContactAccess(int $user_contact_id, int $contact_id, string $operation): bool {
    if (!isset(self::SUPPORTED_OPERATIONS[$operation])) {
      return FALSE;
    }

    $grant_field = self::SUPPORTED_OPERATIONS[$operation];

    // Query crm_contact_access table for a matching grant.
    $query = $this->database->select('crm_contact_access', 'a')
      ->fields('a', [$grant_field])
      ->condition('a.contact_id', $contact_id)
      ->condition('a.gid', $user_contact_id)
      ->condition('a.'.$grant_field, 1);

    $result = $query->execute()->fetchAssoc();

    return !empty($result[$grant_field]);
  }
}
🇺🇸United States bluegeek9

I think this could be done by updating the field formatter, and views field plugin. The module setting will also need a place to store the language to format.

🇺🇸United States bluegeek9

I believe the items listed here are either covered by other issues, or have been resolved. If I am mistake please reopen.

🇺🇸United States bluegeek9

Should crm_user be revision-able?

If so, I assume we want a new revision every time the entity is saved.

Should the user reference field only be on the add form, and absent from the edit form? If so, then only the crm_contact reference need be revision-able.

🇺🇸United States bluegeek9

bluegeek9 created an issue.

Production build 0.71.5 2024