display of privacy values?

Currently, the setting is only displayed if the user clicks on the padlock icon. I guess the idea of also displaying the current setting on the form itself didn't come up during initial development.

@yoyoman: What is your use case for that? How do you envision the privacy setting being displayed other than the way it is now?

Assuming my installation is working properly, whenever I get to a screen where I can edit data, I see a padlock next to the field label. It would be nice to see the privacy settings of the various fields w/o having to click on each padlock.

Showing the privacy values is probably beyond the development of this module since people probably are going to have different layouts for their forms. I am getting something useful with something like this l
switch(radio.val()) {
case "e": $("#" + field_name + "_visible").text("everyone"); break;
case "b": $("#" + field_name + "_visible").text("buddies"); break;
case "n": $("#" + field_name + "_visible").text("nobody"); break;
}
In this case, I have a that will show the privacy setting. I added this after line 49 of the .js file after jQuery posts the value to the file for saving. I didn't know how to grab the label value of each radio button, so this is the best I could do ... If we gave the label a "for" value or the input an "id" value, would I be able to grab that value based on the jquery "radio" value?

I have an idea: simply have two icons. One is an unlocked padlock (the one we already have), and the other is a locked padlock. The unlocked padlock would have two colors (green for "everyone, blue for "buddylist," for example). The locked padlock would show that nobody could see the field (with the exception of the user). I think that would work and would make sense within the scope of this module's basic functionality and usability (easy for me to say, since I have only tested and do not code). Thanks for the great module!

I've gone the route of having 3 colors: red - only the user, orange - buddies, green - everyone. Right now, I have that to the right of the data values, but I was actually considering 3 colored padlocks with the initial color being red.

I like the idea - I'll see what can be added to the 2.x version.

@yoyoman - do you have this coded in already (colored padlocks), or is it just text?

right now it's just colored text, however, the text does change as the radio button is selected and the small window goes away. That text could easily be replaced with the HTML for an image. It would be nice if I could replace the original padlock with a colored version.

I've created a 6.x patch that shows a colored padlock (red/yellow/green) based on the color. The outstanding issue at the moment is how to change the icon (do we need to?) when the user selects a privacy option in the jquery window. Can it wait until the user refreshes the page, or is the expectation (from a user standpoint) that the icon would change too?

Please test out the patch in terms of the basic functionality (colored icons on page load & refresh). I'll backport when things are worked out.

actually, the patch applies nicely to 5.x-1.3, and works well. +1

I'd adjust the padlock images a bit (the colored dots are too subtle a difference.. Maybe Open (no lock, eyeball?) (green), Locked (red) and Partial Open (current lock image) (yellow)

@sethcohn - thanks for the heads up about it applying to 5.x. I agree that different padlocks may work better, but I have the artistic skills of a 2-year-old. I'll see if my partner can whip something up tonight, if not, is there a volunteer?

Here are three new icons, following sethcohn's ideas in #10. Will these work better? If so, I'll recode the patch to use them.

Bryan

Hi Bryan,

tested the patch with the new padlock files (Changed the file names in the patch) and it worked. Anyway I think I like more the coloured padlock approach...

Thanks and regards,

Ben

Would it be a good idea to just setup the names like:
padlock-none
padlock-medium
padlock-locked
and allow users to download different sets of icons (or switch out via the admin panel or something)? Is that necessary? I'm noticing already a difference in opinion, just based on a couple people.

I agree that loading different sets of images makes sense (and would allow customized theming that way... similar to fivestar, for example) A bit more work, but guaranteed to please everyone.

I've redone the patch to include the option of (1) colored icons (2) white icons and (3) custom icons, including the text boxes to name three icons. They must be placed in the icons/ folder inside the module directory. I've also attached an icons/ directory in a zip file that includes all six images from this issue, as I renamed the white set to use an underscore rather than a hyphen. Please test & let me know, I'm pretty sure it's ready but want to be sure. It will be backported once it's tested here on 6.x. @sethcohn - does it apply to 5.x already?

The patch is completely re-done, so please roll back to the 'clean' version if you tried the patch in #9.

Patch almost applies perfectly. There is one failure, due to an extra space in the 5.x module:

Remove the space after the period before ' content fields' in the 5.x module, and then the patch correctly fuzzily applies.

And actually, while we're at it, that description is wrong: there is no box to hide the complete field group. Either code is missing, or the description is plain wrong.

Can I suggest a change that will make this more robust and themeable? Don't force icons to be put into module directory under icons. Instead of this logic (sample to illustrate):

Change to this:

In other words, set the path right away, as part of the white or colored set, and then custom icons don't have to live in the icon directory.
That way: custom images can be entered as full paths, meaning they could be in a theme, in /files, or anyplace else the admin wishes.
The orig module directory doesn't have to be touched, nor upgrades worried about.

Ideally, a theme call (which can be overridden) is an even better way to deal with this, but this is a good start.

Actually, thinking about this, one current flaw is that after updating the permission, once the impromptu dialog is done, there is no change in the icon, even though the change was made.

It would be nice to change the icon to the right one, but if the names vary, there is no good way to do so, unless you populate the javascript with the image urls.
Maybe making the names standardized, and merely change the directory url? So padlock_open.jpg is always the "everyone" jpg, and changing status to "nobody" , in addition to the db change, means change it on the fly to padlock_closed.jpg (easy enough to do with js), but keep the same directory location? Locations would be icons/colored/ and icons/white and custom (merely set the one directory to look for these 3 icons with the right names, instead of 3 urls to enter)

bump. I'm using some variation of the above, merged into the current dev version. I'll generate a patch early next week for it.

@sethcohn, I'll be working on the issue queue this weekend, trying to clear some of the bigger issues (like this one) - did you take the approach as your listed in #18? I can write up a patch, just need to know the 'preferred' route.

Bryan

Bryan, I didn't, but solely due to lack of time... I'm using essentially the patch in #16 right now, but #17 and #18 approaches are worth looking into.

subscribing. I had a similar issue on d5. I will wait for the fix for 21 to re-test.

I'd tried to apply the patch on the version 1.3.2.2.2.13 without any success (actually i'd tried both, #9 and #16).
Could it be possible that current code does not support this patch (#16 at least) or it was just me?
This is the console log:

I'm going to postpone this temporarily. I think once we can get #540644: Make privacy-button themeable integrated (pending the big changes for UR + popups integration), I think it will be much easier to display the privacy values via the theme function.

Bryan O'Shea