extension modules: profile_anonymous

Yes, it should be possible to associate a profile with any entity, so this implies a schema change for the profile table to (pid, name, entity_id, entity_type) where entity_type defaults to 'user', but can store any arbitrary string. This is the roughly same model as used by Voting API, and it's a good one, IMO.

Also, I would suggest that matching contacts to users based on email may be a good default behavior, but ideally, there would be a UI that allows an admin to specify any arbitrary selection of fields as being appropriate to designate a 'match.'

But that's admittedly a scope creep that should not prevent a 1.0 release of the proposed extension, IMO.

>Any entity? What, like taxonomy term?

Sure, why not? Here's a hypothetical use case: Imagine a site that exists to share academic research, and provides a taxonomy of universities. Later, someone gets the idea that the site should store some meta-data about these universities, like mailing addresses. And we've already got a user profile that stores mailing addresses, and some nifty custom code that helps us print envelope labels to send flyers for our annual conference. Someone could easily make a taxonomy_profile module that allows us to generically reusing the profiles without needing to care whether we're dealing with a user or not. And we can choose to do this with or without the overhead of a full-blown CRM application the depends on the existence of a Contact Entity that this example site may not have a need for. (or maybe this site started life in D6 before there was any such Contact Entity, and the costs of overhauling the taxonomy-based approach is too great.)

For conceptual reference, see also: http://en.wikipedia.org/wiki/Duck_typing

Of course, what I had in mind when said 'any entity' was something more along the lines of a 'Customer' or 'Order' entity in e-commerce module. But why should we artificially limit the use of the Profile Entity when it costs us nothing to open it up for creative, unforeseeable uses?

Or, why should we make a special case when we can make a general one? If a Profile is merely 'data about someone', why should we make assumptions about what kind of object represents that someone?

If there's a clear reason for forcing every module that wants to use profiles to create it's own intermediate table, I'm all for it, but lacking that clarity, my preference is to err on the side of the most generic approach that allows future developers to re-use components.

One last thing: without a common table, how would you do a query to the effect of "return all of the entities that use the 'foo' type profile" ? i.e., how can modules that extend profile2 know about the existence of other entities that might use profiles so as to provide options for filtering data or triggering profile-related actions based on entity type? Use case: maybe my email notifications action needs to be configurable to send a notification when foo data is collected for users and ducks but not contacts.

> We can't justify that in Profile2 itself -- because it needs to be a candidate for Drupal 8 Core.

Why would providing the means to efficiently handle Profiles in a generic way prevent it from being a candidate for core? I'm guessing the performance impact of a name--type--id unique index versus a simpler name--id index is negligible, but maybe I'm wrong. Is performance your concern, or is it something else I'm not seeing?

In summary, my thinking on this is driven by the 'entities are the new node' principle. Just as most modules that extend nodes should not care about node-type, modules that provide entities that interface with other entities ideally should not care about the type of those entities. Entities should make themselves available to any other entity that is smart enough to know how to ask for what they have to offer.

>Contacts provided by this module *are* customers in Drupal Commerce.

Good to hear, I didn't know that had been decided.

I still think a generic approach to profile relationships is better, but not important enough to hinder an easy adoption by core.

subscribe

Through it up on github when you get a chance. I'd like to mess with this.

Thanks Joachim. This will really be my first look at D7 coding. The whole entity thing is very interesting and I need to do some more reading on it. I'm used to the whole node stuff from D6 :).

Ok, so after looking at this I'm confused. Party is its own entity. I thought party was just going to use profile2's entities and just create a UI for creating, editing, updating, viewing profile_types.

I can already create profile_types of "contact" or "organization", I just cant create "content" of those types as there is no UI besides when using it with a user. Why recreate this functionality with a whole new entity?

I gotcha. I was thinking I would only have a singular profile per party (ie non-user). Your saying if I have multiple profiles that go with the same non-user party, that there is no way to associate the two.

I still don't really see that as a problem though. Couldn't we:

- add an anonuid column to the {profile} table. We would fill this w/ a partyid so that different profiles can still be associated w/ each other just like they would w/ uid. Then when the uid is filled, anonid is basically ignored. I understand you might not want this because they are trying to get profile2 into d8core, but it seems like a very simple solution.
- add our own partyid column in the {party} table. This would match the profile2 pid to the partyid allowing us to do that same thing as above.

Both of those still seem simpler than using our own entity that is basically doing exactly the same thing as profile2.

Is there anything wrong w/ doing either of those ways?

p.s. I started messing w/ some code, and doing a party module w/ out its own entity would be very similar to the profile2_page.module (I just copied most of that module). Instead of having the page be based on uid, its based on pid (ie: profile-contact/6... the 6 is pid not uid). Also don't have certain menu items unless uid !=null.

Yeah, I was thinking we create a profileid column in the party db so that pid (partyid) can match up with a pid(profileid).... then no need for another entity.

Also, what relationship module are you talking about?

I am testing Profile2, after using core profile and Content Profile in D6.
At the moment it is not possible to create Profiles that are not attached to a user, like I did with Content Profile. Hence this issue..
May I suggest some changes to this module, which
- keep this module lean for core D8;
- let this module be the basis for Profile Anonymous.
I think most of it also recaps above discussion.
In Profile2:
- change fields profile-uid to profile-entity_id + profile-entity_type (an entity reference), so you can relate to 'any entity' (Orders, Universities, Terms, etc.)
In Profile Anonymous:
- Add a flag 'anonymous profiles possible' to the profile type. Setting this flag opens a UI, so you can:
-- create profiles via profile2/add/myprofile; the table 'profile' will only have fields profile-pid and profile-type set;
-- set the owner of the profile, setting the entity reference field in table 'profile'.

I'm no developer, but i am happy to test. In the meantime, I won't be using this module, but create my own content type 'profile'.

BTW, is this not the same as porting Content Profile to D7?
see #560324: Content profile: Create upgrade path to profile2 and port to Drupal 7

Subbing... Any progress on this?