exclude parts of profile from handshake
emmajane - November 30, 2007 - 19:36
| Project: | User Handshakes |
| Version: | 5.x-1.x-dev |
| Component: | Code |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | postponed |
Jump to:
Description
I really like the idea of this module. Unfortunately it's a bit too protective. I'd like to have parts of the user's account visible without a handshake.
For example:
default visible: name, photo, bio
requires handshake: home/mailing address, email address.
I think this is part of what you've described in the TODO list at the top of the module? Thank you for this module please let me know how I can help to get this feature implemented!
#1
You're right, this is on my TODO list. If you look at my other modules, you'll see that the issue queues have stacked up, so I'm getting to them now. Mostly I'm working on bug fixes, but I'm also adding features where it isn't too painful. Unfortunately, I just finished all I could on this module and have released it. This feature will have to wait until the next one, but is at the top of my personal list of feature I want in the module. You may notice that I have two permissions already set up for this which are not being used yet. One is 'view handshakes' and the other is 'bypass handshakes'. The first will be for seeing fields defaulted to visible and you'll assign that to normal users. I'll make it so admins can specify which fields are viewed by default, or, the admin will be able to give the users the option of exposing some fields to all users.
The second permission I mentioned will be used with some kind of role you set up, in addition to administrative users, that need to see certain default information. This will operate independent of the other settings. So if this role needs to see a user's name, address, phone number and so on, you can expose those. So if you generally exposed names, photos, and bios, those users would see all fields I just listed since they are both regular users and special.
Does that make sense?
If you know how to code Drupal modules, I could explain a bit how you would begin doing this if you're interested in contributing patches.
Otherwise, it looks like I'm on about a quarterly schedule when it comes to updates for my modules. And there are even more I haven't released to the public! It's a lot to keep up on and still do regular work.
#2
I have come up with a usable work around for this.
The work around is usable though it it very ugly if nf_registration_mod is enabled.
It is possible to enable the standard "profile" module and create some fields e.g. Real_Name, City, Gender.
These are perhaps the kind of fields a user would want to keep public.
With this enabled we can create a user listing using views to generate a table showing linked username, and the above data as sortable rows.
I stress this is a work-around and if registration_mod is enabled we get an extra tab (duplicate of account settings) called "general settings" when a user edits their own account.
Otherwise it can all be made to work well and serves as a temporary solution before porting to 6.X