Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.This is a request for feedback on the concept.
Here's a scenario as the motivation for this request:
As an admin, I create an event and set a user limit of 20. 20 people sign up for the event and many more e-mail asking to attend. So, a second event is created at the same location on a new day and some people want to move their signup to the new day. It should be possible for registered users to move their own signup or for a user with administer signups to move the signups.
Currently this is possible as a manual process:
1. Cancel current signup on the original signup node
2. Create a new signup with the same information on the new signup node
It would be nice to automate this process as much as possible.
Proposed UI/Process:
Admins could visit node/NID/signups/admin and select users to move and then choose an action in the dropdown like "Move signup" or "Move signup to different node."
On the next page they would be presented with an autocomplete box where they can enter the title and get autocompletes from a list of signup enabled nodes. When they hit submit, all the signups are moved to that node.
Potential problems:
What if the admin tries to move 10 users to a node that is already full? Or which becomes full in the process?
So...any ideas on how to handle those problem cases? Any feedback on whether this should be in Signup itself or a separate module?
| Comment | File | Size | Author |
|---|---|---|---|
| #4 | signup_move_signups.zip | 3.22 KB | gnucifer |
Comments
Comment #1
dwwFirst instinct upon seeing the title was "won't fix". ;)
First impression after reading your description was "separate module".
Next thought was "huge can of worms"...
A) users presumably need a notification email when this happens -- ugh. signup's email functionality is a giant stinking pile, and needs to be burned to the ground and rebuilt from scratch so as not to suck. see #290305: Split out email functionality into separate submodule(s).
B) i'd think you definitely want a confirm form for this operation
C) what's the UI for users to move themselves? #51226: allow users to edit their own signup isn't even done yet. :(
D) You're obviously going to need validation to ensure you're not trying to move more users into a node than it can hold. However, you're still going to have a race condition if the validation passes but while you're actually submitting the form someone else has signed up in the mean time. This race would be made worse with a confirm form. So, I think even with validation on the original selection of users and a node, you're still going to need to validate again when you finally submit the form and do the deed.
E) there's a hook invoked when a signup is canceled and another when a signup is created. do we invoke both hooks during this operation, or a new one?
So, all of this continues to say "separate module" to me...
The one trick is how to get your new operation into the node/N/signups/admin form correctly, and I guess hook_form_alter() would do the trick (although a little ugly). Perhaps #352328: Replace (optionally?) node/N/signups/admin with a views bulk operations view? could come into play here, but maybe not -- I don't know if VBO supports "operations" that require multipage forms... I've never actually used VBO, so I have no idea what its limitations are.
Comment #2
gregglesYeah, this definitely has a lot of potential problems. Perhaps it will need to have site specific assumptions in order to stay sane in which case it would be a "won't fix" within Signup.
A - yes, agreed.
B - Of course a confirm form.
C my goal was to figure out having admins move first and then users after that with the individual user interface based on the admin interface. Editing their own signup first makes sense.
D - yes, I was thinking of confirming as each individual is added, stopping if the limit is reached, and then presenting the form back to the admin with the success/failure of the signups and the ability to move the rest of the people to a different event.
E - right now I think a new one, but maybe both makes sense. This gets into question A about what kind of e-mail may be necessary.
And, to be clear, I (or we) will either be providing patches or perhaps hiring you to write this. It's not yet another random unfunded feature demand ;)
Comment #3
gnucifer commentedI think this should be done with view bulk operations. I will attempt to write something together in the next few days.
Comment #4
gnucifer commentedI'll have to revise few days to few month, but today I took the time to write the module. :) I's pretty raw and needs some work, but it might just work (expect some bugs lurking around though, I have just tested it very briefly). Had some issues with this bug: http://drupal.org/node/676276, so make sure you are running a patched version of signup. Another side note is that the "rollback" feature will not work if the bulk operation view is set to use the batch-api. So using this option is not recommended. Will post new versions in this thread until I get a proper drupal cvs-account.