Address/Phone/Email CRUD access control

Created on 19 May 2025, about 2 months ago

Problem/Motivation

A Contact's Addresses, Phones, and Emails, which are separate entities, should be managed exclusively via Inline Entity Form on the Contact entity.

All CRUD operations on Addresses, Phones, and Emails should be permitted if the user is:

  • Creating a Contact
  • Editing a Contact

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

πŸ“Œ Task
Status

Active

Version

1.0

Component

Code

Created by

πŸ‡ΊπŸ‡ΈUnited States jdleonard Austin, TX, USA

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

  • Issue created by @jdleonard
  • πŸ‡ΊπŸ‡ΈUnited States jdleonard Austin, TX, USA

    Should a Contact Detail have a field representing the Contact that "owns" it? This would make the access control logic simpler as we could just delegate to ContactAccessControlHandler. Should that field be read only (would that interfere with future sharing)?

    I suppose we could still delegate to ContactAccessControlHandler without such a field, but it would require a query to find the Contact referencing the Contact Detail. I err on the side of setting a read only back reference as described above.

  • πŸ‡ΊπŸ‡ΈUnited States bluegeek9

    Adding a contact reference field is how I would implement Detail sharing; it shouldn't interfere.

  • πŸ‡ΊπŸ‡ΈUnited States bluegeek9

    If a contact field is added to the contact detail, the contact form(s) will need to be updated. The add form can not create contact details because the contact id does not exist yet.

    I think it is a blocking issue, just something we will need to address.

Production build 0.71.5 2024