PROFILE_HIDDEN updates
pyromanfo - April 24, 2005 - 15:34
| Project: | Drupal |
| Version: | 7.x-dev |
| Component: | profile.module |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed |
Jump to:
Description
Here are some updates to the PROFILE_HIDDEN functionality.
Basically now if you have 'administer users' access, you can edit these fields and they show up for you in the user's profile when editing.
If you don't then they don't show up for editing at all. They still should show up when simply viewing though.
| Attachment | Size |
|---|---|
| profile_hidden_update.patch | 3.28 KB |
#1
Not sure about this patch. I'll give it some thought/testing.
#2
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)?
#3
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.
#4
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.
#5
Any updates on comitting this? I didn't think to check back because this seemed like the original intent of the PROFILE_HIDDEN patch in the first place, to make certain fields non-editable for users.
#6
Is this going to be committed?
#7
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.
#8
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).
#9
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
#10
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.
#11
Except that PROFILE_HIDDEN is already in core. This simply makes it work as intended.
#12
sounds promising. i hope someone rerolls this for HEAD
#13
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)) {
#14
FORGET THE FIX I POSTED, IT DOES NOT WORK !!!
#15
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.
}
#16
Profile.module in Drupal 5 already supports only showing PROFILE_HIDDEN fields to users with 'administer users' privileges. Closing.
#17
No, it doesn't.
#18
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.
#19
Automatically closed -- issue fixed for two weeks with no activity.