CRM-15330 Profile tabs in Drupal doesn't support language switching

It seems to be a feature because in CRM_Core_BAO_UFGroup::getModuleUFGroup there is a special if to return title instead of the name field when the name field needs to be returned.
I don't get why it's like that but it's seems a little counter intuitive.

There are several places that uses getModuleUFGroup, so it's quite difficult to see what the impact of changing this will be. Here is a list of impacted files :
drupal/civicrm.module: $allUFGroups = CRM_Core_BAO_UFGroup::getModuleUFGroup('User Account', 0, TRUE);
drupal/civicrm_user.inc: $allUFGroups = CRM_Core_BAO_UFGroup::getModuleUFGroup('User Account', 0, TRUE, CRM_Core_Permission::VIEW, array('id', 'name', 'title', 'is_active'));
drupal/civicrm_user.inc: $ufGroups = CRM_Core_BAO_UFGroup::getModuleUFGroup('User Account', 0, TRUE);
CRM/UF/Page/Group.php: $allUFGroups = CRM_Core_BAO_UFGroup::getModuleUFGroup();
CRM/Core/BAO/UFGroup.php: $ufGroups = CRM_Core_BAO_UFGroup::getModuleUFGroup('User Registration');
CRM/Core/BAO/UFGroup.php: $ufGroups = CRM_Core_BAO_UFGroup::getModuleUFGroup('Profile');
CRM/Core/BAO/UFGroup.php: public static function getModuleUFGroup($moduleName = NULL, $count = 0, $skipPermission = TRUE, $op = CRM_Core_Permission::VIEW, $returnFields = NULL) {
CRM/Contact/Form/Search/Criteria.php: $ufGroups = CRM_Core_BAO_UFGroup::getModuleUFGroup('Search Profile', 1);
CRM/Profile/Form.php: $ufGroups = CRM_Core_BAO_UFGroup::getModuleUFGroup('User Registration');
CRM/Profile/Page/View.php: $ufGroups = CRM_Core_BAO_UFGroup::getModuleUFGroup('Profile');

After verification, the name field is only used in drupal/civicrm_user.inc so there is no side effect to expect.

samuel:

i'm assuming u'll submit a PR for this change.

sure, i'm working on it.

PR : https://github.com/civicrm/civicrm-core/pull/4185 and https://github.com/civicrm/civicrm-drupal/pull/166

Samuel - I applied the 2 PRs as patches this morning and did an initial test with single language (prior to testing the multilingual issue) with the patches in place.

On my local sandbox single language, the patches break access to the profile w/in My Account (screenshot attached). After clicking the 'button' to access the 'Name and Address' profile which is enabled for User Account editing, I'm getting:

"The requested page "/user/1/edit/Name%20and%20Address" could not be found."

When I revert the patches, the link works. Have you tried the patches in single language mode? I can add some debugging on my side if you tell me where.

Ok, thanks Dave. I will do more tests.

Ok Dave, i found a bug in my patch and committed the change.
However, i think the problem you had is not linked to that change. You need to clear the drupal menu cache to ensure everything is ok after applying the patch. You should not have those link /user/1/edit/Name%20and%20Address but instead /user/1/edit/name_and_address_13

Also, there is still one problem that i couldn't fixed but it was already there : the secondary tabs are not translated without clearing the drupal menu cache. I will try to deactivate the cache for those page but i think we can go forward on this patch and resolve the issue for now.

I have a customer with the issue Samuel describes so will test the PR

I have found an elegant way to translate tab items so i guess the patch is now complete.
Thanks Eileen for testing.

The drupal fixes weren't deployed to d6 - opening to add them - wondering if Joomla! & WP affected

I've merged into d6 for 4.4
https://github.com/civicrm/civicrm-drupal/pull/221

for master the d6 should be much the same

For 4.4 d7 I am also going to add a fix I did on d6 so that the old urls will still work as people may have links to them - don't know if we want that for 4.6 as people are more breakage-expectant in major upgrades

OK - here is LTS d7 version

https://github.com/civicrm/civicrm-drupal/pull/222

This basically protects existing urls - don't know if master should have it as it's cruft but may prevent breakage?

Eileen - If you're not planning on doing a PR for d6 / master - can you assign to Yash to get those fixes in.

I'm doing a merge from 4.4 D6 to master D6 - it seems a little ahead - so D6 will have the 'be-extra-careful patch' which I put into D7 LTS.

What I haven't done is the master D7 version of the 'be extra careful patch' - which is not necessarily required for 4.6 - since it is a major upgrade - but might be safer. I've mostly tested it on D6 so far

Here is the D6 merge

https://github.com/civicrm/civicrm-drupal/pull/223

What I saw is that unless people clear drupal caches (on d6 at least) they have the old style urls in the edit menu & hence

https://github.com/civicrm/civicrm-drupal/pull/222

makes it so those urls don't bomb. Realistically people might have custom links to them

looks like original 4.4 version for d7 was not right - second PR
https://github.com/civicrm/civicrm-drupal/pull/222/files

I've discovered a tangental issue - some sites appear to have non-unique name values in the uf_group table - meaning fetching by name can cause it to fetch the wrong profile (ie. a disabled one).

Although I think there is good reason to expect name to be unique ... there is nothing at the DB level to enforce it to be. I'm going to improve the fetch function to assist with this

Best to do that as a separate issue. In which case, seems like we can close this now - right???