Menu
▾
▴
phpesp-devel — Discussion of the development of phpESP
You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
(103) |
Apr
(37) |
May
(45) |
Jun
(49) |
Jul
(55) |
Aug
(11) |
Sep
(47) |
Oct
(55) |
Nov
(47) |
Dec
(8) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
(43) |
Feb
(85) |
Mar
(121) |
Apr
(37) |
May
(33) |
Jun
(33) |
Jul
(14) |
Aug
(34) |
Sep
(58) |
Oct
(68) |
Nov
(31) |
Dec
(9) |
| 2004 |
Jan
(13) |
Feb
(57) |
Mar
(37) |
Apr
(26) |
May
(57) |
Jun
(14) |
Jul
(8) |
Aug
(12) |
Sep
(32) |
Oct
(10) |
Nov
(7) |
Dec
(12) |
| 2005 |
Jan
(8) |
Feb
(25) |
Mar
(50) |
Apr
(20) |
May
(32) |
Jun
(20) |
Jul
(83) |
Aug
(25) |
Sep
(17) |
Oct
(14) |
Nov
(32) |
Dec
(27) |
| 2006 |
Jan
(24) |
Feb
(15) |
Mar
(46) |
Apr
(5) |
May
(6) |
Jun
(9) |
Jul
(12) |
Aug
(5) |
Sep
(7) |
Oct
(7) |
Nov
(4) |
Dec
(5) |
| 2007 |
Jan
(4) |
Feb
(1) |
Mar
(7) |
Apr
(3) |
May
(4) |
Jun
|
Jul
|
Aug
(2) |
Sep
(2) |
Oct
|
Nov
(22) |
Dec
(19) |
| 2008 |
Jan
(94) |
Feb
(19) |
Mar
(32) |
Apr
(46) |
May
(20) |
Jun
(10) |
Jul
(11) |
Aug
(20) |
Sep
(16) |
Oct
(12) |
Nov
(13) |
Dec
|
| 2009 |
Jan
|
Feb
(9) |
Mar
(37) |
Apr
(65) |
May
(15) |
Jun
|
Jul
(24) |
Aug
(1) |
Sep
(8) |
Oct
(4) |
Nov
(21) |
Dec
(5) |
| 2010 |
Jan
(35) |
Feb
(6) |
Mar
(8) |
Apr
|
May
(4) |
Jun
(3) |
Jul
(4) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2011 |
Jan
|
Feb
(4) |
Mar
|
Apr
|
May
(1) |
Jun
(1) |
Jul
(1) |
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
|
From: SourceForge.net <no...@so...> - 2009-04-09 21:33:54
|
Bugs item #2669428, was opened at 2009-03-06 21:45 Message generated for change (Comment added) made by liedekef You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=108956&aid=2669428&group_id=8956 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: kswartz (kswartz) >Assigned to: bishop (bishopb) Summary: Copying an existing survey does not copy conditions Initial Comment: I'm working with version 2.0.2 of phpESP, and noticed that if you copy an existing survey, it copies everything BUT the conditions. If this isn't fixed in the latest version, please consider it for the next update. (If this IS fixed in 2.1.2, it will probably speed up my upgrade. Only reason I haven't so far is because I made a lot of changes and fixed some bugs in 2.0.2, and wasn't sure how long it would take to copy the changes over.) ---------------------------------------------------------------------- >Comment By: Franky Van Liedekerke (liedekef) Date: 2009-04-09 23:33 Message: I'm assigning this to Bishop as well, but I'm really planning on releasing a new version after this fix (seems good enough reasons/bugfixes exist now). So Bishop, I don't know if you have the time to look at this and 2672129 any time soon? Franky ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2009-04-09 23:20 Message: Crap, another typo! Man, I wish I could edit these posts. One more time: INSERT INTO conditions (id,survey_id,q1_id,q2_id,cond,cond_value) SELECT NULL, 11, qnew1.id, qnew2.id, cond, cond_value FROM question qold1, question qold2, question qnew1, question qnew2, conditions c WHERE qold1.id=c.q1_id AND qold2.id=c.q2_id AND qold1.survey_id=$old_survey_id and qold2.survey_id=$old_survey_id AND qnew1.survey_id=$new_survey_id AND qnew1.position=qold1.position AND qnew1.deleted=qold1.deleted AND qnew2.survey_id=$new_survey_id AND qnew2.position=qold2.position AND qnew2.deleted=qold2.deleted; ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2009-04-09 23:18 Message: Sorry, the SQL in the last update was missing a line. It should read: INSERT INTO conditions (id,survey_id,q1_id,q2_id,cond,cond_value) SELECT NULL, $new_survey_id, qnew1.id, qnew2.id, cond, cond_value FROM question qold1, question qold2, question qnew1, question qnew2, conditions c WHERE qold1.id=c.q1_id AND qold2.id=c.q2_id AND qold1.survey_id=3 and qold2.survey_id=3 AND qnew1.survey_id=$new_survey_id AND qnew1.position=qold1.position AND qnew1.deleted=qold1.deleted AND qnew2.survey_id=$new_survey_id AND qnew2.position=qold2.position AND qnew2.deleted=qold2.deleted; Just a reminder, too, this enhancement REQUIRES the fix to 2672129 also (which makes copied surveys start with the same position as the original). This SQL cannot be manually applied to previously copied surveys unless the positions between the original and copy are re-aligned by hand, which may or may not be part of the fix to 2672129. (Probably not.) ---------------------------------------------------------------------- Comment By: kswartz (kswartz) Date: 2009-03-08 06:23 Message: (Sorry for the double post before.) Okay, I've looked at survey_aggregate.inc, and I think what I described previously is actually a bug. I've logged a separate bug for this. With that fix in place, this is the SQL I used to copy the conditions from the old survey to the new survey: INSERT INTO conditions (id,survey_id,q1_id,q2_id,cond,cond_value) SELECT NULL, $new_survey_id, qnew1.id, qnew2.id, cond, cond_value FROM question qold1, question qold2, question qnew1, question qnew2, conditions c WHERE qold1.id=c.q1_id AND qold2.id=c.q2_id AND qnew1.survey_id=$new_survey_id AND qnew1.position=qold1.position AND qnew1.deleted=qold1.deleted AND qnew2.survey_id=$new_survey_id AND qnew2.position=qold2.position AND qnew2.deleted=qold2.deleted; I'll work on producing a patch that incorporates this into survey_aggregate.inc Incidentally, I'm not sure why you chose to insert the questions one at a time while cycling through the results of a select. I think all the changes you made to the old data could have been made in SQL. I elected to do an INSERT INTO ... SELECT FROM ... instead, as you can see, as it's much faster. ---------------------------------------------------------------------- Comment By: kswartz (kswartz) Date: 2009-03-08 05:24 Message: Okay, I've set up 2.1.2, and I may have a patch for this coming, but I've discovered a weird quirk that's affecting the SQL. The starting position for all my surveys (in the question table) is 0. However, when I copy a survey, the starting position is 1. Is that intended behavior? Can I always assume that the value of "position" for a question in a copied survey is always one greater than its counterpart in the original survey? ---------------------------------------------------------------------- Comment By: kswartz (kswartz) Date: 2009-03-07 20:45 Message: Okay, I've set up 2.1.2, and I may have a patch for this coming, but I've discovered a weird quirk that's affecting the SQL. The starting position for all my surveys (in the question table) is 0. However, when I copy a survey, the starting position is 1. Is that intended behavior? Can I always assume that the value of "position" for a question in a copied survey is always one greater than its counterpart in the original survey? ---------------------------------------------------------------------- Comment By: kswartz (kswartz) Date: 2009-03-07 01:01 Message: That's cool - it's not a feature I use very often, which is why it took so long to say anything. Next time I go to do this, I'll add a comment to the request with the SQL necessary to do the copy (which is the hard part). If I have time to actually fix the code, I'll gladly supply a patch. (And yes, I'll upgrade to 2.1.2 first. :) ) ---------------------------------------------------------------------- Comment By: Franky Van Liedekerke (liedekef) Date: 2009-03-07 00:40 Message: Hi, sorry, but I don't think it is fixed in 2.1.2 (it was known to me though, and I'm pretty sure I documented it somewhere...) But feel free to make any contribution, be it patches, bug fixes, etc ... Franky ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=108956&aid=2669428&group_id=8956 |
|
From: SourceForge.net <no...@so...> - 2009-04-09 21:20:07
|
Bugs item #2669428, was opened at 2009-03-06 20:45 Message generated for change (Comment added) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=108956&aid=2669428&group_id=8956 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: kswartz (kswartz) Assigned to: Nobody/Anonymous (nobody) Summary: Copying an existing survey does not copy conditions Initial Comment: I'm working with version 2.0.2 of phpESP, and noticed that if you copy an existing survey, it copies everything BUT the conditions. If this isn't fixed in the latest version, please consider it for the next update. (If this IS fixed in 2.1.2, it will probably speed up my upgrade. Only reason I haven't so far is because I made a lot of changes and fixed some bugs in 2.0.2, and wasn't sure how long it would take to copy the changes over.) ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2009-04-09 21:20 Message: Crap, another typo! Man, I wish I could edit these posts. One more time: INSERT INTO conditions (id,survey_id,q1_id,q2_id,cond,cond_value) SELECT NULL, 11, qnew1.id, qnew2.id, cond, cond_value FROM question qold1, question qold2, question qnew1, question qnew2, conditions c WHERE qold1.id=c.q1_id AND qold2.id=c.q2_id AND qold1.survey_id=$old_survey_id and qold2.survey_id=$old_survey_id AND qnew1.survey_id=$new_survey_id AND qnew1.position=qold1.position AND qnew1.deleted=qold1.deleted AND qnew2.survey_id=$new_survey_id AND qnew2.position=qold2.position AND qnew2.deleted=qold2.deleted; ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2009-04-09 21:18 Message: Sorry, the SQL in the last update was missing a line. It should read: INSERT INTO conditions (id,survey_id,q1_id,q2_id,cond,cond_value) SELECT NULL, $new_survey_id, qnew1.id, qnew2.id, cond, cond_value FROM question qold1, question qold2, question qnew1, question qnew2, conditions c WHERE qold1.id=c.q1_id AND qold2.id=c.q2_id AND qold1.survey_id=3 and qold2.survey_id=3 AND qnew1.survey_id=$new_survey_id AND qnew1.position=qold1.position AND qnew1.deleted=qold1.deleted AND qnew2.survey_id=$new_survey_id AND qnew2.position=qold2.position AND qnew2.deleted=qold2.deleted; Just a reminder, too, this enhancement REQUIRES the fix to 2672129 also (which makes copied surveys start with the same position as the original). This SQL cannot be manually applied to previously copied surveys unless the positions between the original and copy are re-aligned by hand, which may or may not be part of the fix to 2672129. (Probably not.) ---------------------------------------------------------------------- Comment By: kswartz (kswartz) Date: 2009-03-08 05:23 Message: (Sorry for the double post before.) Okay, I've looked at survey_aggregate.inc, and I think what I described previously is actually a bug. I've logged a separate bug for this. With that fix in place, this is the SQL I used to copy the conditions from the old survey to the new survey: INSERT INTO conditions (id,survey_id,q1_id,q2_id,cond,cond_value) SELECT NULL, $new_survey_id, qnew1.id, qnew2.id, cond, cond_value FROM question qold1, question qold2, question qnew1, question qnew2, conditions c WHERE qold1.id=c.q1_id AND qold2.id=c.q2_id AND qnew1.survey_id=$new_survey_id AND qnew1.position=qold1.position AND qnew1.deleted=qold1.deleted AND qnew2.survey_id=$new_survey_id AND qnew2.position=qold2.position AND qnew2.deleted=qold2.deleted; I'll work on producing a patch that incorporates this into survey_aggregate.inc Incidentally, I'm not sure why you chose to insert the questions one at a time while cycling through the results of a select. I think all the changes you made to the old data could have been made in SQL. I elected to do an INSERT INTO ... SELECT FROM ... instead, as you can see, as it's much faster. ---------------------------------------------------------------------- Comment By: kswartz (kswartz) Date: 2009-03-08 04:24 Message: Okay, I've set up 2.1.2, and I may have a patch for this coming, but I've discovered a weird quirk that's affecting the SQL. The starting position for all my surveys (in the question table) is 0. However, when I copy a survey, the starting position is 1. Is that intended behavior? Can I always assume that the value of "position" for a question in a copied survey is always one greater than its counterpart in the original survey? ---------------------------------------------------------------------- Comment By: kswartz (kswartz) Date: 2009-03-07 19:45 Message: Okay, I've set up 2.1.2, and I may have a patch for this coming, but I've discovered a weird quirk that's affecting the SQL. The starting position for all my surveys (in the question table) is 0. However, when I copy a survey, the starting position is 1. Is that intended behavior? Can I always assume that the value of "position" for a question in a copied survey is always one greater than its counterpart in the original survey? ---------------------------------------------------------------------- Comment By: kswartz (kswartz) Date: 2009-03-07 00:01 Message: That's cool - it's not a feature I use very often, which is why it took so long to say anything. Next time I go to do this, I'll add a comment to the request with the SQL necessary to do the copy (which is the hard part). If I have time to actually fix the code, I'll gladly supply a patch. (And yes, I'll upgrade to 2.1.2 first. :) ) ---------------------------------------------------------------------- Comment By: Franky Van Liedekerke (liedekef) Date: 2009-03-06 23:40 Message: Hi, sorry, but I don't think it is fixed in 2.1.2 (it was known to me though, and I'm pretty sure I documented it somewhere...) But feel free to make any contribution, be it patches, bug fixes, etc ... Franky ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=108956&aid=2669428&group_id=8956 |
|
From: SourceForge.net <no...@so...> - 2009-04-09 21:18:33
|
Bugs item #2669428, was opened at 2009-03-06 20:45 Message generated for change (Comment added) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=108956&aid=2669428&group_id=8956 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: kswartz (kswartz) Assigned to: Nobody/Anonymous (nobody) Summary: Copying an existing survey does not copy conditions Initial Comment: I'm working with version 2.0.2 of phpESP, and noticed that if you copy an existing survey, it copies everything BUT the conditions. If this isn't fixed in the latest version, please consider it for the next update. (If this IS fixed in 2.1.2, it will probably speed up my upgrade. Only reason I haven't so far is because I made a lot of changes and fixed some bugs in 2.0.2, and wasn't sure how long it would take to copy the changes over.) ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2009-04-09 21:18 Message: Sorry, the SQL in the last update was missing a line. It should read: INSERT INTO conditions (id,survey_id,q1_id,q2_id,cond,cond_value) SELECT NULL, $new_survey_id, qnew1.id, qnew2.id, cond, cond_value FROM question qold1, question qold2, question qnew1, question qnew2, conditions c WHERE qold1.id=c.q1_id AND qold2.id=c.q2_id AND qold1.survey_id=3 and qold2.survey_id=3 AND qnew1.survey_id=$new_survey_id AND qnew1.position=qold1.position AND qnew1.deleted=qold1.deleted AND qnew2.survey_id=$new_survey_id AND qnew2.position=qold2.position AND qnew2.deleted=qold2.deleted; Just a reminder, too, this enhancement REQUIRES the fix to 2672129 also (which makes copied surveys start with the same position as the original). This SQL cannot be manually applied to previously copied surveys unless the positions between the original and copy are re-aligned by hand, which may or may not be part of the fix to 2672129. (Probably not.) ---------------------------------------------------------------------- Comment By: kswartz (kswartz) Date: 2009-03-08 05:23 Message: (Sorry for the double post before.) Okay, I've looked at survey_aggregate.inc, and I think what I described previously is actually a bug. I've logged a separate bug for this. With that fix in place, this is the SQL I used to copy the conditions from the old survey to the new survey: INSERT INTO conditions (id,survey_id,q1_id,q2_id,cond,cond_value) SELECT NULL, $new_survey_id, qnew1.id, qnew2.id, cond, cond_value FROM question qold1, question qold2, question qnew1, question qnew2, conditions c WHERE qold1.id=c.q1_id AND qold2.id=c.q2_id AND qnew1.survey_id=$new_survey_id AND qnew1.position=qold1.position AND qnew1.deleted=qold1.deleted AND qnew2.survey_id=$new_survey_id AND qnew2.position=qold2.position AND qnew2.deleted=qold2.deleted; I'll work on producing a patch that incorporates this into survey_aggregate.inc Incidentally, I'm not sure why you chose to insert the questions one at a time while cycling through the results of a select. I think all the changes you made to the old data could have been made in SQL. I elected to do an INSERT INTO ... SELECT FROM ... instead, as you can see, as it's much faster. ---------------------------------------------------------------------- Comment By: kswartz (kswartz) Date: 2009-03-08 04:24 Message: Okay, I've set up 2.1.2, and I may have a patch for this coming, but I've discovered a weird quirk that's affecting the SQL. The starting position for all my surveys (in the question table) is 0. However, when I copy a survey, the starting position is 1. Is that intended behavior? Can I always assume that the value of "position" for a question in a copied survey is always one greater than its counterpart in the original survey? ---------------------------------------------------------------------- Comment By: kswartz (kswartz) Date: 2009-03-07 19:45 Message: Okay, I've set up 2.1.2, and I may have a patch for this coming, but I've discovered a weird quirk that's affecting the SQL. The starting position for all my surveys (in the question table) is 0. However, when I copy a survey, the starting position is 1. Is that intended behavior? Can I always assume that the value of "position" for a question in a copied survey is always one greater than its counterpart in the original survey? ---------------------------------------------------------------------- Comment By: kswartz (kswartz) Date: 2009-03-07 00:01 Message: That's cool - it's not a feature I use very often, which is why it took so long to say anything. Next time I go to do this, I'll add a comment to the request with the SQL necessary to do the copy (which is the hard part). If I have time to actually fix the code, I'll gladly supply a patch. (And yes, I'll upgrade to 2.1.2 first. :) ) ---------------------------------------------------------------------- Comment By: Franky Van Liedekerke (liedekef) Date: 2009-03-06 23:40 Message: Hi, sorry, but I don't think it is fixed in 2.1.2 (it was known to me though, and I'm pretty sure I documented it somewhere...) But feel free to make any contribution, be it patches, bug fixes, etc ... Franky ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=108956&aid=2669428&group_id=8956 |
|
From: SourceForge.net <no...@so...> - 2009-04-08 07:34:40
|
Bugs item #2672129, was opened at 2009-03-08 05:21 Message generated for change (Comment added) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=108956&aid=2672129&group_id=8956 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Admin Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: kswartz (kswartz) Assigned to: bishop (bishopb) Summary: Copy survey reorders positions starting with 1 instead of 0 Initial Comment: When you initialize $pos before looping through the calls to survey_copy_questions, you set it to 1, so the first copied question has position=1. However, when you define questions for a survey, the first question's position is set to 0. The application works fine with this bug in place UNTIL you go to copy conditions. That requires matching the questions from the new survey and the old survey, and the only way to do that is to match on the columns position and deleted. With this bug, however, the position columns do not correspond, so the question that was in position 1 in the old survey is in position 2 in the new survey. The fix requires changing only two lines in survey_aggregate.inc: $ diff survey_aggregate_old.inc survey_aggregate.inc 74c74 < $pos = 1; --- > $pos = 0; 85c85 < function survey_copy_questions($sid, $new_sid, $pos = 1) { --- > function survey_copy_questions($sid, $new_sid, $pos = 0) { ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2009-04-08 07:34 Message: Basically, that's true. The point is that when you copy the questions from one survey to another, the position values must remain the same. It's okay if some are 0 and some are 1, just as long as the source and destination match. ---------------------------------------------------------------------- Comment By: Franky Van Liedekerke (liedekef) Date: 2009-03-23 20:31 Message: Well, I don't think it matters :-) Or more: to fix the ones starting at "1" would be very troublesome ... the damage there is already done (if you have conditions in place). But after the fix is in place, it wouldn't matter: you start at position 0 in source and destination, even if position 0 is not defined it should still be ok, no? Franky ---------------------------------------------------------------------- Comment By: kswartz (kswartz) Date: 2009-03-09 03:45 Message: I haven't looked through the code yet for the initial "0" position, but I can say that every survey I've created has 0 as the value of position for the first question. I would expect that this gets set when using the section to reorder the questions in creating a new survey. One question (no pun intended) is whether or not it starts with "0" if you do NOT reorder the questions; i.e.: if you only create a question and exit. However, I think it doesn't really matter, and here's why... As soon as we introduce the code to copy conditions (which is dependent on this change), it's going to rely on the fact that positions between original and copied surveys always start with the same value. Today, some surveys will start with 0 and some start with 1. So the next release will have to include an upgrade script that cleans this up, by updating the position column so that ALL surveys start with the same value. I'm inclined to say that value should be 0, based on what I'm seeing from the surveys I've created from scratch and your last comment, bishopb. ---------------------------------------------------------------------- Comment By: bishop (bishopb) Date: 2009-03-08 19:50 Message: I am inclined to think that 0 is the correct position, and since I was the most recent to work in that area of the (really old) code, I'll take on this issue. kswartz: are you seeing the initial definition of 0 somewhere specifically in the code, or only as a post facto artifact in the generated rows? ---------------------------------------------------------------------- Comment By: Franky Van Liedekerke (liedekef) Date: 2009-03-08 17:27 Message: Hmmm ... I don't remember as well, probably the oldest programmer for that part was way before me ... Franky ---------------------------------------------------------------------- Comment By: bishop (bishopb) Date: 2009-03-08 12:15 Message: survey_aggregate() is a generalization of the original survey_copy() code, and in fact the survey_copy_questions() helper function is a direct descendant of the original survey_copy(). In the original survey_copy(), $pos was initialized to 1: 65 $pos=1; 66 array_shift($question_fields); 67 while($question = fetch_row($result)) { 68 $result->MoveNext(); 69 $tid = $question['type_id']; 70 $qid = $question['id']; 71 // fix some fields first 72 $question['survey_id'] = $new_sid; 73 $question['position'] = $pos++; So, I can say that if this is a bug, it's existed for a while. Is anyone here familiar with the older code from survey_copy() that can comment on this? ---------------------------------------------------------------------- Comment By: kswartz (kswartz) Date: 2009-03-08 05:22 Message: File Added: survey_aggregate.inc ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=108956&aid=2672129&group_id=8956 |
|
From: SourceForge.net <no...@so...> - 2009-04-05 12:04:05
|
Bugs item #2138508, was opened at 2008-09-30 18:04 Message generated for change (Comment added) made by liedekef You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=108956&aid=2138508&group_id=8956 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Admin Group: 2.1.2 >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Jonathan Hughes (xerxesii) Assigned to: Franky Van Liedekerke (liedekef) Summary: group manager cannot do much managing Initial Comment: A group manager cannot add a new designer using the forms interface, or perform other tasks such as changing user flags. Message is "This account does not have permission to access this group". Batch submission works OK. Cannot duplicate on demo site since user doesn't have this capability. ---------------------------------------------------------------------- >Comment By: Franky Van Liedekerke (liedekef) Date: 2009-04-05 14:03 Message: True, in the past this was in fact the case: db_qstr was only called for database related things. Now the call to _addslashes does this already (which in fact does stripslashes and db_qstr), and this causes more pain than it solves. This needs to be redone properly. Franky ---------------------------------------------------------------------- Comment By: Franky Van Liedekerke (liedekef) Date: 2009-04-05 14:03 Message: The latest development code contains the fix, please update to the development code or wait for an official release. ---------------------------------------------------------------------- Comment By: Arjen van Bochoven (bochoven) Date: 2009-04-05 13:43 Message: I can confirm that the fix in revision 1110 resolves the issue. A group editor is now able to add new designers and delete them. I can confirm that it also resolves the same issue with respondent accounts. Thank you for the quick resolution. Arjen PS On the long term a more robust approach would be preferred, only escaping the variables only in the query using mysql_real_escape_string() or using a db abstraction layer as the one used in CodeIgniter for example. ---------------------------------------------------------------------- Comment By: Franky Van Liedekerke (liedekef) Date: 2009-04-05 10:18 Message: Hmmm ... the in_array function is called in multiple places with the same $r variable. Shouldn't they all be changed then? I've committed a fix for this to svn. Please verify if this works ok, then I'll close this ticket and release a new version asap. Franky ---------------------------------------------------------------------- Comment By: Arjen van Bochoven (bochoven) Date: 2009-04-04 23:18 Message: Ok, you probably read the mailinglist, but just to be sure here's the culprit: I guess in order to prepare for a mysql query, the variable containing the group is padded with quotes. This causes the check for the group to fail. To fix it, edit admin/include/where/admdesigner.inc on line 155 replace in_array($r, $_SESSION['acl']['pgroup']) || with in_array(trim($r, "'"), $_SESSION['acl']['pgroup']) || ---------------------------------------------------------------------- Comment By: Franky Van Liedekerke (liedekef) Date: 2009-04-04 14:38 Message: Hmmm ... appparently closed for the wrong reason (I based myself on the comment that it was fixed without looking at the poster). I'm going to check this out (again) when I have the time. Franky ---------------------------------------------------------------------- Comment By: Jonathan Hughes (xerxesii) Date: 2008-10-03 18:18 Message: Suggested fix doesn't have any effect! ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2008-10-03 14:49 Message: I've found it, it was nnot a bug but a configuration matter. In the default config file (phpESP.ini.php.default) the setting is as followed: $ESPCONFIG['limit_double_postings'] = 3; By adding the next line to phpESP.ini.php the problem is solved $ESPCONFIG['limit_double_postings'] = 0; Greetings Arjan ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2008-10-03 14:49 Message: I've found it, it was nnot a bug but a configuration matter. In the default config file (phpESP.ini.php.default) the setting is as followed: $ESPCONFIG['limit_double_postings'] = 3; By adding the next line to phpESP.ini.php the problem is solved $ESPCONFIG['limit_double_postings'] = 0; Greetings Arjan ---------------------------------------------------------------------- Comment By: Franky Van Liedekerke (liedekef) Date: 2008-10-03 13:21 Message: I'll check this out. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=108956&aid=2138508&group_id=8956 |
|
From: SourceForge.net <no...@so...> - 2009-04-05 11:43:45
|
Bugs item #2138508, was opened at 2008-09-30 18:04 Message generated for change (Comment added) made by bochoven You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=108956&aid=2138508&group_id=8956 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Admin Group: 2.1.2 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jonathan Hughes (xerxesii) Assigned to: Franky Van Liedekerke (liedekef) Summary: group manager cannot do much managing Initial Comment: A group manager cannot add a new designer using the forms interface, or perform other tasks such as changing user flags. Message is "This account does not have permission to access this group". Batch submission works OK. Cannot duplicate on demo site since user doesn't have this capability. ---------------------------------------------------------------------- Comment By: Arjen van Bochoven (bochoven) Date: 2009-04-05 13:43 Message: I can confirm that the fix in revision 1110 resolves the issue. A group editor is now able to add new designers and delete them. I can confirm that it also resolves the same issue with respondent accounts. Thank you for the quick resolution. Arjen PS On the long term a more robust approach would be preferred, only escaping the variables only in the query using mysql_real_escape_string() or using a db abstraction layer as the one used in CodeIgniter for example. ---------------------------------------------------------------------- Comment By: Franky Van Liedekerke (liedekef) Date: 2009-04-05 10:18 Message: Hmmm ... the in_array function is called in multiple places with the same $r variable. Shouldn't they all be changed then? I've committed a fix for this to svn. Please verify if this works ok, then I'll close this ticket and release a new version asap. Franky ---------------------------------------------------------------------- Comment By: Arjen van Bochoven (bochoven) Date: 2009-04-04 23:18 Message: Ok, you probably read the mailinglist, but just to be sure here's the culprit: I guess in order to prepare for a mysql query, the variable containing the group is padded with quotes. This causes the check for the group to fail. To fix it, edit admin/include/where/admdesigner.inc on line 155 replace in_array($r, $_SESSION['acl']['pgroup']) || with in_array(trim($r, "'"), $_SESSION['acl']['pgroup']) || ---------------------------------------------------------------------- Comment By: Franky Van Liedekerke (liedekef) Date: 2009-04-04 14:38 Message: Hmmm ... appparently closed for the wrong reason (I based myself on the comment that it was fixed without looking at the poster). I'm going to check this out (again) when I have the time. Franky ---------------------------------------------------------------------- Comment By: Jonathan Hughes (xerxesii) Date: 2008-10-03 18:18 Message: Suggested fix doesn't have any effect! ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2008-10-03 14:49 Message: I've found it, it was nnot a bug but a configuration matter. In the default config file (phpESP.ini.php.default) the setting is as followed: $ESPCONFIG['limit_double_postings'] = 3; By adding the next line to phpESP.ini.php the problem is solved $ESPCONFIG['limit_double_postings'] = 0; Greetings Arjan ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2008-10-03 14:49 Message: I've found it, it was nnot a bug but a configuration matter. In the default config file (phpESP.ini.php.default) the setting is as followed: $ESPCONFIG['limit_double_postings'] = 3; By adding the next line to phpESP.ini.php the problem is solved $ESPCONFIG['limit_double_postings'] = 0; Greetings Arjan ---------------------------------------------------------------------- Comment By: Franky Van Liedekerke (liedekef) Date: 2008-10-03 13:21 Message: I'll check this out. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=108956&aid=2138508&group_id=8956 |
|
From: SourceForge.net <no...@so...> - 2009-04-05 08:18:32
|
Bugs item #2138508, was opened at 2008-09-30 18:04 Message generated for change (Comment added) made by liedekef You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=108956&aid=2138508&group_id=8956 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Admin Group: 2.1.2 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jonathan Hughes (xerxesii) Assigned to: Franky Van Liedekerke (liedekef) Summary: group manager cannot do much managing Initial Comment: A group manager cannot add a new designer using the forms interface, or perform other tasks such as changing user flags. Message is "This account does not have permission to access this group". Batch submission works OK. Cannot duplicate on demo site since user doesn't have this capability. ---------------------------------------------------------------------- >Comment By: Franky Van Liedekerke (liedekef) Date: 2009-04-05 10:18 Message: Hmmm ... the in_array function is called in multiple places with the same $r variable. Shouldn't they all be changed then? I've committed a fix for this to svn. Please verify if this works ok, then I'll close this ticket and release a new version asap. Franky ---------------------------------------------------------------------- Comment By: Arjen van Bochoven (bochoven) Date: 2009-04-04 23:18 Message: Ok, you probably read the mailinglist, but just to be sure here's the culprit: I guess in order to prepare for a mysql query, the variable containing the group is padded with quotes. This causes the check for the group to fail. To fix it, edit admin/include/where/admdesigner.inc on line 155 replace in_array($r, $_SESSION['acl']['pgroup']) || with in_array(trim($r, "'"), $_SESSION['acl']['pgroup']) || ---------------------------------------------------------------------- Comment By: Franky Van Liedekerke (liedekef) Date: 2009-04-04 14:38 Message: Hmmm ... appparently closed for the wrong reason (I based myself on the comment that it was fixed without looking at the poster). I'm going to check this out (again) when I have the time. Franky ---------------------------------------------------------------------- Comment By: Jonathan Hughes (xerxesii) Date: 2008-10-03 18:18 Message: Suggested fix doesn't have any effect! ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2008-10-03 14:49 Message: I've found it, it was nnot a bug but a configuration matter. In the default config file (phpESP.ini.php.default) the setting is as followed: $ESPCONFIG['limit_double_postings'] = 3; By adding the next line to phpESP.ini.php the problem is solved $ESPCONFIG['limit_double_postings'] = 0; Greetings Arjan ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2008-10-03 14:49 Message: I've found it, it was nnot a bug but a configuration matter. In the default config file (phpESP.ini.php.default) the setting is as followed: $ESPCONFIG['limit_double_postings'] = 3; By adding the next line to phpESP.ini.php the problem is solved $ESPCONFIG['limit_double_postings'] = 0; Greetings Arjan ---------------------------------------------------------------------- Comment By: Franky Van Liedekerke (liedekef) Date: 2008-10-03 13:21 Message: I'll check this out. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=108956&aid=2138508&group_id=8956 |
|
From: SourceForge.net <no...@so...> - 2009-04-04 21:18:05
|
Bugs item #2138508, was opened at 2008-09-30 18:04 Message generated for change (Comment added) made by bochoven You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=108956&aid=2138508&group_id=8956 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Admin Group: 2.1.2 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jonathan Hughes (xerxesii) Assigned to: Franky Van Liedekerke (liedekef) Summary: group manager cannot do much managing Initial Comment: A group manager cannot add a new designer using the forms interface, or perform other tasks such as changing user flags. Message is "This account does not have permission to access this group". Batch submission works OK. Cannot duplicate on demo site since user doesn't have this capability. ---------------------------------------------------------------------- Comment By: Arjen van Bochoven (bochoven) Date: 2009-04-04 23:18 Message: Ok, you probably read the mailinglist, but just to be sure here's the culprit: I guess in order to prepare for a mysql query, the variable containing the group is padded with quotes. This causes the check for the group to fail. To fix it, edit admin/include/where/admdesigner.inc on line 155 replace in_array($r, $_SESSION['acl']['pgroup']) || with in_array(trim($r, "'"), $_SESSION['acl']['pgroup']) || ---------------------------------------------------------------------- Comment By: Franky Van Liedekerke (liedekef) Date: 2009-04-04 14:38 Message: Hmmm ... appparently closed for the wrong reason (I based myself on the comment that it was fixed without looking at the poster). I'm going to check this out (again) when I have the time. Franky ---------------------------------------------------------------------- Comment By: Jonathan Hughes (xerxesii) Date: 2008-10-03 18:18 Message: Suggested fix doesn't have any effect! ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2008-10-03 14:49 Message: I've found it, it was nnot a bug but a configuration matter. In the default config file (phpESP.ini.php.default) the setting is as followed: $ESPCONFIG['limit_double_postings'] = 3; By adding the next line to phpESP.ini.php the problem is solved $ESPCONFIG['limit_double_postings'] = 0; Greetings Arjan ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2008-10-03 14:49 Message: I've found it, it was nnot a bug but a configuration matter. In the default config file (phpESP.ini.php.default) the setting is as followed: $ESPCONFIG['limit_double_postings'] = 3; By adding the next line to phpESP.ini.php the problem is solved $ESPCONFIG['limit_double_postings'] = 0; Greetings Arjan ---------------------------------------------------------------------- Comment By: Franky Van Liedekerke (liedekef) Date: 2008-10-03 13:21 Message: I'll check this out. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=108956&aid=2138508&group_id=8956 |
|
From: SourceForge.net <no...@so...> - 2009-04-04 12:38:19
|
Bugs item #2138508, was opened at 2008-09-30 18:04 Message generated for change (Comment added) made by liedekef You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=108956&aid=2138508&group_id=8956 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Admin >Group: 2.1.2 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jonathan Hughes (xerxesii) Assigned to: Franky Van Liedekerke (liedekef) Summary: group manager cannot do much managing Initial Comment: A group manager cannot add a new designer using the forms interface, or perform other tasks such as changing user flags. Message is "This account does not have permission to access this group". Batch submission works OK. Cannot duplicate on demo site since user doesn't have this capability. ---------------------------------------------------------------------- >Comment By: Franky Van Liedekerke (liedekef) Date: 2009-04-04 14:38 Message: Hmmm ... appparently closed for the wrong reason (I based myself on the comment that it was fixed without looking at the poster). I'm going to check this out (again) when I have the time. Franky ---------------------------------------------------------------------- Comment By: Jonathan Hughes (xerxesii) Date: 2008-10-03 18:18 Message: Suggested fix doesn't have any effect! ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2008-10-03 14:49 Message: I've found it, it was nnot a bug but a configuration matter. In the default config file (phpESP.ini.php.default) the setting is as followed: $ESPCONFIG['limit_double_postings'] = 3; By adding the next line to phpESP.ini.php the problem is solved $ESPCONFIG['limit_double_postings'] = 0; Greetings Arjan ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2008-10-03 14:49 Message: I've found it, it was nnot a bug but a configuration matter. In the default config file (phpESP.ini.php.default) the setting is as followed: $ESPCONFIG['limit_double_postings'] = 3; By adding the next line to phpESP.ini.php the problem is solved $ESPCONFIG['limit_double_postings'] = 0; Greetings Arjan ---------------------------------------------------------------------- Comment By: Franky Van Liedekerke (liedekef) Date: 2008-10-03 13:21 Message: I'll check this out. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=108956&aid=2138508&group_id=8956 |
|
From: SourceForge.net <no...@so...> - 2009-04-04 12:37:12
|
Bugs item #2138508, was opened at 2008-09-30 18:04 Message generated for change (Settings changed) made by liedekef You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=108956&aid=2138508&group_id=8956 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Admin Group: v2.0.2 >Status: Open >Resolution: None Priority: 5 Private: No Submitted By: Jonathan Hughes (xerxesii) Assigned to: Franky Van Liedekerke (liedekef) Summary: group manager cannot do much managing Initial Comment: A group manager cannot add a new designer using the forms interface, or perform other tasks such as changing user flags. Message is "This account does not have permission to access this group". Batch submission works OK. Cannot duplicate on demo site since user doesn't have this capability. ---------------------------------------------------------------------- Comment By: Jonathan Hughes (xerxesii) Date: 2008-10-03 18:18 Message: Suggested fix doesn't have any effect! ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2008-10-03 14:49 Message: I've found it, it was nnot a bug but a configuration matter. In the default config file (phpESP.ini.php.default) the setting is as followed: $ESPCONFIG['limit_double_postings'] = 3; By adding the next line to phpESP.ini.php the problem is solved $ESPCONFIG['limit_double_postings'] = 0; Greetings Arjan ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2008-10-03 14:49 Message: I've found it, it was nnot a bug but a configuration matter. In the default config file (phpESP.ini.php.default) the setting is as followed: $ESPCONFIG['limit_double_postings'] = 3; By adding the next line to phpESP.ini.php the problem is solved $ESPCONFIG['limit_double_postings'] = 0; Greetings Arjan ---------------------------------------------------------------------- Comment By: Franky Van Liedekerke (liedekef) Date: 2008-10-03 13:21 Message: I'll check this out. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=108956&aid=2138508&group_id=8956 |
|
From: SourceForge.net <no...@so...> - 2009-03-23 20:31:44
|
Bugs item #2672129, was opened at 2009-03-08 06:21 Message generated for change (Comment added) made by liedekef You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=108956&aid=2672129&group_id=8956 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Admin Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: kswartz (kswartz) Assigned to: bishop (bishopb) Summary: Copy survey reorders positions starting with 1 instead of 0 Initial Comment: When you initialize $pos before looping through the calls to survey_copy_questions, you set it to 1, so the first copied question has position=1. However, when you define questions for a survey, the first question's position is set to 0. The application works fine with this bug in place UNTIL you go to copy conditions. That requires matching the questions from the new survey and the old survey, and the only way to do that is to match on the columns position and deleted. With this bug, however, the position columns do not correspond, so the question that was in position 1 in the old survey is in position 2 in the new survey. The fix requires changing only two lines in survey_aggregate.inc: $ diff survey_aggregate_old.inc survey_aggregate.inc 74c74 < $pos = 1; --- > $pos = 0; 85c85 < function survey_copy_questions($sid, $new_sid, $pos = 1) { --- > function survey_copy_questions($sid, $new_sid, $pos = 0) { ---------------------------------------------------------------------- Comment By: Franky Van Liedekerke (liedekef) Date: 2009-03-23 21:31 Message: Well, I don't think it matters :-) Or more: to fix the ones starting at "1" would be very troublesome ... the damage there is already done (if you have conditions in place). But after the fix is in place, it wouldn't matter: you start at position 0 in source and destination, even if position 0 is not defined it should still be ok, no? Franky ---------------------------------------------------------------------- Comment By: kswartz (kswartz) Date: 2009-03-09 04:45 Message: I haven't looked through the code yet for the initial "0" position, but I can say that every survey I've created has 0 as the value of position for the first question. I would expect that this gets set when using the section to reorder the questions in creating a new survey. One question (no pun intended) is whether or not it starts with "0" if you do NOT reorder the questions; i.e.: if you only create a question and exit. However, I think it doesn't really matter, and here's why... As soon as we introduce the code to copy conditions (which is dependent on this change), it's going to rely on the fact that positions between original and copied surveys always start with the same value. Today, some surveys will start with 0 and some start with 1. So the next release will have to include an upgrade script that cleans this up, by updating the position column so that ALL surveys start with the same value. I'm inclined to say that value should be 0, based on what I'm seeing from the surveys I've created from scratch and your last comment, bishopb. ---------------------------------------------------------------------- Comment By: bishop (bishopb) Date: 2009-03-08 20:50 Message: I am inclined to think that 0 is the correct position, and since I was the most recent to work in that area of the (really old) code, I'll take on this issue. kswartz: are you seeing the initial definition of 0 somewhere specifically in the code, or only as a post facto artifact in the generated rows? ---------------------------------------------------------------------- Comment By: Franky Van Liedekerke (liedekef) Date: 2009-03-08 18:27 Message: Hmmm ... I don't remember as well, probably the oldest programmer for that part was way before me ... Franky ---------------------------------------------------------------------- Comment By: bishop (bishopb) Date: 2009-03-08 13:15 Message: survey_aggregate() is a generalization of the original survey_copy() code, and in fact the survey_copy_questions() helper function is a direct descendant of the original survey_copy(). In the original survey_copy(), $pos was initialized to 1: 65 $pos=1; 66 array_shift($question_fields); 67 while($question = fetch_row($result)) { 68 $result->MoveNext(); 69 $tid = $question['type_id']; 70 $qid = $question['id']; 71 // fix some fields first 72 $question['survey_id'] = $new_sid; 73 $question['position'] = $pos++; So, I can say that if this is a bug, it's existed for a while. Is anyone here familiar with the older code from survey_copy() that can comment on this? ---------------------------------------------------------------------- Comment By: kswartz (kswartz) Date: 2009-03-08 06:22 Message: File Added: survey_aggregate.inc ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=108956&aid=2672129&group_id=8956 |
|
From: SourceForge.net <no...@so...> - 2009-03-23 10:25:58
|
Bugs item #2674394, was opened at 2009-03-09 09:03 Message generated for change (Comment added) made by liedekef You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=108956&aid=2674394&group_id=8956 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: SQL Group: None Status: Closed Resolution: Fixed Priority: 7 Private: No Submitted By: kswartz (kswartz) Assigned to: bishop (bishopb) Summary: Dashboard returns no surveys due to ambiguous column in SQL Initial Comment: I'm using PHP version 2.1.2 (which isn't in the Group box, by the way -- that should be fixed.) This SQL is executed in survey_get_in_realm(): SELECT DISTINCT tblSurvey.id, tblSurvey.name, tblSurvey.title, tblSurvey.owner, tblSurvey.open_date, tblSurvey.close_date FROM survey AS tblSurvey JOIN access AS tblAccess ON tblAccess.survey_id=tblSurvey.id WHERE (tblSurvey.realm = 'auto' OR tblAccess.realm = 'auto') AND $where However, $where is computed in survey_fetch_limiting_where as this: (((status & 3)) AND (NOT (status & 4)) AND (owner='kswartz' OR realm IS NULL)) ORDER BY id DESC When you combine the two, the SQL statement fails because of an ambiguous reference to realm, which appears in both of the tables being joined. As a result, when users log in to take a survey in my install, they never see anything listed. (I'm using MySQL 5.0, but this error would happen with any database.) The easiest fix is one line: 184c184 < $where = survey_fetch_limiting_where(); --- > $where = survey_fetch_limiting_where('status','owner','tblSurvey.realm'); ---------------------------------------------------------------------- >Comment By: Franky Van Liedekerke (liedekef) Date: 2009-03-23 11:25 Message: great! tx, bishop! ---------------------------------------------------------------------- Comment By: bishop (bishopb) Date: 2009-03-23 11:17 Message: Franky said> is this a valid fix? Then it should get in asap ... A more general fix was called for: specifically, the user's realms needed to be checked against both the survey's explicit realm and the realms granted access to the survey via the access table. I've committed my fix to trunk (rev 1108). kswartz, I'd appreciate a ping back to confirm this fix works in your use case. Thanks, and thanks for helping improve phpESP! ---------------------------------------------------------------------- Comment By: Franky Van Liedekerke (liedekef) Date: 2009-03-22 13:53 Message: Bishop, is this a valid fix? Then it should get in asap ... Franky ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=108956&aid=2674394&group_id=8956 |
|
From: SourceForge.net <no...@so...> - 2009-03-23 10:18:10
|
Bugs item #2674394, was opened at 2009-03-09 04:03 Message generated for change (Settings changed) made by bishopb You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=108956&aid=2674394&group_id=8956 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: SQL Group: None Status: Closed Resolution: Fixed Priority: 7 Private: No Submitted By: kswartz (kswartz) Assigned to: bishop (bishopb) Summary: Dashboard returns no surveys due to ambiguous column in SQL Initial Comment: I'm using PHP version 2.1.2 (which isn't in the Group box, by the way -- that should be fixed.) This SQL is executed in survey_get_in_realm(): SELECT DISTINCT tblSurvey.id, tblSurvey.name, tblSurvey.title, tblSurvey.owner, tblSurvey.open_date, tblSurvey.close_date FROM survey AS tblSurvey JOIN access AS tblAccess ON tblAccess.survey_id=tblSurvey.id WHERE (tblSurvey.realm = 'auto' OR tblAccess.realm = 'auto') AND $where However, $where is computed in survey_fetch_limiting_where as this: (((status & 3)) AND (NOT (status & 4)) AND (owner='kswartz' OR realm IS NULL)) ORDER BY id DESC When you combine the two, the SQL statement fails because of an ambiguous reference to realm, which appears in both of the tables being joined. As a result, when users log in to take a survey in my install, they never see anything listed. (I'm using MySQL 5.0, but this error would happen with any database.) The easiest fix is one line: 184c184 < $where = survey_fetch_limiting_where(); --- > $where = survey_fetch_limiting_where('status','owner','tblSurvey.realm'); ---------------------------------------------------------------------- Comment By: bishop (bishopb) Date: 2009-03-23 06:17 Message: Franky said> is this a valid fix? Then it should get in asap ... A more general fix was called for: specifically, the user's realms needed to be checked against both the survey's explicit realm and the realms granted access to the survey via the access table. I've committed my fix to trunk (rev 1108). kswartz, I'd appreciate a ping back to confirm this fix works in your use case. Thanks, and thanks for helping improve phpESP! ---------------------------------------------------------------------- Comment By: Franky Van Liedekerke (liedekef) Date: 2009-03-22 08:53 Message: Bishop, is this a valid fix? Then it should get in asap ... Franky ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=108956&aid=2674394&group_id=8956 |
|
From: SourceForge.net <no...@so...> - 2009-03-23 10:17:39
|
Bugs item #2674394, was opened at 2009-03-09 04:03 Message generated for change (Comment added) made by bishopb You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=108956&aid=2674394&group_id=8956 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: SQL Group: None >Status: Closed >Resolution: Fixed >Priority: 7 Private: No Submitted By: kswartz (kswartz) Assigned to: bishop (bishopb) Summary: Dashboard returns no surveys due to ambiguous column in SQL Initial Comment: I'm using PHP version 2.1.2 (which isn't in the Group box, by the way -- that should be fixed.) This SQL is executed in survey_get_in_realm(): SELECT DISTINCT tblSurvey.id, tblSurvey.name, tblSurvey.title, tblSurvey.owner, tblSurvey.open_date, tblSurvey.close_date FROM survey AS tblSurvey JOIN access AS tblAccess ON tblAccess.survey_id=tblSurvey.id WHERE (tblSurvey.realm = 'auto' OR tblAccess.realm = 'auto') AND $where However, $where is computed in survey_fetch_limiting_where as this: (((status & 3)) AND (NOT (status & 4)) AND (owner='kswartz' OR realm IS NULL)) ORDER BY id DESC When you combine the two, the SQL statement fails because of an ambiguous reference to realm, which appears in both of the tables being joined. As a result, when users log in to take a survey in my install, they never see anything listed. (I'm using MySQL 5.0, but this error would happen with any database.) The easiest fix is one line: 184c184 < $where = survey_fetch_limiting_where(); --- > $where = survey_fetch_limiting_where('status','owner','tblSurvey.realm'); ---------------------------------------------------------------------- >Comment By: bishop (bishopb) Date: 2009-03-23 06:17 Message: Franky said> is this a valid fix? Then it should get in asap ... A more general fix was called for: specifically, the user's realms needed to be checked against both the survey's explicit realm and the realms granted access to the survey via the access table. I've committed my fix to trunk (rev 1108). kswartz, I'd appreciate a ping back to confirm this fix works in your use case. Thanks, and thanks for helping improve phpESP! ---------------------------------------------------------------------- Comment By: Franky Van Liedekerke (liedekef) Date: 2009-03-22 08:53 Message: Bishop, is this a valid fix? Then it should get in asap ... Franky ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=108956&aid=2674394&group_id=8956 |
|
From: SourceForge.net <no...@so...> - 2009-03-23 09:40:15
|
Bugs item #1145732, was opened at 2005-02-21 21:50 Message generated for change (Comment added) made by liedekef You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=108956&aid=1145732&group_id=8956 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: User Group: v1.7 >Status: Closed Resolution: None Priority: 5 Private: No Submitted By: Mark Jansen (trombonefreakus) Assigned to: Nobody/Anonymous (nobody) Summary: totals in cross-tabs and report do not match Initial Comment: Both in version 1.6.1 and version 1.7 just downloaded, I have different totals when viewing a cross-tabluated result and a total result. The crossed totals even have different total values accross the questions, while the survey totals are always lower than any crossed survey total. So, I have a crossed result with a total numbers of respondents of 1987 and one with 1967 respondents, while the overall survey has 1952 responses. How is this possible??? Does phpESP uses only the respondents who completed the entire survey for the survey results, while using also respondents who quitted before finishing the survey for the crossed results?? I desperately need to know this, since I used the software for quite an important survey. Thanks! ---------------------------------------------------------------------- Comment By: Franky Van Liedekerke (liedekef) Date: 2009-03-23 10:40 Message: The latest production release already contains the fix, please update. ---------------------------------------------------------------------- Comment By: Matthew Gregg (greggmc) Date: 2005-02-21 23:49 Message: Logged In: YES user_id=14116 You can increase the timeout and/or memory limit in the php.ini on your server, to allow the CSV export to complete. ---------------------------------------------------------------------- Comment By: Mark Jansen (trombonefreakus) Date: 2005-02-21 22:59 Message: Logged In: YES user_id=1224545 Well, downloading the data gives a timeout, so I can't use alternatives either. And I would like to suggest to reconsider removing this code, since without this one would need extra (commercial) software, while phpESP can do it for free right now (but not completely accurate though....). ---------------------------------------------------------------------- Comment By: Matthew Gregg (greggmc) Date: 2005-02-21 22:03 Message: Logged In: YES user_id=14116 A quick view of the source shows that it should be using only completed surveys for both. Without looking closely at your data I can't determine what may be the problem. It very well could be a bug in ESP's crosstab code. My advice would be to export the data out of ESP and run your cross in a tool more suited to analysis. FYI, I'm considering removing the cross code for future releases(unless someone wants to fix/maintain that code) as ESP should be the very best tool for data collection and leave the data analysis to sas/spss/excel/etc. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=108956&aid=1145732&group_id=8956 |
|
From: SourceForge.net <no...@so...> - 2009-03-23 09:38:52
|
Bugs item #1545415, was opened at 2006-08-23 18:58 Message generated for change (Settings changed) made by liedekef You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=108956&aid=1545415&group_id=8956 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed Resolution: None Priority: 5 Private: No Submitted By: Daniel Fetzer (danielfetzer) Assigned to: Nobody/Anonymous (nobody) Summary: hardcoded strings in default.js Initial Comment: There are hardcoded string int the default.js, should be exchanged by variables ---------------------------------------------------------------------- Comment By: Franky Van Liedekerke (liedekef) Date: 2009-03-23 10:38 Message: The latest production release already contains the fix, please update. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=108956&aid=1545415&group_id=8956 |
|
From: SourceForge.net <no...@so...> - 2009-03-22 12:53:23
|
Bugs item #2674394, was opened at 2009-03-09 09:03 Message generated for change (Comment added) made by liedekef You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=108956&aid=2674394&group_id=8956 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: SQL Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: kswartz (kswartz) Assigned to: bishop (bishopb) Summary: Dashboard returns no surveys due to ambiguous column in SQL Initial Comment: I'm using PHP version 2.1.2 (which isn't in the Group box, by the way -- that should be fixed.) This SQL is executed in survey_get_in_realm(): SELECT DISTINCT tblSurvey.id, tblSurvey.name, tblSurvey.title, tblSurvey.owner, tblSurvey.open_date, tblSurvey.close_date FROM survey AS tblSurvey JOIN access AS tblAccess ON tblAccess.survey_id=tblSurvey.id WHERE (tblSurvey.realm = 'auto' OR tblAccess.realm = 'auto') AND $where However, $where is computed in survey_fetch_limiting_where as this: (((status & 3)) AND (NOT (status & 4)) AND (owner='kswartz' OR realm IS NULL)) ORDER BY id DESC When you combine the two, the SQL statement fails because of an ambiguous reference to realm, which appears in both of the tables being joined. As a result, when users log in to take a survey in my install, they never see anything listed. (I'm using MySQL 5.0, but this error would happen with any database.) The easiest fix is one line: 184c184 < $where = survey_fetch_limiting_where(); --- > $where = survey_fetch_limiting_where('status','owner','tblSurvey.realm'); ---------------------------------------------------------------------- >Comment By: Franky Van Liedekerke (liedekef) Date: 2009-03-22 13:53 Message: Bishop, is this a valid fix? Then it should get in asap ... Franky ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=108956&aid=2674394&group_id=8956 |
|
From: SourceForge.net <no...@so...> - 2009-03-12 01:18:15
|
Bugs item #2684265, was opened at 2009-03-12 01:18 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=108956&aid=2684265&group_id=8956 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: demo: cannot create new survey Initial Comment: Creating a new survey does not work in the online demo. Replication: - click on "New Survey" - fill in all fields marked "Required"[red text] - click "Continue" Expected result: - a new page Actual result: - same page, buttons on top to navigate to other sections do not work Severity: Highest severity: application is useless without ability to make new surveys ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=108956&aid=2684265&group_id=8956 |
|
From: SourceForge.net <no...@so...> - 2009-03-10 21:34:03
|
Feature Requests item #1950791, was opened at 2008-04-24 07:08 Message generated for change (Comment added) made by kswartz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=358956&aid=1950791&group_id=8956 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Priority: 5 Private: No Submitted By: piccirm (piccirm) Assigned to: Nobody/Anonymous (nobody) Summary: Customer pick list Initial Comment: In order to insert a survey collected from another users (customer) it 'd be possibile to associate a survey to a user o customer with a functionality that provide a search a pick of a particular user/customer pi...@wy... ---------------------------------------------------------------------- Comment By: kswartz (kswartz) Date: 2009-03-10 14:33 Message: Actually it sounds to me like this is a request to query survey results by user, rather than by an arbitrary counter. If so, I was planning on making that request myself, and I have a code fix to provide this behavior. But this pretty much only works with surveys marked as private. ---------------------------------------------------------------------- Comment By: bishop (bishopb) Date: 2008-04-24 07:13 Message: Logged In: YES user_id=1982963 Originator: NO If I understand the request, I presently handle this by writing custom tables and joining those against respondent (and by association, survey). It's on my as-yet-unpublished wish list for the next major version to easily support pluggable auxiliary data fields for respondents (and possibly surveys), thus allowing a particular survey run to better represent the user population. (Note that this doesn't imply this functionality will make it into the next version; it's only on my wish list at this time.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=358956&aid=1950791&group_id=8956 |
|
From: SourceForge.net <no...@so...> - 2009-03-10 21:30:52
|
Feature Requests item #2676835, was opened at 2009-03-09 16:46 Message generated for change (Comment added) made by kswartz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=358956&aid=2676835&group_id=8956 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Open Priority: 5 Private: No Submitted By: kswartz (kswartz) Assigned to: Nobody/Anonymous (nobody) Summary: Need ability for user to delete incomplete survey Initial Comment: I've been making numerous enhancements to phpESP on my own (many of which I'm about to work on giving back), but I'm a bit stumped on how to move forward on this one, and would like some advice (in the absence of an actual fix). We have a lengthy survey that may be filled out multiple times by our users. The survey has about 100 questions, and may be done over a period of a few days, while the respondent does some research. We've found that occasionally, a user will want to scrap the survey completely, but still enter a new one. However, any time they sign in and try to start the survey, it always uses their saved one, and starts them where they left off. We want to introduce the option to DELETE a saved-but-incomplete survey from the dashboard page. I'm up for working on this code myself, but need some advice. Is there a good way to securely reuse the code that does this in the admin pages? Unlike the admin pages, a user doesn't have to be a superuser to delete his OWN survey. Right now, the workaround we have is to resume the saved survey, and hit the "Previous Page" button all the way back to page 1. Unfortunately, at 20 pages, that's a bit painful. I am visualizing an additional column on the dashboard page, called "Action". It can show a link to delete a saved survey, OR a link to view (or edit, depending on whether the survey would support it) any previously submitted copies of the survey. That's a separate enhancement request; I just wanted to mention how I saw this one fitting into a bigger picture. ---------------------------------------------------------------------- >Comment By: kswartz (kswartz) Date: 2009-03-10 14:30 Message: This is the URL I was using to try and jump to page 1: http://localhost/techeval/public/survey.php?sec=1&name=ebstecheval However, it just reloads the page I saved on. When I do a view source, I see this: <input type="hidden" name="userid" value="sec=1" /> <input type="hidden" name="sid" value="3" /> <input type="hidden" name="rid" value="113" /> <input type="hidden" name="sec" value="3" /> Not sure if it's relevant, but this is a private survey, with navigation and save/resume enabled. Of course, overriding the URL on the browser bar is mixing GET parameters with POST parameters. If handler.php looks at the POST parameter over the GET one, then putting it in a URL won't work. I'll have to use a JavaScript handler to update the sec hidden field to something like 2, then pretend the user hit the Prev button. (I don't even know if that'll work, just a guess.) --- I totally agree about productizing any such solution. I would also want to harden it by comparing the owner of the current session and the owner of the survey, and only allow a delete (or reset) if they match. The per-survey control is something I can forego for my own purposes, although I would certainly agree with the need for that in the product. Regarding the resetting option, when you say: "Nonetheless, I don't think a survey_reset() would waste the response table rows: it would simply update them to the default values (eg null).", I see a problem with that if the questions are marked as required. It might technically work if you're only enforcing that constraint through the UI, but I'm visualizing a scenario in which the user manually tweaks the URL to jump to the last page and submit his survey -- now full of unanswered questions that require a value. (I'm also making an assumption here that a null value is not an acceptable answer when one is required. Functionally, I think that's appropriate.) ---------------------------------------------------------------------- Comment By: bishop (bishopb) Date: 2009-03-10 11:50 Message: I would think that sec=1 would do it, as that sets the section. Upon cursory review of the code (handler.php down to survey_render.php), that looks correct. Can you include your modified URL and a little more description of the "sets the hidden user id parameter to 'sec=1'" problem? Re: survey_reset() vs. survey_delete(). Your situation does sound like it could go both ways, so the easiest thing to do would be to link to a "delete" handler right on the survey. That handler (say delete.php) takes the response ID and blows away the survey (via survey_delete()), then links back (or throws a header) to the dashboard. That would be ad-hoc and could be kept out of the phpESP source tree for your own use. But, to implement this to production would require some more fortification. The delete handler, for example, would need to also corroborate the SID to prevent delete attacks. We would also want to add per-survey control over whether responses may be deleted by the respondent. Were there to be a survey_reset(), that would need to figure out the default values and set the entries to those defaults, opting to null if no defaults were defined. (I don't recall if we have a definition of "default values", so setting to null always would be appropriate.) Nonetheless, I don't think a survey_reset() would waste the response table rows: it would simply update them to the default values (eg null). (And then possibly increment a reset_counter in the statistics table.) ---------------------------------------------------------------------- Comment By: kswartz (kswartz) Date: 2009-03-10 10:59 Message: BTW, I've joined the developer's mailing list. If that is a more appropriate forum for discussions of this nature in the future, please let me know, and I'll do that. I logged a request mainly because I thought there was strong support for this to be a generic enhancement, and there might be a patch resulting from the discussion (possibly from me). ---------------------------------------------------------------------- Comment By: kswartz (kswartz) Date: 2009-03-10 10:58 Message: This is great. Thank you for the ideas! How do you link back to the first page of a survey? I tried adding "&sec=1" to the URL, but then it sets the hidden userid parameter to "sec=1". (That looks like a bug, by the way. :) ) Actually, my use case is really more of a deletion, than a reset, but either one would work. The survey we've implemented is used to request and gather information about using another software product in conjunction with our own. The use case I envision is that the respondent decides they don't want to use that product after doing the research. But the survey has to be filled out once for each product they want to use, so if the user finds something else he wants to use, he has to fill out a new survey, starting from scratch. In our case, nothing from the original survey would be preserved, except for about 3 questions (of roughly 100) with information identifying the requester. [If this were going to be a 100% custom solution for us, I might consider preserving that data. I've been trying not to make too many changes like that, however, as it'll make it harder for me to contribute other fixes I've made back to the project.] Now, in our case, there are no default values -- everything is blank to start out. In that case, the only difference between resetting and deleting the survey that I can see is that deleting it removes a row from the response table. Both options would still remove all the rows from the response_* child tables (again, that's specific to this case, where none of the questions have default values). Is that an accurate assessment? Thanks again. ---------------------------------------------------------------------- Comment By: bishop (bishopb) Date: 2009-03-10 05:13 Message: I'm with Franky, at least in addressing a valid navigation use case ("user wants to review or change submitted responses, starting from the beginning"). I'd also like to define the semantic differences of "resetting" a survey's responses and "deleting" a survey. The former keeps the survey, but initializes responses to default values. The latter removes any indication that the user every began the survey. It's entirely possible that "resetting" is allowed (and desired), but "deleting" is not. I can also see cases where you'd want to record the number of resets (for statistical analysis on the effectiveness of your surveys). Your description of the problem sounds more like resetting, than deleting. If that is the case, I would not reuse the admin survey_delete() code based on response ID. Instead, I'd write a new function (say survey_reset()) and expose it both in admin (keyed off of response ID) and in userland (as at least a link on the survey itself, possibly (though not recommended) with a link on the dashboard). ---------------------------------------------------------------------- Comment By: Franky Van Liedekerke (liedekef) Date: 2009-03-10 00:36 Message: How about just providing a link to the first page of the survey? You can do this at the bottom, top, anywhere within the current survey ... Franky ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=358956&aid=2676835&group_id=8956 |
|
From: SourceForge.net <no...@so...> - 2009-03-10 18:50:30
|
Feature Requests item #2676835, was opened at 2009-03-09 19:46 Message generated for change (Comment added) made by bishopb You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=358956&aid=2676835&group_id=8956 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. >Category: None >Group: None >Status: Pending Priority: 5 Private: No Submitted By: kswartz (kswartz) Assigned to: Nobody/Anonymous (nobody) Summary: Need ability for user to delete incomplete survey Initial Comment: I've been making numerous enhancements to phpESP on my own (many of which I'm about to work on giving back), but I'm a bit stumped on how to move forward on this one, and would like some advice (in the absence of an actual fix). We have a lengthy survey that may be filled out multiple times by our users. The survey has about 100 questions, and may be done over a period of a few days, while the respondent does some research. We've found that occasionally, a user will want to scrap the survey completely, but still enter a new one. However, any time they sign in and try to start the survey, it always uses their saved one, and starts them where they left off. We want to introduce the option to DELETE a saved-but-incomplete survey from the dashboard page. I'm up for working on this code myself, but need some advice. Is there a good way to securely reuse the code that does this in the admin pages? Unlike the admin pages, a user doesn't have to be a superuser to delete his OWN survey. Right now, the workaround we have is to resume the saved survey, and hit the "Previous Page" button all the way back to page 1. Unfortunately, at 20 pages, that's a bit painful. I am visualizing an additional column on the dashboard page, called "Action". It can show a link to delete a saved survey, OR a link to view (or edit, depending on whether the survey would support it) any previously submitted copies of the survey. That's a separate enhancement request; I just wanted to mention how I saw this one fitting into a bigger picture. ---------------------------------------------------------------------- >Comment By: bishop (bishopb) Date: 2009-03-10 14:50 Message: I would think that sec=1 would do it, as that sets the section. Upon cursory review of the code (handler.php down to survey_render.php), that looks correct. Can you include your modified URL and a little more description of the "sets the hidden user id parameter to 'sec=1'" problem? Re: survey_reset() vs. survey_delete(). Your situation does sound like it could go both ways, so the easiest thing to do would be to link to a "delete" handler right on the survey. That handler (say delete.php) takes the response ID and blows away the survey (via survey_delete()), then links back (or throws a header) to the dashboard. That would be ad-hoc and could be kept out of the phpESP source tree for your own use. But, to implement this to production would require some more fortification. The delete handler, for example, would need to also corroborate the SID to prevent delete attacks. We would also want to add per-survey control over whether responses may be deleted by the respondent. Were there to be a survey_reset(), that would need to figure out the default values and set the entries to those defaults, opting to null if no defaults were defined. (I don't recall if we have a definition of "default values", so setting to null always would be appropriate.) Nonetheless, I don't think a survey_reset() would waste the response table rows: it would simply update them to the default values (eg null). (And then possibly increment a reset_counter in the statistics table.) ---------------------------------------------------------------------- Comment By: kswartz (kswartz) Date: 2009-03-10 13:59 Message: BTW, I've joined the developer's mailing list. If that is a more appropriate forum for discussions of this nature in the future, please let me know, and I'll do that. I logged a request mainly because I thought there was strong support for this to be a generic enhancement, and there might be a patch resulting from the discussion (possibly from me). ---------------------------------------------------------------------- Comment By: kswartz (kswartz) Date: 2009-03-10 13:58 Message: This is great. Thank you for the ideas! How do you link back to the first page of a survey? I tried adding "&sec=1" to the URL, but then it sets the hidden userid parameter to "sec=1". (That looks like a bug, by the way. :) ) Actually, my use case is really more of a deletion, than a reset, but either one would work. The survey we've implemented is used to request and gather information about using another software product in conjunction with our own. The use case I envision is that the respondent decides they don't want to use that product after doing the research. But the survey has to be filled out once for each product they want to use, so if the user finds something else he wants to use, he has to fill out a new survey, starting from scratch. In our case, nothing from the original survey would be preserved, except for about 3 questions (of roughly 100) with information identifying the requester. [If this were going to be a 100% custom solution for us, I might consider preserving that data. I've been trying not to make too many changes like that, however, as it'll make it harder for me to contribute other fixes I've made back to the project.] Now, in our case, there are no default values -- everything is blank to start out. In that case, the only difference between resetting and deleting the survey that I can see is that deleting it removes a row from the response table. Both options would still remove all the rows from the response_* child tables (again, that's specific to this case, where none of the questions have default values). Is that an accurate assessment? Thanks again. ---------------------------------------------------------------------- Comment By: bishop (bishopb) Date: 2009-03-10 08:13 Message: I'm with Franky, at least in addressing a valid navigation use case ("user wants to review or change submitted responses, starting from the beginning"). I'd also like to define the semantic differences of "resetting" a survey's responses and "deleting" a survey. The former keeps the survey, but initializes responses to default values. The latter removes any indication that the user every began the survey. It's entirely possible that "resetting" is allowed (and desired), but "deleting" is not. I can also see cases where you'd want to record the number of resets (for statistical analysis on the effectiveness of your surveys). Your description of the problem sounds more like resetting, than deleting. If that is the case, I would not reuse the admin survey_delete() code based on response ID. Instead, I'd write a new function (say survey_reset()) and expose it both in admin (keyed off of response ID) and in userland (as at least a link on the survey itself, possibly (though not recommended) with a link on the dashboard). ---------------------------------------------------------------------- Comment By: Franky Van Liedekerke (liedekef) Date: 2009-03-10 03:36 Message: How about just providing a link to the first page of the survey? You can do this at the bottom, top, anywhere within the current survey ... Franky ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=358956&aid=2676835&group_id=8956 |
|
From: SourceForge.net <no...@so...> - 2009-03-10 17:59:24
|
Bugs item #2676835, was opened at 2009-03-09 16:46 Message generated for change (Comment added) made by kswartz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=108956&aid=2676835&group_id=8956 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: User Group: v2.0.2 Status: Open Resolution: None Priority: 5 Private: No Submitted By: kswartz (kswartz) Assigned to: Nobody/Anonymous (nobody) Summary: Need ability for user to delete incomplete survey Initial Comment: I've been making numerous enhancements to phpESP on my own (many of which I'm about to work on giving back), but I'm a bit stumped on how to move forward on this one, and would like some advice (in the absence of an actual fix). We have a lengthy survey that may be filled out multiple times by our users. The survey has about 100 questions, and may be done over a period of a few days, while the respondent does some research. We've found that occasionally, a user will want to scrap the survey completely, but still enter a new one. However, any time they sign in and try to start the survey, it always uses their saved one, and starts them where they left off. We want to introduce the option to DELETE a saved-but-incomplete survey from the dashboard page. I'm up for working on this code myself, but need some advice. Is there a good way to securely reuse the code that does this in the admin pages? Unlike the admin pages, a user doesn't have to be a superuser to delete his OWN survey. Right now, the workaround we have is to resume the saved survey, and hit the "Previous Page" button all the way back to page 1. Unfortunately, at 20 pages, that's a bit painful. I am visualizing an additional column on the dashboard page, called "Action". It can show a link to delete a saved survey, OR a link to view (or edit, depending on whether the survey would support it) any previously submitted copies of the survey. That's a separate enhancement request; I just wanted to mention how I saw this one fitting into a bigger picture. ---------------------------------------------------------------------- >Comment By: kswartz (kswartz) Date: 2009-03-10 10:59 Message: BTW, I've joined the developer's mailing list. If that is a more appropriate forum for discussions of this nature in the future, please let me know, and I'll do that. I logged a request mainly because I thought there was strong support for this to be a generic enhancement, and there might be a patch resulting from the discussion (possibly from me). ---------------------------------------------------------------------- Comment By: kswartz (kswartz) Date: 2009-03-10 10:58 Message: This is great. Thank you for the ideas! How do you link back to the first page of a survey? I tried adding "&sec=1" to the URL, but then it sets the hidden userid parameter to "sec=1". (That looks like a bug, by the way. :) ) Actually, my use case is really more of a deletion, than a reset, but either one would work. The survey we've implemented is used to request and gather information about using another software product in conjunction with our own. The use case I envision is that the respondent decides they don't want to use that product after doing the research. But the survey has to be filled out once for each product they want to use, so if the user finds something else he wants to use, he has to fill out a new survey, starting from scratch. In our case, nothing from the original survey would be preserved, except for about 3 questions (of roughly 100) with information identifying the requester. [If this were going to be a 100% custom solution for us, I might consider preserving that data. I've been trying not to make too many changes like that, however, as it'll make it harder for me to contribute other fixes I've made back to the project.] Now, in our case, there are no default values -- everything is blank to start out. In that case, the only difference between resetting and deleting the survey that I can see is that deleting it removes a row from the response table. Both options would still remove all the rows from the response_* child tables (again, that's specific to this case, where none of the questions have default values). Is that an accurate assessment? Thanks again. ---------------------------------------------------------------------- Comment By: bishop (bishopb) Date: 2009-03-10 05:13 Message: I'm with Franky, at least in addressing a valid navigation use case ("user wants to review or change submitted responses, starting from the beginning"). I'd also like to define the semantic differences of "resetting" a survey's responses and "deleting" a survey. The former keeps the survey, but initializes responses to default values. The latter removes any indication that the user every began the survey. It's entirely possible that "resetting" is allowed (and desired), but "deleting" is not. I can also see cases where you'd want to record the number of resets (for statistical analysis on the effectiveness of your surveys). Your description of the problem sounds more like resetting, than deleting. If that is the case, I would not reuse the admin survey_delete() code based on response ID. Instead, I'd write a new function (say survey_reset()) and expose it both in admin (keyed off of response ID) and in userland (as at least a link on the survey itself, possibly (though not recommended) with a link on the dashboard). ---------------------------------------------------------------------- Comment By: Franky Van Liedekerke (liedekef) Date: 2009-03-10 00:36 Message: How about just providing a link to the first page of the survey? You can do this at the bottom, top, anywhere within the current survey ... Franky ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=108956&aid=2676835&group_id=8956 |
|
From: SourceForge.net <no...@so...> - 2009-03-10 17:59:18
|
Bugs item #2676835, was opened at 2009-03-09 16:46 Message generated for change (Comment added) made by kswartz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=108956&aid=2676835&group_id=8956 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: User Group: v2.0.2 Status: Open Resolution: None Priority: 5 Private: No Submitted By: kswartz (kswartz) Assigned to: Nobody/Anonymous (nobody) Summary: Need ability for user to delete incomplete survey Initial Comment: I've been making numerous enhancements to phpESP on my own (many of which I'm about to work on giving back), but I'm a bit stumped on how to move forward on this one, and would like some advice (in the absence of an actual fix). We have a lengthy survey that may be filled out multiple times by our users. The survey has about 100 questions, and may be done over a period of a few days, while the respondent does some research. We've found that occasionally, a user will want to scrap the survey completely, but still enter a new one. However, any time they sign in and try to start the survey, it always uses their saved one, and starts them where they left off. We want to introduce the option to DELETE a saved-but-incomplete survey from the dashboard page. I'm up for working on this code myself, but need some advice. Is there a good way to securely reuse the code that does this in the admin pages? Unlike the admin pages, a user doesn't have to be a superuser to delete his OWN survey. Right now, the workaround we have is to resume the saved survey, and hit the "Previous Page" button all the way back to page 1. Unfortunately, at 20 pages, that's a bit painful. I am visualizing an additional column on the dashboard page, called "Action". It can show a link to delete a saved survey, OR a link to view (or edit, depending on whether the survey would support it) any previously submitted copies of the survey. That's a separate enhancement request; I just wanted to mention how I saw this one fitting into a bigger picture. ---------------------------------------------------------------------- >Comment By: kswartz (kswartz) Date: 2009-03-10 10:58 Message: This is great. Thank you for the ideas! How do you link back to the first page of a survey? I tried adding "&sec=1" to the URL, but then it sets the hidden userid parameter to "sec=1". (That looks like a bug, by the way. :) ) Actually, my use case is really more of a deletion, than a reset, but either one would work. The survey we've implemented is used to request and gather information about using another software product in conjunction with our own. The use case I envision is that the respondent decides they don't want to use that product after doing the research. But the survey has to be filled out once for each product they want to use, so if the user finds something else he wants to use, he has to fill out a new survey, starting from scratch. In our case, nothing from the original survey would be preserved, except for about 3 questions (of roughly 100) with information identifying the requester. [If this were going to be a 100% custom solution for us, I might consider preserving that data. I've been trying not to make too many changes like that, however, as it'll make it harder for me to contribute other fixes I've made back to the project.] Now, in our case, there are no default values -- everything is blank to start out. In that case, the only difference between resetting and deleting the survey that I can see is that deleting it removes a row from the response table. Both options would still remove all the rows from the response_* child tables (again, that's specific to this case, where none of the questions have default values). Is that an accurate assessment? Thanks again. ---------------------------------------------------------------------- Comment By: bishop (bishopb) Date: 2009-03-10 05:13 Message: I'm with Franky, at least in addressing a valid navigation use case ("user wants to review or change submitted responses, starting from the beginning"). I'd also like to define the semantic differences of "resetting" a survey's responses and "deleting" a survey. The former keeps the survey, but initializes responses to default values. The latter removes any indication that the user every began the survey. It's entirely possible that "resetting" is allowed (and desired), but "deleting" is not. I can also see cases where you'd want to record the number of resets (for statistical analysis on the effectiveness of your surveys). Your description of the problem sounds more like resetting, than deleting. If that is the case, I would not reuse the admin survey_delete() code based on response ID. Instead, I'd write a new function (say survey_reset()) and expose it both in admin (keyed off of response ID) and in userland (as at least a link on the survey itself, possibly (though not recommended) with a link on the dashboard). ---------------------------------------------------------------------- Comment By: Franky Van Liedekerke (liedekef) Date: 2009-03-10 00:36 Message: How about just providing a link to the first page of the survey? You can do this at the bottom, top, anywhere within the current survey ... Franky ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=108956&aid=2676835&group_id=8956 |
|
From: SourceForge.net <no...@so...> - 2009-03-10 12:13:52
|
Bugs item #2676835, was opened at 2009-03-09 19:46 Message generated for change (Comment added) made by bishopb You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=108956&aid=2676835&group_id=8956 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: User Group: v2.0.2 Status: Open Resolution: None Priority: 5 Private: No Submitted By: kswartz (kswartz) Assigned to: Nobody/Anonymous (nobody) Summary: Need ability for user to delete incomplete survey Initial Comment: I've been making numerous enhancements to phpESP on my own (many of which I'm about to work on giving back), but I'm a bit stumped on how to move forward on this one, and would like some advice (in the absence of an actual fix). We have a lengthy survey that may be filled out multiple times by our users. The survey has about 100 questions, and may be done over a period of a few days, while the respondent does some research. We've found that occasionally, a user will want to scrap the survey completely, but still enter a new one. However, any time they sign in and try to start the survey, it always uses their saved one, and starts them where they left off. We want to introduce the option to DELETE a saved-but-incomplete survey from the dashboard page. I'm up for working on this code myself, but need some advice. Is there a good way to securely reuse the code that does this in the admin pages? Unlike the admin pages, a user doesn't have to be a superuser to delete his OWN survey. Right now, the workaround we have is to resume the saved survey, and hit the "Previous Page" button all the way back to page 1. Unfortunately, at 20 pages, that's a bit painful. I am visualizing an additional column on the dashboard page, called "Action". It can show a link to delete a saved survey, OR a link to view (or edit, depending on whether the survey would support it) any previously submitted copies of the survey. That's a separate enhancement request; I just wanted to mention how I saw this one fitting into a bigger picture. ---------------------------------------------------------------------- >Comment By: bishop (bishopb) Date: 2009-03-10 08:13 Message: I'm with Franky, at least in addressing a valid navigation use case ("user wants to review or change submitted responses, starting from the beginning"). I'd also like to define the semantic differences of "resetting" a survey's responses and "deleting" a survey. The former keeps the survey, but initializes responses to default values. The latter removes any indication that the user every began the survey. It's entirely possible that "resetting" is allowed (and desired), but "deleting" is not. I can also see cases where you'd want to record the number of resets (for statistical analysis on the effectiveness of your surveys). Your description of the problem sounds more like resetting, than deleting. If that is the case, I would not reuse the admin survey_delete() code based on response ID. Instead, I'd write a new function (say survey_reset()) and expose it both in admin (keyed off of response ID) and in userland (as at least a link on the survey itself, possibly (though not recommended) with a link on the dashboard). ---------------------------------------------------------------------- Comment By: Franky Van Liedekerke (liedekef) Date: 2009-03-10 03:36 Message: How about just providing a link to the first page of the survey? You can do this at the bottom, top, anywhere within the current survey ... Franky ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=108956&aid=2676835&group_id=8956 |
|
From: SourceForge.net <no...@so...> - 2009-03-10 07:36:38
|
Bugs item #2676835, was opened at 2009-03-10 00:46 Message generated for change (Comment added) made by liedekef You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=108956&aid=2676835&group_id=8956 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: User Group: v2.0.2 Status: Open Resolution: None Priority: 5 Private: No Submitted By: kswartz (kswartz) Assigned to: Nobody/Anonymous (nobody) Summary: Need ability for user to delete incomplete survey Initial Comment: I've been making numerous enhancements to phpESP on my own (many of which I'm about to work on giving back), but I'm a bit stumped on how to move forward on this one, and would like some advice (in the absence of an actual fix). We have a lengthy survey that may be filled out multiple times by our users. The survey has about 100 questions, and may be done over a period of a few days, while the respondent does some research. We've found that occasionally, a user will want to scrap the survey completely, but still enter a new one. However, any time they sign in and try to start the survey, it always uses their saved one, and starts them where they left off. We want to introduce the option to DELETE a saved-but-incomplete survey from the dashboard page. I'm up for working on this code myself, but need some advice. Is there a good way to securely reuse the code that does this in the admin pages? Unlike the admin pages, a user doesn't have to be a superuser to delete his OWN survey. Right now, the workaround we have is to resume the saved survey, and hit the "Previous Page" button all the way back to page 1. Unfortunately, at 20 pages, that's a bit painful. I am visualizing an additional column on the dashboard page, called "Action". It can show a link to delete a saved survey, OR a link to view (or edit, depending on whether the survey would support it) any previously submitted copies of the survey. That's a separate enhancement request; I just wanted to mention how I saw this one fitting into a bigger picture. ---------------------------------------------------------------------- >Comment By: Franky Van Liedekerke (liedekef) Date: 2009-03-10 08:36 Message: How about just providing a link to the first page of the survey? You can do this at the bottom, top, anywhere within the current survey ... Franky ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=108956&aid=2676835&group_id=8956 |
24 messages has been excluded from this view by a project administrator.
