Prepopulate project issue metadata from $_GET
drumm - July 7, 2009 - 18:52
| Project: | Project issue tracking |
| Version: | 6.x-1.x-dev |
| Component: | User interface |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | needs work |
| Issue tags: | needs drupal.org deployment |
Description
Form: node_form, issue type only
Fields:
rid
component
category
assigned
sid
title
body
These fields should be fillable from $_GET. #500536: File an issue for this link will use it.
#1
Patch attached.
#2
Missed rid.
#3
If this is added to drupal.org, would it be possible to add something to the bottom of each Handbook page saying something like:
Is there a problem with this page? If you create and log in to your drupal.org account, you can edit most pages on drupal.org (you should see an Edit tab at the top). If you do not see an Edit tab, or if you can identify the problem but aren't sure how to fix it, you can (link) file an issue(endlink) to bring it to the attention of the documentation team. Thanks!
That could be prefilled with:
Project: Documentation
Component: Correction/Clarification
Category: bug report
Title: Documentation error on [url]
Body: On [url], ... (please describe the problem here)
#4
Committed.
Leaving open for #3 to potentially be implemented.
#5
#6
Been out of town a few weeks, just catching up now and saw this. It probably would have been better to be consistent with the GET parameters used in the issue queue views. For example "status" instead of "sid"... Did this get deployed on d.o yet? Are other things making use of it yet?
#7
p.s. What a pain in the ass that we added this code in the d.o module instead of just making prepopulate work. *sigh*
#8
"Just making prepopulate work" turned into writing a whole field-level white-listing system. Sorry, I'm not going to invest that sort of time just to get a handful of values from $_GET to #default_value, and I didn't see anyone else volunteering.
#9
The keys can still be changed, do you have a complete list?
#10
The issue view GET args are:
assigned
status (sid)
priorities
categories
component
version (rid)
To be really nice, version should accept the human-readable version number, not the nid of the release node it points to. That'd require a db query, but it's worth it to make the version field actually useful.
"priorities" and "categories" should probably be singular, in fact. I bet I did it that way in a failed attempt to prevent link rot from the old URLs, but they're almost entirely broken, anyway, so I should just switch those. category can be "bug", "task", "support", or "feature". priority is (currently) just an int (1 = critical, 2 = normal, 3 = minor).
status uses an int value.
component is just the human-readable component string.
assigned in the view GET uses a username as the value, but internally, project_issue stores a UID (0 == unassigned).
Now that I see how project_issue-specific this is really getting, perhaps it's best all the way around to just patch project_issue itself for this... Then, at least other users of project* will a) benefit from it and b) have an interest in keeping it working properly and ported in the future, instead of making this only a d.o feature. Then it's slightly more likely to avoid the "we don't see anyone volunteering" syndrome. ;)
#11
Committed name changes to drupalorg: http://cvs.drupal.org/viewvc.py/drupal/contributions/modules/drupalorg/d...
#12
Backported the drupalorg patch to DRUPAL-6--1 and updated SVN.
#13
That commit looks incomplete. See attached.
#14
Committed geggles's patch to DRUPAL-6--1 asnd HEAD. Moving to SVN now.