Posted by jbrauer on April 28, 2008 at 6:07am
13 followers
| Project: | Prepopulate |
| Version: | 7.x-2.x-dev |
| Component: | Code |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | needs work |
Issue Summary
I had the need to allow users to hide a field if it had been prepopulated. There are perhaps some downsides to this as it pertains to users mistaking this for something that would prevent changes. In the use case we had it was simply to create links to create documents with a fixed taxonomy. The patch also includes a couple of coding style cleanups (very minor).
Comments
#1
#2
Er... Not quite sure why the last patch seemed to work at some point... because it clearly doesn't really work. So here's version 2 of the patch.
#3
This sounds like a great feature and one the I may like to use. I've not installed the prepopulate module yet, so can you give me a run-down of how this feature works. E.g. What options are available? Can an admin determine which prepopulated fields will be hidden? etc...
Thanks
Ian
#4
It doesn't allow an admin to work on a field-by-field setting... that would have to be added as more GET arguments. It allows the administrator to say on a content type basis whether the prepopulated fields should be hidden on the form.
#5
This is a bit different now in 6.x-2.x (HEAD code) where we have removed the node type checkbox and prepopulate now works on all forms. I'm sorta thinking I'd rather have a settings page that lists content types and lets you select which ones will be hidden rather than spreading them out to each content type page.
Also we need to make it clear that this can only be set on content types (not any other kind of form.) We could also just have a "master" toggle that either hides or shows all of your prepopulated fields on all forms on the site.Giving folks both options (global or by content type) or some variation(s) of that needs to be determined and make sure we come up with a clear UI for selection.
I'm going to move this to v2 and needs work due to this.
#6
Hi
Sorry, I'm new to patch files but I can't make it work.
After patching de module I don't see any diference. I'm not sure but maybe is my fault patching, if I look into the patched module I still see "// $Id: prepopulate.module,v 1.5.2.1 2008/03/12 16:40:38 add1sun Exp $" at the top.
I've tried patching the module manually and it neither works.
One example link is: http://pixelgordo.com/node/add/juego?edit[taxonomy][3]=53 wich works but I can still view the taxonomy 3 selection menu.
Please, tell me if you need more information. If someone submit the module already patched I'll receive it very glad, thanks ;)
#7
@Macarro The CVS identifier isn't changed by the patch.
After patching the files there should be a new option along with the "allow pre-populate" to mark the content type to be "hide on prepopulate". I haven't gotten back to it to move this forward with regard to the changes Addi suggests for D6 and beyond.
#8
Yes, I see it now and it's checked but it doesn't work.
#9
A bit of extra information:
I've just unchecked both options, allow prepopulate and hide prepopulated fields, and saved the options.
Then, I've rechecked them and everything seems to work, prepopulated fields are hidden. But when I try to post the new node I get an error message:
If you need more information, don't hesitate to ask for it. Kind regards.
#10
Seeing comment #5 in this thread makes me think this is the right place to discuss my request, but if this really belongs in a separate issue, just let me know...
We'd love to have prepopulate on d.o for the issue node form, so that for example, api.drupal.org could have links on every page to "Report a bug in this documentation" that went to something like:
http://drupal.org/node/add/project-issue/drupal/bug?version=6.x-dev&component=Documentation&title=bug%20in%20PHPDoc%20for%20function_name()However, chx is worried about making all d.o forms prepopulate-able. So, it'd be nice to just have a way to lock down which forms get the behavior. We could always hack the copy we deploy on d.o, but it'd be nicer if the module supported that upstream. @add1sun: are you down with that? Is this the issue for that? If not, where should we discuss/implement this?
Thanks!
-Derek
#11
Hm, well it used to do just that, where you could enable it per content type, and then it was removed since it didn't seem horribly useful (and non content-type forms didn't work at all since there was no config to enable it). :-p Is there a specific concern about which forms should *not* be prepopulatable? I don't have a problem adding a feature for this but a UI for non-content type stuff would need to be sorted out. This should probably be a new feature request since that is different from just hiding prepopulated fields from users.
Also note that I have not been actively maintaining this module for a while (and seems like none of the other co-maintainers are either) so if someone wants to take this over and make it into what D.o needs, let me know.
#12
Having recently worked with similar settings on other modules it seems that there is a good case for having the ability to control which forms pre-populate from both the content type page as well as a centralized list for the whole module. Will be working on a patch for this in the next couple of weeks if one isn't here sooner. My current thinking is
Options 2 & 3 will allow an additional setting to allow hiding pre-populated fields if the administrator so desires.
#13
I'm very interested in seeing this in action, it seems to be an obvious feature to me, in as much as I'd suggest it's almost more common to want to hide the field than not. For now I can hide it with CSS, but that's not an ideal situation. Perhaps we could look at being able to hide this on a role basis, as in regular users don't get to change it, but a full admin can.
#14
I'm very interested in seeing this in action[2].
Subsc...
#15
I see you're going in a different direction here with applying a patch and all but in case somebody is interested - I use the formfilter module to hide prepopulated fields and it works fine for almost all fields (have had some problems with organic group selection fields back in drupal 5, not sure if that works now).
#16
subscribe
#17
What were the specifc concerns about prefilling any form on drupal.org?
#18
chx's concern:
17:05 < chx> drumm: this borders CSRF
17:05 < chx> drumm: I would like to exclude admin forms
17:05 < chx> drumm: of course it is not CSRF in itself, but... it makes me
uneasy
17:06 < chx> drumm: you are lowering the barrier where a barrier is a good
thing.
17:06 < drumm> chx: it is just pre-fill, not pre-submit
17:07 < chx> drumm: so let's say someone wants to get added to the Drupal
Planet, and he provides a comfy link which prefills the feed add
form. That makes TOO easy for an admin to make two clicks and dont
think.
17:07 < chx> drumm: exclude this from admin/* and I am happy
17:08 < drumm> chx: I would hope our admins are smart enough so that won't be a
problem
17:08 < chx> drumm: i find your faith amusing
17:08 < chx> drumm: actually we mayhaps actually want to *whitelist* this to
node/add/project-issue
chx's quick solution, disable the module from drupalorg module: http://drupalbin.com/10335
#19
My review:
Yes, the drupalorg_init() solution is a quick hack, but it gets the job done. It is better than nothing and allows #500536: File an issue for this link to move forward.
I also support doing nothing and letting any form be pre-filled. I see the point of the concern, but think it is too hypothetical to spend time on. If it is a problem once deployed for all forms, then it is worth spending time on. Meanwhile, the prepopulate module can implement a clean solution at its own pace.
#20
Heine is not happy with this and this neither am I. The risk that somebody crafts crafty links and some admin being in a hurry is just too high.
#21
20:33 < Heine> [20:22] I'd custom fill a few whitelisted elements from $_GET
20:33 < Heine> [20:23] eg, status, project & title
#22
This issue should return to whatever was going on before comment #10, the drupalorg module can do a minimal whitelist for now. It is always good to remove things like this from the drupalorg module, we can move to prepopulate when it can whitelist on a form/field basis.
#23
The drupalorg module issue is #512824: Prepopulate project issue metadata from $_GET.
#24
Is anyone still working on this now that this issue is back on its original course?
I was sure that Prepopulate was configurable per content type and I'm glad my memory isn't failing. Thanks for the clarification, add1sun!
#25
For now I can hide it with CSS, but that's not an ideal situation.
#13 how would one go about doing that themselves/anyone? thanks. Ive looked at formfilter aschiwi but it isnt doing the jobe. content taxonomy seems overload too. a quick css fix will do for me. thanks.
I suppose i should at least suggest a way to hide it so as i can improve my css/drupal knowledge. ok so i open up firebug in firefox and look at the field.....i look above and see it is in a div id 'edit-taxonomy-tags-1-wrapper' which is in a div class standard and then a div class node-form. Nope i have no idea what to do. maybe....
.node-form edit-taxonomy-tags {
some css in here that makes things disappear
}
Was i even close?
tx
#26
The module works great, it prepopulates my field as needed.
Only issue is that when the field is hidden, the field value won't be passed through on form submit.
=> Is there a way to have it working for hidden fields?
=> What is the status of this issue?