Even after turning search off in some others they still appear:

- Birthday
- Cell Phone

Possibly others....

James

HI James,

I am really sorry for the delayed reply.
I have helped you fix this issue. After quite some time debugging your site, it seems it is just a simple issue. Your custom fields are having the same unique names between them. This resulted conflict in your database.

Can you verify for me this issue is fixed? Please advise.

Definitely better, thank you.

May I ask, do you plan to implement a check process int he code to disallow a new field addition if the field does not have a unique name? From my memory ES Auto-Adds the Name, Description, some default settings and also the unique name. I may be mistaken. If it adds these should it recognize when its already being used and either rename it automatically or prompt the user to change it before saving is successful?

Thanks,
James

@James, I may be mistaken, but I believe Mohd is actually referring a fields "Unique Key" which is accessible from the "Advanced" tab of the profile field editor. My guess is the way your particular environment ended up with two fields with the same "Unique Key" is that one profile type was copied. When that happens, the "Unique Key" is copied over as well.

This is an important and necessary part of the "copy a profile" method in light of the fact that it is customary for users to be switched form profile-to-profile type as they either change their membership subscription to the ES-based community or they otherwise become eligible some other type of profile.

For example, in a site for educators there may be a student teacher, teacher, and administrator and over just a short time one could be assigned for a time to each of those, in turn. You would want certain profile fields for this user to persist across profile types, such as Birthday. Otherwise, you would have to have the user complete his/her profile again.

Another consideration is how Apps get profile field information. If the App expects the Unique Id "member_birthday" to be the custom field for a users birthday then it should be so no matter what profile type is assigned to a user. If unique ids were not also copied over when creating a new profile, then this would not be the case.

Regarding error checks, if you ever attempt to create a NEW field with a Unique Key that already exists, you will get an error message.

@Eileen, thanks and I am very familiar with the EasySocial work flow.

Regarding the information about a copy profile. This is actually the default "Registered User" profile that I have add additional group/pages to with accompanying fields. And, there are really (2) issues here.

1. Some fields that are CORE should have the ability to disable search functions which was/is not currently present
2. Some fields had a duplicate unique key << Agree with you here.

I would personally think the unique key would be handled similarly to the way Joomla's title/alias is handled (not exactly but same processes).

Lastly, if this is a possibility where a user can clone a user group and should then have to go back and make unique id's for the fields this needs to be add to the documentation of EasySocial if not already present.

What are your thoughts?

P.S. Have you made any use of my JReviews Notification Addon?

Thanks,
James

Hey James, this is ironic but I hadn't set my "notifications" in the JReviews forum to receive e-mail notifications so I just learned you made the "Notifications Addon" available from your posting in this thread. Thank You! I'm going to have a look at it this week. I'll make status updates in that forum or on github.

1. Some fields that are CORE should have the ability to disable search functions which was/is not currently present

Ah, I skipped over this first part of the problem and yes good to be able to restrict them from search if so desired.

I would personally think the unique key would be handled similarly to the way Joomla's title/alias is handled (not exactly but same processes).

I'd agree too when the scope is WITHIN the same user profile, and yeah, that's what it does. As far as I can tell it's not possible to clone a user group within a profile. But as you know, when you select "Save As Copy" while editing a User Profile, it saves and then also creates a NEW copy of that user profile and brings along the same field names and unique ids which is the way it should work.

@Eileen, thanks! I think StackIdeas team will be able to decipher what we need and make any changes necessary.

Regarding the Notification Addon, please do let me know what you discover. If you make any beneficial changes or need any changes please let me know and I would likely be interested in helping or splitting the expense with you. I would really like to get some other people involved and invested in it so if you want to start a new thread concerning it I would love to jump in and throw my two cents in the pool.

James

Hi James,

Sorry for late reply to this,

May I ask, do you plan to implement a check process int he code to disallow a new field addition if the field does not have a unique name? From my memory ES Auto-Adds the Name, Description, some default settings and also the unique name. I may be mistaken. If it adds these should it recognize when its already being used and either rename it automatically or prompt the user to change it before saving is successful?

Thanks for your feedback, we will see what is the best to do this checking from there, because if let say one of the site created multiple profile type, example : one of the Mobile number custom field "Unique key" need to be same as each other profile type, because this will be affected when the user search the mobile number custom field result in advanced search.

Very good point, and I definitely agree.

Thank you,
James

Thanks for understanding James