Closed (fixed)
Project:
Signup
Version:
6.x-1.x-dev
Component:
User interface
Priority:
Normal
Category:
Bug report
Assigned:
Reporter:
Created:
3 Aug 2009 at 20:09 UTC
Updated:
4 Oct 2009 at 22:30 UTC
Jump to comment: Most recent file
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
Comment #1
dwwI'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
Comment #2
mlsamuelson commentedI'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.
Comment #3
mlsamuelson commentedOkay, 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.
Comment #4
mlsamuelson commentedChanging status.
Comment #5
dwwOk, 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.:
Comment #6
mlsamuelson commented* Oops. I previously post the wrong file's top line here. Fixed now.
Comment #7
dwwStill 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...
Comment #8
dwwCommitted #7 "gone" to HEAD and DRUPAL-6--1. Back to active for the other bug here, which I *still* can't reproduce. :(
Comment #9
bxlredlabel commentedHello,
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
Comment #10
bxlredlabel commentedIs it possible to add the Attendance check box via the phptemplate function?
Comment #11
bxlredlabel commentedSorry... The use of signup status allow to cover such a feature.
Comment #12
dwwYay! 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?
Comment #13
dwwAlthough 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. ;)