Profile categories with only hidden fields show up as empty pages when editing

Please do not mark your own issues as 'ready to commit.'

I'd like to avoid using %s a whole list since %s means string, not comma separated list of numbers. The rest of profile module seems to do it in two options of an if statement.

I couldn't find access checking to show that only user 1 can view hidden fields. This code from profile_view_profile() demonstrates that no one can view hidden fields:

  // Show private fields to administrators and people viewing their own account.
  if (user_access('administer users') || $GLOBALS['user']->uid == $user->uid) {
    $result = db_query('SELECT * FROM {profile_fields} WHERE visibility != %d ORDER BY category, weight', PROFILE_HIDDEN);
  }
  else {
    $result = db_query('SELECT * FROM {profile_fields} WHERE visibility != %d AND visibility != %d ORDER BY category, weight', PROFILE_PRIVATE, PROFILE_HIDDEN);
  }

Works for me and repare a broken UI.

The current 6.x-dev code does not seem to have any limits of the categories returned by profile_categories(), so this patch definitely does not apply. The question is if the problem remains but is caused by some code moved elsewhere, or the problem is fixed too.

The problem is still present in 6.x
This can be verified by creating a new hidden field in a new category and try to edit that field with a normal authenticated user: a local task for the category should appear, but no fields are shown. The category shouldn't be visible in the first place, as nothing is in it.

But, the solution for 5.x (just filter out the categories that according to the current user's rights are empty) won't work for 6.x, because of the new menu-system which is, sort of, cached permanently for all users independent of who's viewing the profile.

I believe for 6.x the user.module and/or the profile.module need to be adapted to incorporate the 5.x dynamic visibility/access managment that was simulated by profile.module in the 5.x version.

In the current 6.x user.module the local tasks are created with no access callbacks. If I'm corrent, either profile.module needs to create its own local tasks, or user.module needs an access callback that listens to whether the category it wants to create has any visible children. As I'm not yet completely up to date on the new menu system to make those changes, I can't give any examples what I think might be the solution.

The patch from #3 fixes this problem for me on Drupal 5. Please commit this to D5 as this is clearly a bug that should be fixed.

This has been fixed in D6 in #192692: Profile categories display doesn't follow visibility rules, lets focus on D5 again.

The patch in #3 forgot that users with 'administer users' permissions also have the right to edit hidden profile fields. Attached is a patch that takes this into account.

Something went wrong with that patch. Attempt 2

Committed to 5.x.