PROFILE_HIDDEN updates

Not sure about this patch. I'll give it some thought/testing.

I am not sure the current implementation is too usefull. What about if I want to add fields that users can neither see nor edit (like the roles)?

Having this feature would be helpful to me. But there are some properties I would like to completely hide and some that would be unnecessary to show the user.

This is useful functionality. I have deployed drupal into a few corproations and they often have profile fields like 'title' and 'telephone number' and 'department'. thos fields should be editable only by administrators. thats what this patch allows, if i'm not mistaken.

i think it is great but i think we were waiting to hear back on the suggestion to provide the option to make some fields hidden from the public AND the user.

quote,
"...this seemed like the original intent of the PROFILE_HIDDEN patch in the first place, to make certain fields non-editable for users."

add to that,
"to make certain fields non-editable for users and/or non-visible."

Use case -
JBFish333 has recently joined one of your drupal forum communities. He has been active for 12 months occasionally helping others. Six months ago he got into a heated debate with other members. He started using profanity and disobeyed the rules 3 times. You warned him that he has to stop and put this behavior in the hidden "Notes" field. He was doing good and then this month he started using profanity again. You checked his notes field and saw his history. Because he has been helping people you warned him again privately that he has one last chance. He has said that it won't happen again. You made mention of this in the notes field.
- we don't want JBFish333 to see this profile field.

Typical applications of user fields that are hidden from the user (or public) are for account control and/or customer profiling. You might track lifetime revenue and profitability of a customer which you probably wouldn't want them to see. You might store the initial referer to cross-reference these against various customer acquisition methods. You might store the TOS acceptance date, and if the TOS revision date is greater than the TOS acceptance date, display the latest Accept TOS form upon logging in.

These are pretty much standard procedure for commercial sites (not so much for community sites).

The patch discussed in issue #14149 is another (much more flexible) approach to gaining this same functionality.

I agree that there are definitely many use cases for this, and other variations of hiding data from XXX / restricting editing to XXX, especially in corporate sites.

Cheers,
Eric

I agree that there are a lot of valid use cases. But I really think all this must be handled by an advaced_profile.module. We should keep drupal core clean, that is why we have all the hooks. There are a lot of hooks that allow you to mke advanced profile modules with hierarchical-permissions and all, if you wish. But, please, not in core.

sounds promising. i hope someone rerolls this for HEAD

There is a logic bug in this patch...
It makes the HIDDEN feild work as promised, but it also disables the function "Visible on registration form" completely. If the checkbox is set, then it is assumed, that users can fill this feild on registration form, and if not, then users cannot edit this feild on registration form. But this patch hides the feild on registration form completely... makes the checkbox not function properly...

I'm a noob in PHP, and i fix things mostly by "change and try/experiment" a lot... so this fix may not be very good. I did not apply the followings change, and i got the checbox fixed
The other functions work perfectly...
...
@@ -216,10 +216,16 @@

function profile_save_profile(&$edit, &$user, $category) {
if (($_GET['q'] == 'user/register') ? 1 : 0) {
- $result = db_query('SELECT fid, name, type FROM {profile_fields} WHERE register = 1 AND visibility != %d ORDER BY category, weight', PROFILE_HIDDEN);
+ if (user_access('administer users'))
+ $result = db_query('SELECT fid, name, type FROM {profile_fields} WHERE register = 1 AND ORDER BY category, weight');
+ else
+ $result = db_query('SELECT fid, name, type FROM {profile_fields} WHERE register = 1 AND visibility != %d ORDER BY category, weight', PROFILE_HIDDEN);
}
else {
- $result = db_query("SELECT fid, name, type FROM {profile_fields} WHERE LOWER(category) = LOWER('%s') AND visibility != %d", $category, PROFILE_HIDDEN);
+ if (user_access('administer users'))
+ $result = db_query("SELECT fid, name, type FROM {profile_fields} WHERE LOWER(category) = LOWER('%s')", $category);
+ else
+ $result = db_query("SELECT fid, name, type FROM {profile_fields} WHERE LOWER(category) = LOWER('%s') AND visibility != %d", $category, PROFILE_HIDDEN);
// We use LOWER('%s') instead of PHP's strtolower() to avoid UTF-8 conversion issues.
}
while ($field = db_fetch_object($result)) {

FORGET THE FIX I POSTED, IT DOES NOT WORK !!!

Ok now... i tested more now... this one works... i have tested it with one type of feild (one line textfeild) only, but the user registering and activation works. The user cannot edit HIDDEN feild, he cannot see HIDDEN faild, but he can fill it on the reigstration form, if the feild is marked to appear there... tested. I cant tell much about security... not good in PHP stuff...

Ok here is the way i did it... Below is the original patch... Im going to mark the lines i ignored with "¤¤¤" !!!
I didnt get this patch thing "GnuWin32.." to work properly, so im not able to create or run a patch file...

--- /root/drupal/drupal/modules/profile.module	2005-04-24 09:34:35.582867968 -0500
+++ profile.module	2005-04-24 09:45:55.551497024 -0500
@@ -216,10 +216,16 @@
 
 function profile_save_profile(&$edit, &$user, $category) {
   if (($_GET['q'] == 'user/register') ? 1 : 0) {
-    $result = db_query('SELECT fid, name, type FROM {profile_fields} WHERE register = 1 AND visibility != %d ORDER BY category, weight', PROFILE_HIDDEN);
+    if (user_access('administer users'))
+      $result = db_query('SELECT fid, name, type FROM {profile_fields} WHERE register = 1 AND ORDER BY category, weight');
+    else
+      $result = db_query('SELECT fid, name, type FROM {profile_fields} WHERE register = 1 AND visibility != %d ORDER BY category, weight', PROFILE_HIDDEN);
   }
   else {
¤¤¤-    $result = db_query("SELECT fid, name, type FROM {profile_fields} WHERE LOWER(category) = LOWER('%s') AND visibility != %d", $category, PROFILE_HIDDEN);
¤¤¤+    if (user_access('administer users'))
¤¤¤+      $result = db_query("SELECT fid, name, type FROM {profile_fields} WHERE LOWER(category) = LOWER('%s')", $category);
¤¤¤+    else
¤¤¤+      $result = db_query("SELECT fid, name, type FROM {profile_fields} WHERE LOWER(category) = LOWER('%s') AND visibility != %d", $category, PROFILE_HIDDEN);
     // We use LOWER('%s') instead of PHP's strtolower() to avoid UTF-8 conversion issues.
   }
   while ($field = db_fetch_object($result)) {
@@ -278,8 +284,12 @@
   profile_load_profile($user);
 
   // 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);
+  $admin_access = user_access('administer users');
+  if ( $admin_access || $GLOBALS['user']->uid == $user->uid) {
+    if ($admin_access)
+      $result = db_query('SELECT * FROM {profile_fields} ORDER BY category, weight');
+    else
+      $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);
@@ -313,10 +323,16 @@
 function profile_form_profile($edit, $user, $category) {
 
   if (($_GET['q'] == 'user/register') ? 1 : 0) {
-    $result = db_query('SELECT * FROM {profile_fields} WHERE register = 1 ORDER BY category, weight');
+    if (user_access('administer users'))
+      $result = db_query('SELECT * FROM {profile_fields} WHERE register = 1 ORDER BY category, weight');
+    else
+      $result = db_query('SELECT * FROM {profile_fields} WHERE register = 1 AND visibility != %d ORDER BY category, weight', PROFILE_HIDDEN);
   }
   else {
¤¤¤-    $result = db_query("SELECT * FROM {profile_fields} WHERE LOWER(category) = LOWER('%s') ORDER BY weight", $category);
¤¤¤+    if (user_access('administer users'))
¤¤¤+    $result = db_query("SELECT * FROM {profile_fields} WHERE LOWER(category) = LOWER('%s')", $category);
¤¤¤+    else
¤¤¤+    $result = db_query("SELECT * FROM {profile_fields} WHERE LOWER(category) = LOWER('%s') AND visibility != %d", $category, PROFILE_HIDDEN);
     // We use LOWER('%s') instead of PHP's strtolower() to avoid UTF-8 conversion issues.
   }

Profile.module in Drupal 5 already supports only showing PROFILE_HIDDEN fields to users with 'administer users' privileges. Closing.

No, it doesn't.

Yes it does.

This is how to reproduce:
- create a profile field, set it to hidden
- login as user without 'administer users' permissions
- edit its account
- See that you do not see that profile field.
- Log in as user with administer users' permission
- Edit its account
- See that you DO see that profile field.

So, fixed.

I'm relatively new to Drupal so please forgive me if I'm completely off base here, but I recently ran into an issue while using the forms api to try and set a hidden profile field using the profile_save_profile() function. I built some custom forms for the user to fill out upon creating an account but I don't want those fields displayed or edited via the profile once they have been set.
I might be missing something (and if I am please correct me), but it seems since the hidden profile field is accessible via modules and themes according to the profile/edit page, ("Hidden profile field, only accessible by administrators, modules and themes."), that you should be able to specify whether or not you want to have profile_save_profile() affect hidden fields. Is this the wrong function to use to do this? If so, please show give me an example of the correct way to save data to the profile from the Forms API.

As a work around I modified the profiles module by adding a 3rd parameter to the _profile_get_fields() function. It basically lets me determine whether or not I want it to retrieve the hidden fields.

function _profile_get_fields($category, $register = FALSE, $hidden = FALSE) {
$args = array();
$sql = 'SELECT * FROM {profile_fields} WHERE ';
$filters = array();
if ($register) {
$filters[] = 'register = 1';
}
else {
// Use LOWER('%s') instead of PHP's strtolower() to avoid UTF-8 conversion issues.
$filters[] = "LOWER(category) = LOWER('%s')";
$args[] = $category;
}
if (!user_access('administer users') and !$hidden) {
$filters[] = 'visibility != %d';
$args[] = PROFILE_HIDDEN;
}
$sql .= implode(' AND ', $filters);
$sql .= ' ORDER BY category, weight';
return db_query($sql, $args);
}

I then update the profile_save_profile() function to include the same parameter, and pass it to _profile_get_fields().

function profile_save_profile(&$edit, &$user, $category, $register = FALSE, $hidden = FALSE) {
$result = _profile_get_fields($category, $register, $hidden);
while ($field = db_fetch_object($result)) {
if (_profile_field_serialize($field->type)) {
$edit[$field->name] = serialize($edit[$field->name]);
}
db_query("DELETE FROM {profile_values} WHERE fid = %d AND uid = %d", $field->fid, $user->uid);
db_query("INSERT INTO {profile_values} (fid, uid, value) VALUES (%d, %d, '%s')", $field->fid, $user->uid, $edit[$field->name]);
// Mark field as handled (prevents saving to user->data).
$edit[$field->name] = NULL;
}
}

This allowed it to retain all the other functionality, but let's me affect the hidden profile fileds at will...

@jwalter:
Please open up a forum topic for your use-case. I'm sure someone will be able to help you!