Closed (fixed)
Project:
Drupal core
Version:
5.3
Component:
profile.module
Priority:
Normal
Category:
Feature request
Assigned:
Reporter:
Created:
9 Nov 2004 at 01:47 UTC
Updated:
25 Apr 2008 at 19:36 UTC
Jump to comment: Most recent file
Comments
Comment #1
menesis commentedProfile 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
_userhook and checkuser_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/3to see all users with rank 3. But that's inconvenient (to use).Comment #2
menesis commentedsorry
Comment #3
(not verified) commentedThis is pyromanfo, I can't seem to login.
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.
Comment #4
pyromanfo commentedOkay it seems I forgot to attach the patch, it also works with 4.5.1
Comment #5
boris mann commented+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.
Comment #6
svemir commentedThis 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.
Comment #7
dansuade commentedyeah...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.
Comment #8
pyromanfo commentedREAD 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.
Comment #9
pyromanfo commentedHere's a patch for 4.5.2 as well
Comment #10
moshe weitzman commented+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'
Comment #11
pyromanfo commentedAh, 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.
Comment #12
yelvington commentedAfter reading through this it sounds like it would solve the issue I raised here:
http://drupal.org/node/19926. Correct?
Comment #13
morbus iff+1 for me. This would be very useful for some things i've got planned.
Comment #14
pyromanfo commentedHere it is for HEAD
Comment #15
dries commentedCommitted to HEAD.
Comment #16
(not verified) commentedComment #17
johnnytalker commentedDoesn't this have an updated version for Drupal 5? Thanks.
Comment #18
webchickThis is feature is already in 5.x.