Storing the active profile(s) in a field

Why not use the methods available the the Profile entity's storage handler?

/** @var \Drupal\profile\Entity\ProfileInterface[] $profiles */
      $profiles = $storage->loadMultipleByUser($this->getOwner(), $this->getType());

This allows me to load multiple based on the owner of the user by type. Or just run the query on the profile entity storage, with the user being one field condition and value another?

Edit: Example query

$query = \Drupal::entityQuery('profile')
  ->condition('uid', 1)
  ->condition('default', 1)
  ->condition('date_of_birth', '2000-0101');
$results = $query->execute();

Ok, now the use case makes sense. As a way to basically have a condition on fields across two different profile types. How would you control access to the field on the user, or proposed solution? I'd assume this is something that should not be editable in the UI as it is automatically populated as a backreference.

Also, should this be something the module itself provides, or implementations that require it - such as the CRM contributed module.

So I find the idea great. However, I feel it brings about a lot of questions:

• How do we name the field?
• What about a field for each profile type?
• What if the profile type supports multiple?
• Do we allow it to be displayed on user form? Like admins to manually adjust?
• What about active and inactive? Inactive represents an entity in "trash", preserved for other references

I think it'd be great to see this incubated in a CRM module, with your use case. Something that implements the presave hook to add the profile reference to the user, adds the field to user entity, etc.

I'm moving this to Postponed because I would love to come back to this later once the implementation has been flushed out. I'd even like to link to the CRM module's implementation as an example. I'm always in IRC, feel free to ping me if you would like!

andrewbelcher, I've been bouncing back and forth on this a lot lately. Has the query and simplified rendering been a big win?

Okay, I think I'm going to move forward and commit this. Does it make working with Token easier? RE: #2785585: Make profile fields avalaible as tokens

Vic Luijkx, it's been on the back burner. I'm considering it to be a possible beta blocker. It seems like it'd simplify a lot of developer experience and possibly our own code.

Okay, I think we should move forward with this. It makes rendering profiles on the user much more customizable. Removes hook_extra_field_info which just stinks.

The only "bummer" is for multiple profiles there wouldn't be an easy way to just get the default when there are multiple profiles.

I'm okay with using the Profile storage to load the default. Most use cases probably won't allow for multiple profiles.

Updated the patch so that it applies and added some test coverage making sure that the fields get created and removed with the ProfileTypes and making sure that the field points to the default item.

Fix the unit test issues.

Is there any news about implementation?

sedax, the main hold up is how do we handle profile types which allow multiple references? Or in that case do we just not support the referenced field?

Any new patch is ready ?

@mglaman I think the best thing is to have a multiple user reference, maybe recalled through the profile ID

Ex.
[node:author:profile:customer:field_first_name]

bojanz had an idea: can we use a computed base field? This way we avoid the storage and can still manipulate via an entity query. Would simplify populating backreferences to profiles on user accounts.

I just read https://www.drupal.org/docs/8/api/entity-api/dynamicvirtual-field-values....

My thought is:

• Add a profiles computed field
• The computed field extends (or acts like) EntityReferenceFieldItemList to load profiles.
• We need to see how we can allow entity queries still with this field. Not sure if marking it computed will throw query error for the field not existing

Here's an updated go using a computer field. It's much nicer than using extra fields and allows granular control. Still, needs some more work. Also, need to experiment with querying. It adds a calculated entity reference field for each profile type.

Here's an example of configuring user display and output.

And since it's a calculated field, we should only need to clear the entity field manager discovery cache, no storage changes, to make Drupal aware of the fields.

This patch fixes chaining with the computed field. So something like $user->customer_profiles->first()->entity->address; works as if a normal entity reference. Also adds a test.

Still need to figure out the query, if possible. Ideally if this doesn't work out for the query, it solves the whole extra fields issue.

Yep. That does not work

Drupal\Core\Entity\Query\QueryException: 'customer_profiles' not found in Drupal\Core\Entity\Query\Sql\Tables->ensureEntityTable()

Despite all efforts, this happens when compiling query conditions, which is way before altered is allowed. Looks like we'll need to use non-computed field and update the user whenever a new profile is created. Not horrible.

Getting caught up on this issue and I think the idea of improving DX from the user object perspective would be great.

Concerning the storage of references to profiles, I do something similar on a D7 site but with an additional level of abstraction. I automatically create a "meta" profile for each user that they cannot access, this is where I store the references to each of their other profiles by profile type (each profile type is its own entref field). Maybe it's worth considering doing the same here?

If we use a profile to store all the references to other profiles, then the only thing we would need on the user to achieve the DX goal would be a single entref field to the user's meta profile. This would allow for similar api improvements requested in the issue description, and would also avoid the need to save the user due to profile changes since the user would only ever need a single reference to their "meta" profile that should never change.

Pseudo usage based on issue description, the user to meta profile entref field is named "profiles" in these examples:

• $user = \Drupal\user\Entity\User::load(1);
  $date_of_birth = $user->profiles->entity->some_profile_type->entity->date_of_birth->value;
  

• $query = \Drupal::entityQuery('user');
  $query->condition('roles', 'administrator');
  $query->condition('profiles.entity.some_profile_type.entity.date_of_birth', '2000-01-01');
  

I'm sure there are drawbacks to this approach, but can't speak to them knowledgeably from a performance perspective. Each query from a user to their profiles would require an additional join is an obvious one.

Matt's patch in #39, basically fixes the issue I reported here: #2946670: Add computed {$profile_type}_profiles fields to users, use them to render profile data on the user profile regardless of the other issues here, I'd love to see that patch get comitted, if for nothing more than to have real widget configuration abilities on user field display.

Then the *proper* solution here could back out that code and replace it with something else, if it ever gets written.

Patch #40 no longer applies on latest -dev because of #2930966: Fix phpcs errors (short array syntax, other tweaks). Ported and working on it. Interdiff doesn't work, attached a simple diff file.

With #45 (actually #40 ported), I got an exception in the user register form (with embed profile):

Drupal\Core\Database\InvalidQueryException: Query condition profile.uid IN () cannot be empty. in Drupal\Core\Database\Query\Condition->condition()
...

That happened for new users that have no user ID yet.

I also found that the new profile reference field looks like empty when accessing though the API. For instance, the isEmpty() method returns TRUE despite the user as one or more profiles. I reviewed the field item list, now:

• ProfileEntityFieldItemList extends EntityReferenceFieldItemList
• the base class getters are overridden to ensure that the item list value is populated before read it

Not sure if setters should be overridden as well, since it is a read-only field. It might produce some side effect. At the moment, changes performed in the field value simply are not persistent.

I think that some of @manuel.adan's improvements might be no longer needed (according to https://www.drupal.org/docs/8/api/entity-api/dynamicvirtual-field-values...) because #2392845: Add a trait to standardize handling of computed item lists was committed to D8.4.

@mglaman said in #41 that in order to get querying to work, "we'll need to use non-computed field and update the user whenever a new profile is created." (which was @andrewbelcher's original proposal.)

I propose that we do two things:
1) add a base field with storage of all profiles, to help querying, which should be this issue.
2) add a configurable computed field that references a single profile (defined in the field settings). Because it is configurable, sitebuilders can add multiple instances and therefore control more finely which profiles are shown in a particular display and in which sequence. This should be a separate issue. We might even be able to figure out a widget for it to work on forms.

> A. Switch to storing the link between users and profiles in an entity reference field on the user
> B. Store a cache of the active profiles in an entity reference field

Option C: Allow entity queries to go via backreferences.

I've got a hunch there's a core issue for that...

Bingo: #2975750: Allow entity queries to query reverse relationships.

I was hoping there'd be a patch there, but sadly not.

#2946670: Add computed {$profile_type}_profiles fields to users, use them to render profile data on the user profile has introduced a computed field per profile type. No need to do anything here.