Users with suitable signup permissions (signup admins) can use the Edit Signup form (signup/edit/) to edit another user's signup record. (This operation is accessible from the Views based admin list of sign-up users displayed in the node's Signups tab). The Email Address confirm field is currently displayed on the form in this scenario, and shouldn't (doesn't need to) be.

I have attached a suggested patch for the latest release (6.x-1.0-rc5) for consideration. The following cursory testing has been performed on the patch, with the Signup confirm email module enabled:
1. Signups > Administer > Edit Signup - Field not displayed.
2. Regression tests:
a) Signups > Administer > Add Signup - Field not displayed, as before.
b) User signs up via node's signup form - Field displayed, as before.
c) User edits signup - Field displayed, as before.

Thanks.

CommentFileSizeAuthor
#2 578278-2.signup_confirm_email_not_for_admins.patch1.76 KBdww
signup_confirm_email.inc_.patch1.21 KBneil.brown

Comments

neil.brown’s picture

neil.brown commented

nb - The attached patch was generated using diff.

dww’s picture

dww
we/he/they
commented
Status: Needs review » Fixed
StatusFileSize
new 578278-2.signup_confirm_email_not_for_admins.patch1.76 KB

Thanks, good catch. However, there were a few problems with your patch:

A) It introduced some stray whitespace in various spots.

B) The comments didn't always wrap to 80 characters wide.

C) Your logic test wouldn't correctly bail out if an anonymous user is trying to edit their own signup (in which case we also don't want this field, since we already ask for the email address when anonymous users signup).

I fixed those and committed the attached patch to HEAD and DRUPAL-6--1. The fix will be out in rc6.

Thanks!
-Derek

dww’s picture

dww
we/he/they
commented

Oh, forgot to mention that while testing this, I found a related UI problem. When the signup_confirm_email field *is* displayed when a user edits their own signup at signup/edit/N, the field was showing up above the header information due to a weighting problem. That's what the 2nd hunk in patch #2 is about.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.