This is a patch to allow admins to have fields that the user cannot see and that can only be accessed by administrators, modules or themes. This allows me to implement a custom ranks module, which allows you to assign minimum post count requirements to selections in a profile field, as long as it's hidden. Allowing users to change this field would defeat the purpose of having a field that is modified when your post count changes. I figured this might be useful to other module developers, allowing them to store data in profile fields that the user can't modify.

Comments

menesis’s picture

Title: PROFILE_HIDDEN visibility type for profile fields » I guess you use profile.module for wrong purpose

Profile fields are defined by admin and are not guaranteed to exist for your module to use.

You should put that field in your own database table. If you want a field in user's account page where admin can put a value for modules to use, and not show it to users, use _user hook and check user_access('administer users') to determine whether to show the field.

The patch would be useful for such cases as 'notes about user'. Or you could implement 'ranking by admins hand' without writing a line of code - create a 'selection list' field rank with values 1 2 3, make it hidden, and go to profile/rank/3 to see all users with rank 3. But that's inconvenient (to use).

menesis’s picture

Title: I guess you use profile.module for wrong purpose » PROFILE_HIDDEN visibility type for profile fields

sorry

Anonymous’s picture

This is pyromanfo, I can't seem to login.

Profile fields are defined by admin and are not guaranteed to exist for your module to use.

Of course not, my module allows the administrator to select what field to use, if not field is seelcted the module does nothing. In the install file I simply need to tell the site administrator that they need a hidden selection field with the custom ranks entered in. That's not misusing profile.module at all, it's merely allowing a module to set profile data on the admin's behalf. That's the point of the PROFILE_HIDDEN visibility type, so that there can be fields that can be set by the admin or programmatically and displayed by the theme and theres no chance of user manipulation. It's still profile data, it's just not set by the user. I don't see how it's a misuse of profile.module. Besides, I think this is a really handy thing for module developers, if you're writing info about users you can just stick them in a custom profile field. Not only does this keep from requiring another DB but it gives the administrator contol over the data with an already existing GUI. No need to reinvent the wheel for what is essentially the same purpose, to attach arbitrary data to each user in an administrator defined manner.

pyromanfo’s picture

StatusFileSize
new3.4 KB

Okay it seems I forgot to attach the patch, it also works with 4.5.1

boris mann’s picture

+1

We use mapping to profile fields in the FOAF module. Adding a "hidden" flag will allow other user-related info to be stored in the profile table, which seems like a good idea.

Note: my +1 is for the concept, I haven't looked at the code.

svemir’s picture

This is almost exactly what I need for a project of mine. I need a bunch of user-profile-style fields which are read-only for users themselves. I can use existing user-profile functionalities to manage these fields, and the only thing missing was preventing users from modifying them. I do not really need to completely hide these fields fom users, so I might come up with additional patch to "PROFILE_READ_ONLY" in addition to PROFILE_HIDDEN - unless the whole idea is rejected by the maintainers.

dansuade’s picture

yeah...add my +1 as well. I'm trying to implement monitering the total kB(space) on nodes submitted/used per user and be able to auto limit the user when reaches size limit but I want to also have the power to go into user profile and set it back a little so user can post again whenever i want to. This hidden + or readonly seems like could do the trick.
-Dan.

pyromanfo’s picture

READ ONLY would be fine for what I'd be using too, if anybody wants to do that instead of hidden. Really it makes more since than HIDDEN, hiding it was just easier.

pyromanfo’s picture

StatusFileSize
new3.45 KB

Here's a patch for 4.5.2 as well

moshe weitzman’s picture

+1 from me too ... this is possible today using hook_user() but it requires a bunch of silly code. this patch would make this easy.

please reroll this for HEAD and set to 'patch'

pyromanfo’s picture

Ah, I forgot about this patch, I'll need to update it for 4.6.0. I'll do that tonight.

Thanks for the positive feedback, when I introduced it nobody seemed too keen on the idea.

yelvington’s picture

After reading through this it sounds like it would solve the issue I raised here:
http://drupal.org/node/19926. Correct?

morbus iff’s picture

+1 for me. This would be very useful for some things i've got planned.

pyromanfo’s picture

StatusFileSize
new3.54 KB

Here it is for HEAD

dries’s picture

Committed to HEAD.

Anonymous’s picture

johnnytalker’s picture

Version: » 5.3
Assigned: Unassigned » johnnytalker
Status: Closed (fixed) » Active

Doesn't this have an updated version for Drupal 5? Thanks.

webchick’s picture

Status: Active » Closed (fixed)

This is feature is already in 5.x.