Split LocationType into EmailType and AddressType

Reduced scope. This is dependent on 📌 Implement "Email" Contact Detail Type Active .

What if we combined the Email Type, Telephone Type, and Location Type as a single entity type?

We can add two properties for bundles and negate to indicate which Contact Detail bundle it is valid for.

We will also need to create a custom EntityReferenceSelection

Will will have one entity type instead of three. We will have a single field (type). And if another ContactDetailType is create, by a sitebuilder, it will work as expected.

DetailType is architecturally elegant, but complicates the UX and implementation.

Can we identify possible additional Contact Detail bundles for which a DetailType would make sense?

Is there a strong argument for different Contact Detail bundles sharing the same type entity?

All entity types are identical from a schema perspective. They are serving the same role.
There is a strong overlap between Address and Email, with some elements applying to all three types.
I am an engineer, so architectural elegance is a goal.

I can not think of any additional Contact Detail Types.

How do you think it will harm the UX?
I think it could simplify the UX.
All the Contact Details will use the same field, simplifying views and list builders*.
When using Search and Search API we will want to filter by type and bundle: Home and Address. If they are separate entity types, the entities with the same label are confusing

I am working on the Entity Selection handler so I can test my idea and maybe show you.

If the LocationType is being referenced from a Contact Detail, only the Location Types that match the Contact Detail Bundle will show.
If the LocationType is being referenced from any other entity type, it behaves as normal.

*I was doing some development and needed to know if an additional Email contact detail was created, and dropping into the database was the only option. We will probably need to add some UI to the admin interface.

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

I updated the location type so it can be included/excluded by contact detail bundle. Empty implies all.

I left the email & telephone types - the task is only half done.

Agreed, renaming to DetailType makes sense if the property will be shared across multiple field types, as it’s more generic and descriptive. This avoids confusion and aligns with the property’s broader usage.