The expected behavior when going to edit an existing signup is that the user would have to click the "edit" button (which then becomes a "save" button) prior to being able to edit the contents of the signup form. Currently, in 6.x-1.0-rc4, things work like this _except_ that the only field that is disabled before edit is clicked is the Attendance select box. Other fields can be edited before the button is clicked.

Comments

dww’s picture

Status: Active » Postponed (maintainer needs more info)

I've tested this on on FF 3.0.12 and Safari 4.0.2 on my mac. So long as JS is enabled, it all works as designed, not as described here. ;) Can you post info about your browser and test environment?

Thanks!
-Derek

mlsamuelson’s picture

I've tested on OSX 10.5 with FF 3.5.1, Opera 9.64, and Safari 4.0.2. JS is enabled in all of them.

I don't believe this is a browser rendering issue, however, since none of the input tags in question have the disabled attribute in them.

mlsamuelson’s picture

Okay, more info on the buggy behavior:

1. If I'm logged in as admin - the above mentioned behavior happens.

2. If I log in as a user with "signup for content" but not "edit own signups" permissions, the textfield inputs are disabled as desired, except for the email text field, which is editable, and, when edited, reveals the checkbox despite the form not being submit-able.

3. If the user in 2 has "edit own signups" permissions, then the form behavior is identical to that of 1.

Let me know if you need further explanation or any clarification.

mlsamuelson’s picture

Status: Postponed (maintainer needs more info) » Active

Changing status.

dww’s picture

Ok, 3.2 is a bug from #534948: signup_confirm_email breaks signup_status. I should fix that regardless.

3.3 "makes sense" in that it should be equivalent to 3.1.

3.1 makes no sense. ;) What's the top of your copy of js/signup_edit_form.js look like? E.g.:

/* $Id: signup_edit_form.js,v 1.1.2.2 2009/08/03 19:57:42 dww Exp $ */
mlsamuelson’s picture

/* $Id: signup_edit_form.js,v 1.1.2.1 2009/01/24 02:15:08 dww Exp $ */

* Oops. I previously post the wrong file's top line here. Fixed now.

dww’s picture

Still can't reproduce the problem where things don't show up disabled on page load, though I'll note that the latest copy of signup_edit_form.js is indeed this one:

/* $Id: signup_edit_form.js,v 1.1.2.2 2009/08/03 19:57:42 dww Exp $ */

However, #3.2 is definitely a bug. Here are two patches (and screenshots) for possible solutions:

"gone" == if the user can't edit their own signup, it's stupid to even show their email address at all, so just leave it off.

"disabled" == if they can't edit, just show the email (not the checkbox, e.g. if JS is off) but keep the form element disabled.

Any preference? I think I lean towards "gone", but I don't really care that much...

dww’s picture

Status: Needs review » Active

Committed #7 "gone" to HEAD and DRUPAL-6--1. Back to active for the other bug here, which I *still* can't reproduce. :(

bxlredlabel’s picture

Hello,

1/ I meet the same behavior of my signup module. The attendance field is disable before i click on the edit button. This behavior occurs for people with administration rights on signup.

2/ The others aren't able to choose Attended or not on the attendance field.

Thanks in advance

bxlredlabel’s picture

Is it possible to add the Attendance check box via the phptemplate function?

bxlredlabel’s picture

Sorry... The use of signup status allow to cover such a feature.

dww’s picture

Version: 6.x-1.0-rc4 » 6.x-1.x-dev
Status: Active » Needs review
StatusFileSize
new812 bytes

Yay! I was able to reproduce this. The jQuery selector to find the form elements to disable was bogus. Pretty sure the attached patch fixes it. Certainly does on Safari 4.0.3 and FF 3.0.14. Anyone else care to test on other browsers?

dww’s picture

Status: Needs review » Fixed

Although it's been hard to get deterministic results from other people, the patch #12 certainly doesn't make things any worse, and it works properly in various browsers on the test site I put up on shared hosting. I'm calling it good enough -- I've sunk too much time into this issue already. Committed to HEAD and DRUPAL-6--1

If folks upgrade and definitely clear all the caches and browser caches and so on, and they *still* see problems here, they can reopen this with a patch. Otherwise, I'm done here. ;)

Status: Fixed » Closed (fixed)

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