Closed (fixed)
Project:
Signup
Version:
5.x-2.x-dev
Component:
User interface
Priority:
Normal
Category:
Feature request
Assigned:
Reporter:
Created:
8 Nov 2007 at 19:13 UTC
Updated:
17 Dec 2007 at 21:41 UTC
Jump to comment: Most recent file
Comments
Comment #1
dwwksenzee offered to sponsor my time to work on this, so i'll be implementing this in the nearish future...
a few ideas on how it should work:
I'll add a new global setting to the admin/settings/signup page:
If the above setting is configured to use the separate tab, when viewing a signup-enabled node, you'll get a new "Sign up" menu tab at node/N/signup. This means that anyone with permission to signup will now get both the "Sign up" and "View" tabs on all signup-enabled nodes -- hope that's ok. ;)
This new tab will basically include everything that's currently injected into the main node -- either the signup form if the current user isn't signed up, or their signup details (and, if they have the right perms, the signup info of the other folks who signed up for that node, etc).
I've got a few open questions, mostly for ksenzee since she's paying for this, but if other signup users care to comment, I'll take your opinions into consideration, too. ;)
A) Is a global switch flexible enough? Does anyone see the need to make this option per content-type, not just site-wide? Seems like the big motivation for this feature is if you have a really long signup form (which must be site-wide given how the signup form currently works), you might want to put it on a different page. That makes me think a global option makes the most sense (at least until the signup form is more flexible for each node type).
B) People with administer signups (either global, or for their own content) will also see a "Signups" tab at node/N/signups. Is that too confusing with node/N/signup vs. node/N/signups? Any suggestions on what to do about it?
C) Should there be a 3rd option to put the signup form/details in a block?
Input welcome...
Thanks,
-Derek
Comment #2
ksenzeeThis is how I envisioned it working too, so it's fine with me. :)
For me it's flexible enough. I'll probably use this lovely messy hack to get different form fields on different events, and I can see where someone else that was doing this would want more flexibility. But for me a global switch is great.
I only have one user with signups admin rights, and she can deal. :) Seriously, the difference between "sign up" and "signups" seems clear enough. The only possible improvement I can think of would be to change "signups" to "view signups," but frankly I'd rather keep it as is. The word "view" is already a bit confusing on a site with views installed.
I don't need this personally, but I like the idea.
Another pie-in-the-sky thing -- which I don't even think is possible in D5 -- is that it would be nice to have some convenient way to alias signup forms. If my event title is "events/november-meetup", I'll want the signup form to live at "events/november-meetup/register". The only way I can see to do that right now is to create the alias manually at /admin/build/path/add. Since this site has about an event a month, that's fine with me, but it would be nice if I didn't have to.
Thanks!
Katherine
Comment #3
dwwInitial implementation. Seems to work on a local site given light testing, but I'd appreciate other tests, reviews, feedback on the UI, help text, etc.
Thanks,
-Derek
p.s. Unfortunately, this conflicts a lot with http://drupal.org/node/79331#comment-437537 which I'd really like to fix in the next release. :( So, I'm going to have to spend some extra time making these play nicely together, but I wanted to at least post my initial effort.
Comment #4
ksenzeeIt worked perfectly in my testing. Thanks for the lightning-fast response. One UI request: Is it possible to pull the form fields out of their fieldset when they appear on the signup tab? The fieldset seems a bit superfluous when the form is the only thing on the page.
Comment #5
dwwGood idea. New patch with the following:
- If the signup form is on a separate tab, no fieldset.
- Fixed descriptions of the advanced settings about this.
- Fixed typo in the previous patch for the setting ('On a separate %sign_up tag' -- should be tab).
- Added more doxygen about the various functions involved in all of this.
- Added a CHANGELOG.txt entry for the feature.
Let me know if there's anything else.
Thanks,
-Derek
Comment #6
ksenzeeI swear it takes me longer to apply the patches than it takes dww to write the code.
Yes, this looks fabulous. Is it rude to mark someone else's code RTBC in their own issue queue??
Comment #7
dwwHehe, thanks. ;) No, it's not rude at all. That's the point of the queue. I write it. You test it. You say it's RTBC. I commit it. ;)
But anyway, this seems to be ready, so I just committed to HEAD. It'll show up in the next official release whenever that's ready (there are some other things I want to include before then, so I'm not going to roll a release just for this). Meanwhile, you should see it in the 5.x-2.x-dev snapshot in the next few hours (whenever the packaging script next runs).
Cheers,
-Derek
Comment #8
(not verified) commentedAutomatically closed -- issue fixed for two weeks with no activity.