bluegeek9 → created an issue. See original summary → .
bluegeek9 → created an issue.
bluegeek9 → changed the visibility of the branch 8.x-1.x to hidden.
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.
bluegeek9 → created an issue.
bluegeek9 → created an issue.
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.
bluegeek9 → made their first commit to this issue’s fork.
bluegeek9 → made their first commit to this issue’s fork.
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.
This produces a code coverage report for each MR:
https://project.pages.drupalcode.org/-/name/-/jobs/5329682/artifacts/pub...
bluegeek9 → changed the visibility of the branch 8.x-1.x to hidden.
bluegeek9 → made their first commit to this issue’s fork.
bluegeek9 → changed the visibility of the branch 8.x-1.x to hidden.
bluegeek9 → made their first commit to this issue’s fork.
I updated the comment.
bluegeek9 → made their first commit to this issue’s fork.
bluegeek9 → created an issue.
bluegeek9 → created an issue.
bluegeek9 → created an issue.
I made the background transparent. The project page maybe cached.
You can view it hereA https://project.pages.drupalcode.org/crm/
bluegeek9 → changed the visibility of the branch 3525637-transparent to active.
bluegeek9 → changed the visibility of the branch 3525637-transparent to hidden.
bluegeek9 → changed the visibility of the branch 1.0.x to hidden.
bluegeek9 → created an issue.
bluegeek9 → created an issue.
bluegeek9 → created an issue.
New Release message_subscribe 8.x-1.5.
bluegeek9 → created an issue.
New Release message_subscribe 2.0.1
bluegeek9 → changed the visibility of the branch 8.x-1.x to hidden.
bluegeek9 → made their first commit to this issue’s fork.
bluegeek9 → created an issue.
bluegeek9 → created an issue.
I was able to reproduce the error after deleting 'name.generate.examples'.
Since 2.0.x is the default branch, the changes need to be merged for the logo to appear on the project page.
Updating my organization credit attribute.
Updating my organization credit attribute.
Updating my organization credit attribute.
Updating my organization credit attribute.
Updating my organization credit attribute.
Updating my organization credit attribute.
This was resolved in 📌 Automated Drupal 11 compatibility fixes for name RTBC .
bluegeek9 → changed the visibility of the branch 3196193-remove-boundary-setting to hidden.
bluegeek9 → changed the visibility of the branch 8.x-1.x to hidden.
bluegeek9 → made their first commit to this issue’s fork.
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.
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.
bluegeek9 → created an issue.
I think this is a duplicate of 📌 External Identifier field Active
bluegeek9 → created an issue.
Does a user need the 'administer crm contact detail types' to create an address?
Does a use need the 'administer crm contact detail types' to create an address?
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]);
}
}
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.
I believe the items listed here are either covered by other issues, or have been resolved. If I am mistake please reopen.
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.
bluegeek9 → created an issue.
bluegeek9 → created an issue.
bluegeek9 → created an issue.
bluegeek9 → created an issue.
bluegeek9 → created an issue.