remove audience checkboxes in edit as well for members
ajayg - April 28, 2008 - 04:00
| Project: | Organic groups |
| Version: | 6.x-2.0 |
| Component: | og.module |
| Category: | feature request |
| Priority: | normal |
| Assigned: | sethcohn |
| Status: | needs review |
Description
Is there a way to keep the audience checkboxes use the same simple mode for edit node form also?
If a user is member of multiple nodes and site admin has chosen the keep the checkbox off for "Audience checkboxes" in Node Authoring form the a very simple way for audience (current group only) is presented during new node creation. IS there any easy patch to keep it simple (show only the same group where it was created originally instead of multiple checkboxes)?
I tried to look through og_form_add_og_audience where it has this $simple mode. I tried to understand the code but my head is just not getting it. It seems the code starting from line 1814
// Emit the audience form element.
if ($simple) { IS there a way to reuse during node edit?
thanks
#1
I originally wrote as support request but now I see this as a consistancy bug (or atleast a usability issue) and also found a fix.
The issue is the behaviour of "Audience checkboxes" in Node authoring form is not consitant and confusing. It does simplify the
new node creation by not showing the audience checkboxes as intended but confuses by showing those in node edit form.
I found, if we change the following line
from
$simple = !user_access('administer organic groups') && !variable_get('og_audience_checkboxes', TRUE) && count($gids);to
$simple = !user_access('administer organic groups') && !variable_get('og_audience_checkboxes', TRUE);It works consistently in both node create and edit form. For those who want simple can keep the box unchecked. For those who want multiple audience can check the box.
#2
if we simplified on edit form, a user could not reaffiliate a node if he made a mistake. but so many people want this that i will do it one day.
#3
Since this is one line patch, would you please consider this? Or there is more to this?
My Thought was the current user interface (allowing choice) leaves more to abuse and confusion (and others seems to need this as well) and if a user make a mistake the system admin can always correct it.
Come to think of this, the user making a mistake are smaller due to this patch, since they need to first go in the group to make a post.
Are there "gotchas" that I need to be aware if I make the above change in my installation?
#4
#5
#6
This worked for me. Thanks!
#7
I support this request by ajayg, because it is really confusing. It also enables users to assign a post to multiple groups, which I want to prevent.
#8
For those who support, could you please review and verify the patch I have submitted above?
#9
I agree in principle with this patch idea. Lets' be clear on the use cases though:
If a user clicks on a node/add/xx with a gids[]= in the url, that should accept the group as given, and likely hide the checkboxes (we know what group was requested).
If a user clicks on a node/add/xx without a gids[]=, we have no idea what groups to display, so showing all groups is an option, but if you don't show any, how will a user _select_ a group to post into? If checkboxes are off, should we assume it must be public? Or fail, with an error?
If a user is editing an existing node (no gids[] in url), do we assume they may not change groups if checkboxes are off, since there was no (or very little) possibility they could have made a mistake assigning a group, since we really don't let them assign groups in the first place?
If we all agree on those use cases, seems like a clean thing to patch, and Moshe's concern in #2 isn't an issue for these use cases. If the last case isn't true (and they can pick a group out of a list if we aren't sure of the desired gid), then #2 above is a potenial reason to not patch this way, but perhaps not a showstopper.
#10
The suggested patch makes create and edit form consistent. The behaviour for "node/add/xx without a gids[]=" is unchanged. It just makes whatever functionality for create same is for edit. If there is a fundamental use case issue with using "with gid" or "without gid" that is not changed by this patch.
#11
how can I remove it at all, using myhookmodule_form_alter ?
i'm trying it altering $form['og_groups']...
i removed the taxonomy field with
$taxonomy = array('#type' => 'hidden',
'#value' => $form['taxonomy'][5]['#default_value'][0]
);
$form['taxonomy'][5] = $taxonomy;
'#type' => 'hidden' is not possible for the audience select list because it's not an input tag...it's a select tag....
any idea?
#12
i found this
http://agaric.com/note/skip-validation-form-element-drupal
it works, i can post the topic but it gave me some error:
warning: array_filter() [function.array-filter]: The first argument should be an array in /home/bank/public_html/sites/default/modules/og/og.module on line 1501.
warning: array_keys() [function.array-keys]: The first argument should be an array in /home/bank/public_html/sites/default/modules/og/og.module on line 1502.
any idea?
#13
I don't think this should be completely removed, for instance, in our company we actually want users to be able to select multiple audiences per post.
#14
@datune
My request is about being consistent (and less confusing to users) between node create and edit. If you want users to actually select multiple audience then you simply not choose the simple checkbox option so both create and edit you can do it for multiple audience. So you use case is already covered (I think)
My issue is currently you can simplify the create form but not simplifying the edit form with that checkbox.
#15
@ajayg Full ACK
#16
I am testing this as mentioned above - line 1690 in og.module:
- $simple = !user_access('administer organic groups') && !variable_get('og_audience_checkboxes' , TRUE) && count($gids);+ $simple = !user_access('administer organic groups') && !variable_get('og_audience_checkboxes', TRUE);
Seems to do what it is intended to, but I haven't looked into the modules code enough to follow and judge, I must admit. I would appreciate any hint if this it the proper way to do this. Because it sounds strange, that the OG-guru wrote he's gonna "do it one day" - if this is it, it probably would be done already, wouldn't it?
I changed the version, as I am running this with the current version and still see this as a "required" request. Hope that's ok - or should I open up a new one instead? Because this really is a desirable feature from my point of view, as this setting then hinders people from writing into multiple groups, at the same time - which I also wanted to do.
#17
From #2 and #9 I assume this change to be generally ok and nobody replied anything contrary. So I made a patchfile of this against 6.x-2.0 now, which you will find enclosed. diff showed up another change because something about "No newline at end of file" as a change I never consciously made, so I added a newline at the end of the file, or is there something I should know about end-of-files here?
It seems the only thing that changes is that in edit-forms the users only see the group where the post is already in. I thought a problem might arise if the group-admin removes the right for a specific content-type via og content-type-admin after a post has been created and the user then goes to edit that post, but existing posts can still be edited, so it looks all good to me. Behaviour on missing gids for creating content seems to be unchanged. Moving posts across groups is only possible for the side-admin after this patch, not for group-admins.
With this patch the existing description in admin/og/og for "Group details" / "audience checkbox" becomes untrue. Group-Admins do not see the selector anymore when not active and the part about editing also changes. I found this string to be og.admin.inc and made a patchfile for that as well. I found out patch-files can be concatenated, so both changes are in the one file attached. I hope this is ok? If you let me know how-to, I will provide a german translation as well - I just haven't understood the handling of language files yet (can I just change the strings in includes.de.po to match my change above and provide the according translation?).
But thinking about the number of installations of OG out there, I wonder if there is anyone relying on group-admins being able to override this setting. So not sure if this can be deployed as such into the module itself? I would appreciate a discussion on this, as I am interested in getting that change into a release state. I am willing to help if you let me know how.