Possibility to have different RealName rules when using ProfileContent

This sounds like a reasonable request and one which I had thought of when I was first adding this support. I just don't know when I can get to it.

Marked #369616: Support fields shared accross multiple content profiles (content_profile). as duplicate if this one.

+1

(I also raised Priority to normal)

hi, I am interested in this too,
as I have a profile for corporate members, and one for individuals.
So I would like to set up a rule using fields from two different content types.

Then I could enter three Variables 1% 2% 3% - "Company" "First name" "Last name"
Then I had either "Company" or "Firstname Lastname" as Realname.

So, it would be nice if we could select fields from multiple content types.

Can this be accomplished?

How about a token integration?
Then we could grab the tokens from various content profile pages.

I have 2 content profiles set up, member_profile and company_profile and they have different roles

in member_profile I have field_first_name and field_last_name
in company_profile I use a field as the existing field_first_name but labeled as Company name

For now I allow company role to both view and edit own field_last_name even though there is no such fields in company_profile content.

realname.module (v 1.4.4.57 2009/10/13 17:48:06 nancyw)
org

    $profile_privacy = module_exists('profile_privacy');
    if ($module && module_exists($module)) {

added 1 line after line 743

    $profile_privacy = module_exists('profile_privacy');
    if ($account->roles AND in_array('company',$account->roles)) { $type = 'company_profile'; } // extra CP by Role (jannol)
    if ($module && module_exists($module)) {

realname_content_profile.inc
org

  $profile = content_profile_load($type, $account->uid);
  if (!$profile) {
    return;
  }

added 3 lines (plus comment line) after line 12

  $profile = content_profile_load($type, $account->uid);
  // extra CP by Role - 3 lines (jannol)
  if (!$profile) {
    $profile = content_profile_load('company_profile', $account->uid);
  }
  if (!$profile) {
    return;
  }

And now I have the Company name showing in both pages/nodes/private msg

I know my "solution" might be ugly hacks but in order to be able to write more later for either me or anyone else I try to find out what to do.

Subscribing.

FWIW, token integration seems like a good approach, particularly given that Token is part of core for Drupal 7.

jannol: I'd like to do a similar thing, but I'm not a coder and I have 3 content profile types. How would your patch look for two additional content types?

+1 Subscribing

+1 Subscribing as well...

Similar issue for 7.x: #1194546: Different RealName for different roles and/or Profile2 profiles (maybe one of these two could be marked duplicate to focus efforts on one branch?).

That issue doesn't really look like a dupplicate of this one. One is for showing the same realname in different ways based on role, and this one is for having different realnames taken from different content profile node types.

Well, here's a patch for those who need to use multiple content types to extract realnames.

This patch lets you select more than one profile content types in the realname settings page (admin/user/realname/module) and then shows you all fields from all of the selected types in the "fields" page.

Then you can basically use any fields from any of the selected content types as a source for realnames. as an example, if you have two profile types, say "personal" and "professional" with the following fields:
personal:
* first name
* last name
professional:
* title

if you select both types in the modules tabs (admin/user/realname/module) you will see all fields listed in the fields tab (admin/user/realname/fields).

You can then check all three fields if you want:
[x] personal: first name
[x] personal: last name
[x] professional: title

and then specify the pattern as usual.

%3 %2 %1

As an interesting note, all fields that are not present are ignored in the pattern, and this patch will let you specify different real names for users with different profile content types.

i.e. if you have teacher_profile and student_profile, with fields teacher_name and student_name, if you check both fields and use %1 %2 as a pattern, it will show either teacher_name or student_name as realname (assuming nobody has both content profile types created, in which case it would show both fields).

Well, I'm really interested in your feedback so if anybody finds any bug or problem, please let me know!

Edit: This is a valid -p0 (old style) patch, I'm not using git so the bot won't validate, but if you use patch -p0 < realname_multiple_profile_types.patch it should work.
the same goes for the next patch.

Changed version to 6.x-1.x-dev and additional patch to remove warning message in the settings page.

#15: realname_multiple_profile_types.patch queued for re-testing.

I tried the patch.

I had 2 roles with different content profiles and wanted different realnames. I created a (third, common) content type (also set as content profile) with 1 computed field and a text field. The computed field executed a php script to see if the form for the registration was filled with the field of one or the other content type and generated the realname writing it in the text field of this 3rd content profile. I, then, put this field in the /admin/user/realname/fields.

Here's what I did and what I noticed:
- patched realname,
- disinstalled computedfield,
- deleted the third content profile,
- in /admin/user/realname/module -> "content profile",
- in /admin/user/realname/fields -> checked Name, Surname, Company name (Name & Surname are fields of a content type used as content profile for "private" while Company name is a field of a content type used as content profile for "company"),
- rebulid realname.

It seems to work fine even if I'm still trying registration procedure...
Only things not to work very well, is the list in /admin/user/realname/fields where I expected to see (in the "field name" column) something like "content_type : field" instead of "0: field" (zero is fixed for all fields) and that created a little confusion since several fields are duplicated.

If others confirm the patch as working this should be a great add to the module. Thanks lucascaro!

I think you need to go to admin/user/realname/module and select more than one content type.
For that, you need to click on the "Use this module" button and then you are presented with the content types selection page.

Anyways, this is a bug with the patch #15. I've created another patch that corrects this bug (added below).

This new patch needs to be applied after #15 and #17 were applied to the dev code.
I hope it helps.

and the mentioned patch

Your last patch is missing the part:

--- realname_content_profile.inc Base (BASE)
+++ realname_content_profile.inc Locally Modified (Based On LOCAL)

Except for this typo, it is working great!

Ps. I attached the same last patch (#22) with correct header.
Pps. Can this changes be added to the next release of the module?

Awesome, so in order to make this work, one would need to apply patches #15, then #17 and after that #23 to the dev version.

It would be nice to have this as part of the module, but that is up to the maintainers. Also I'm using it without any problems, but it wouldn't hurt to have more people trying it and reporting here how it works.

Cheers!

Thank you i subscribe to the issue, is it ok for 1.4?

I think it sould work for 1.4. If you test it, please report back here!

After a short test, it works for 1.4

Hi all, I've re rolled the patch for the new 6.x-1.x-dev (datestamp is 1315960553).
I've put all the patches in one file and re-generated it with git.

Can you review so we can mark it as RTBC?
thanks!

The patch from #28 works as expected for me. Thanks lucascaro.

yay! thanks! it's a much smaller patch though. I'd like it if more people could give it a look and see if it would work without the rest of the changes.

The patch from #28 worked for us on 6.x-1.4 and is working as well on 6.x-1.5.

I can confirm that the patch from #28 worked for us on 6.x-1.5 too.

Re-testing to see if this still applies to the latest -dev. if it works this should be good to go.

Edit: it seems that the patch does not apply to the latest dev. bummer. needs a manual re-roll. If the maintainer(s) like the patch I can do it, but I'd like to hear from them first.

Cheers.