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...> - 2010-03-15 03:28:49
|
Feature Requests item #2970468, was opened at 2010-03-15 03:28 Message generated for change (Tracker Item Submitted) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=358956&aid=2970468&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: gui Group: None Status: Open Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Timed Survey Initial Comment: Can we have a timed survey for our users. I need my user to fill survey in a specific time and they should be able to see the down timer on top of screen. It is somewhat like a test scenario, where respondent has to answer questions in a specific time. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=358956&aid=2970468&group_id=8956 |
|
From: SourceForge.net <no...@so...> - 2010-02-22 19:42:27
|
Bugs item #2956482, was opened at 2010-02-22 04:24 Message generated for change (Settings changed) made by bishopb You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=108956&aid=2956482&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: 2.1.3 Status: Open Resolution: None Priority: 5 Private: No Submitted By: mike () >Assigned to: bishop (bishopb) Summary: Dashboard displays incorrect "Last Access" date Initial Comment: Related: 2784037 If a survey has multiple responses, the "Last Access" column in the dashboard may display an incorrect date. The column is built from a $responses array which ultimately is generated in survey_get_responses function in espsurvey.inc. The root cause is this block of code from survey_get_from_sql: if (isset($surveys[$id])) { if ($needsConversion) { // we've collided, but not yet converted to an array: do so $surveys[$id] = array ($surveys[$id]); $needsConversion = false; } $surveys[$id][] = $row; } else { $surveys[$id] = $row; } $row is an array. When there is only one $row in the SQL result, $surveys[$id] is equal to that single $row. If a second $row is found, $surveys[$id] is turned into an array of arrays, with each $row being an entry in the "second dimension" of the array. It appears the line: $surveys[$id] = array ($surveys[$id]); is intended to convert the current value of $surveys[$id] into an entry in a new array of arrays. However, $surveys[$id] is expanded, and rather than adding a reference to an array, it simply adds all the name->value pairs currently in $surveys[$id] to a new array. $surveys[$id] looks like [survey_id] => 3 [username] => foobar [submitted] => 2010-02-12 03:25:29 [complete] => Y [ip] => 1.1.1.1 [0] => Array ( 2 [survey_id] => 3 [username] => foobar [submitted] => 2010-02-12 03:29:34 [complete] => Y [ip] => 1.1.1.1 ) instead of the intended [0] => Array([survey_id] => 3 [username] => foobar [submitted] => 2010-02-12 03:25:29 [complete] => Y [ip] => 1.1.1.1) [1] => Array ( 2 [survey_id] => 3 [username] => foobar [submitted] => 2010-02-12 03:29:34 [complete] => Y [ip] => 1.1.1.1 ) Back in dashboard.php, the $array['submitted'] is tested, it exists, and thus it is assumed that is the ONLY entry. Rather than iterating through the rest of the array, that first date is simply returned. That explanation feels terrible to me, hopefully it makes sense to anyone else encountering this issue. In my case, I solved it by creating a new function response_get_from_sql, identical in most ways except it starts by assuming there are multiple values to be inserted in the array, never mucking about with needsConversion and so forth in the first place. Inelegant perhaps, but I didn't want to screw around survey_get_from_sql. ---------------------------------------------------------------------- >Comment By: bishop (bishopb) Date: 2010-02-22 14:42 Message: Thanks for the report and detailed review! I did design the dashboard with the idea of only one response in mind, so I probably baked in this problem in other places as well. Your solution (assume multiple responses) seems like the appropriate track. I'll take this one on and make the appropriate changes. ---------------------------------------------------------------------- Comment By: mike () Date: 2010-02-22 04:28 Message: Oh, mentioned bug 2784037 as related because this also solves the "Some Finished, some Incomplete" bug that user reported. They misdiagnosed the exact cause but did identify the same area of code as the root. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=108956&aid=2956482&group_id=8956 |
|
From: SourceForge.net <no...@so...> - 2010-02-22 09:28:13
|
Bugs item #2956482, was opened at 2010-02-22 09:24 Message generated for change (Comment added) made by You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=108956&aid=2956482&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: 2.1.3 Status: Open Resolution: None Priority: 5 Private: No Submitted By: mike () Assigned to: Nobody/Anonymous (nobody) Summary: Dashboard displays incorrect "Last Access" date Initial Comment: Related: 2784037 If a survey has multiple responses, the "Last Access" column in the dashboard may display an incorrect date. The column is built from a $responses array which ultimately is generated in survey_get_responses function in espsurvey.inc. The root cause is this block of code from survey_get_from_sql: if (isset($surveys[$id])) { if ($needsConversion) { // we've collided, but not yet converted to an array: do so $surveys[$id] = array ($surveys[$id]); $needsConversion = false; } $surveys[$id][] = $row; } else { $surveys[$id] = $row; } $row is an array. When there is only one $row in the SQL result, $surveys[$id] is equal to that single $row. If a second $row is found, $surveys[$id] is turned into an array of arrays, with each $row being an entry in the "second dimension" of the array. It appears the line: $surveys[$id] = array ($surveys[$id]); is intended to convert the current value of $surveys[$id] into an entry in a new array of arrays. However, $surveys[$id] is expanded, and rather than adding a reference to an array, it simply adds all the name->value pairs currently in $surveys[$id] to a new array. $surveys[$id] looks like [survey_id] => 3 [username] => foobar [submitted] => 2010-02-12 03:25:29 [complete] => Y [ip] => 1.1.1.1 [0] => Array ( 2 [survey_id] => 3 [username] => foobar [submitted] => 2010-02-12 03:29:34 [complete] => Y [ip] => 1.1.1.1 ) instead of the intended [0] => Array([survey_id] => 3 [username] => foobar [submitted] => 2010-02-12 03:25:29 [complete] => Y [ip] => 1.1.1.1) [1] => Array ( 2 [survey_id] => 3 [username] => foobar [submitted] => 2010-02-12 03:29:34 [complete] => Y [ip] => 1.1.1.1 ) Back in dashboard.php, the $array['submitted'] is tested, it exists, and thus it is assumed that is the ONLY entry. Rather than iterating through the rest of the array, that first date is simply returned. That explanation feels terrible to me, hopefully it makes sense to anyone else encountering this issue. In my case, I solved it by creating a new function response_get_from_sql, identical in most ways except it starts by assuming there are multiple values to be inserted in the array, never mucking about with needsConversion and so forth in the first place. Inelegant perhaps, but I didn't want to screw around survey_get_from_sql. ---------------------------------------------------------------------- >Comment By: mike () Date: 2010-02-22 09:28 Message: Oh, mentioned bug 2784037 as related because this also solves the "Some Finished, some Incomplete" bug that user reported. They misdiagnosed the exact cause but did identify the same area of code as the root. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=108956&aid=2956482&group_id=8956 |
|
From: SourceForge.net <no...@so...> - 2010-02-22 09:24:11
|
Bugs item #2956482, was opened at 2010-02-22 09:24 Message generated for change (Tracker Item Submitted) made by You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=108956&aid=2956482&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: 2.1.3 Status: Open Resolution: None Priority: 5 Private: No Submitted By: mike () Assigned to: Nobody/Anonymous (nobody) Summary: Dashboard displays incorrect "Last Access" date Initial Comment: Related: 2784037 If a survey has multiple responses, the "Last Access" column in the dashboard may display an incorrect date. The column is built from a $responses array which ultimately is generated in survey_get_responses function in espsurvey.inc. The root cause is this block of code from survey_get_from_sql: if (isset($surveys[$id])) { if ($needsConversion) { // we've collided, but not yet converted to an array: do so $surveys[$id] = array ($surveys[$id]); $needsConversion = false; } $surveys[$id][] = $row; } else { $surveys[$id] = $row; } $row is an array. When there is only one $row in the SQL result, $surveys[$id] is equal to that single $row. If a second $row is found, $surveys[$id] is turned into an array of arrays, with each $row being an entry in the "second dimension" of the array. It appears the line: $surveys[$id] = array ($surveys[$id]); is intended to convert the current value of $surveys[$id] into an entry in a new array of arrays. However, $surveys[$id] is expanded, and rather than adding a reference to an array, it simply adds all the name->value pairs currently in $surveys[$id] to a new array. $surveys[$id] looks like [survey_id] => 3 [username] => foobar [submitted] => 2010-02-12 03:25:29 [complete] => Y [ip] => 1.1.1.1 [0] => Array ( 2 [survey_id] => 3 [username] => foobar [submitted] => 2010-02-12 03:29:34 [complete] => Y [ip] => 1.1.1.1 ) instead of the intended [0] => Array([survey_id] => 3 [username] => foobar [submitted] => 2010-02-12 03:25:29 [complete] => Y [ip] => 1.1.1.1) [1] => Array ( 2 [survey_id] => 3 [username] => foobar [submitted] => 2010-02-12 03:29:34 [complete] => Y [ip] => 1.1.1.1 ) Back in dashboard.php, the $array['submitted'] is tested, it exists, and thus it is assumed that is the ONLY entry. Rather than iterating through the rest of the array, that first date is simply returned. That explanation feels terrible to me, hopefully it makes sense to anyone else encountering this issue. In my case, I solved it by creating a new function response_get_from_sql, identical in most ways except it starts by assuming there are multiple values to be inserted in the array, never mucking about with needsConversion and so forth in the first place. Inelegant perhaps, but I didn't want to screw around survey_get_from_sql. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=108956&aid=2956482&group_id=8956 |
|
From: SourceForge.net <no...@so...> - 2010-02-15 09:08:33
|
Bugs item #2951148, was opened at 2010-02-13 09:26 Message generated for change (Comment added) made by You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=108956&aid=2951148&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.3 Status: Open Resolution: None Priority: 5 Private: No Submitted By: mike () Assigned to: Franky Van Liedekerke (liedekef) Summary: esp_setlocale quietly fails to set up locale Initial Comment: System: Linux (Ubuntu, Hardy), PHP5, Apache2, gettext compiled in When the en_US.UTF-8 locale is not available on the host, setlocale() will quietly fail to change the locale. esp_setlocale($lang) will also quietly fail. (I presume this is true if ANY locale you attempt to use is not available on the host, when using the gettext native extension). One noticeable symptom is that test.php reports gettext is available and real but "%%%% Gettext Test Failed" is still displayed. I see messages on the mailing list about this issue. For the most part this is a minor issue; the failure will mostly be unnoticed as the failover language is English. However, poor suckers like me who try to modify the en_US localization file will be very confused. The output of test.php may also be confusing. The root cause of the problem can be resolved by installing the en_US.UTF-8 locale. In ubuntu, sudo locale-gen en_US.UTF-8 Note that "locale -a" will list existing locales. On the php_ESP side, when the locale is not set correctly, this should be detected and reported. For example, adding this code at the appropriate place in test.php will retrieve the current locale setting and ensure it was accurately set to language.charset. <li>LC_ALL: <?php check_string(setlocale(LC_ALL, 0), $ESPCONFIG['lang'].".".$ESPCONFIG['charset']); ?></li> Additional checks in esp_setlocale() may be called for; PHP docs say the return value of setlocale() when a locale is actually set varies from system to system, but also says it should return the locale if set properly. ---------------------------------------------------------------------- Comment By: mike () Date: 2010-02-15 09:08 Message: Certainly the user bears some responsibility, yet as always the hard working developer is stuck trying to make things more fool-proof. :) Note, however, that as far as I could tell I chose a locale that was available. The test.php page reports the locale as en_US, and I chose en_US, which IS installed on my server. I now know that the charset is set in phpESP.ini.php.default as UTF-8 but didn't realize this at the time (also my fault...). (Why no UTF-8? No idea. On my install of Ubuntu-server from Slicehost, the default charset was ISO-8859-15... certainly I bear responsibility for not noticing and someone should say something nasty to Slicehost.) In addition to adding a test to test.php, my only other thought was to set the default locale/charset to the current system default (via setlocale(LC_ALL, 0)) instead of using en_US.UTF-8 as the default (unless there is a problem getting the current locale or it is incompatible). This might be overkill and open a new world of problems. Certainly my problem is solved now, and hopefully future google searches will show the solution here. :) (For some reason, it didn't turn up the email list archives). ---------------------------------------------------------------------- Comment By: Franky Van Liedekerke (liedekef) Date: 2010-02-15 08:37 Message: Indeed many people on this list had this problem and always when I asked them "is the locale installed on your server" the person stopped responding. It is your own problem for selecting a locale not available, but indeed it should be made more fool-proof. I'll take a look at this! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=108956&aid=2951148&group_id=8956 |
|
From: SourceForge.net <no...@so...> - 2010-02-15 08:37:57
|
Bugs item #2951148, was opened at 2010-02-13 10:26 Message generated for change (Comment added) made by liedekef You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=108956&aid=2951148&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.3 Status: Open Resolution: None Priority: 5 Private: No Submitted By: https://www.google.com/accounts () >Assigned to: Franky Van Liedekerke (liedekef) Summary: esp_setlocale quietly fails to set up locale Initial Comment: System: Linux (Ubuntu, Hardy), PHP5, Apache2, gettext compiled in When the en_US.UTF-8 locale is not available on the host, setlocale() will quietly fail to change the locale. esp_setlocale($lang) will also quietly fail. (I presume this is true if ANY locale you attempt to use is not available on the host, when using the gettext native extension). One noticeable symptom is that test.php reports gettext is available and real but "%%%% Gettext Test Failed" is still displayed. I see messages on the mailing list about this issue. For the most part this is a minor issue; the failure will mostly be unnoticed as the failover language is English. However, poor suckers like me who try to modify the en_US localization file will be very confused. The output of test.php may also be confusing. The root cause of the problem can be resolved by installing the en_US.UTF-8 locale. In ubuntu, sudo locale-gen en_US.UTF-8 Note that "locale -a" will list existing locales. On the php_ESP side, when the locale is not set correctly, this should be detected and reported. For example, adding this code at the appropriate place in test.php will retrieve the current locale setting and ensure it was accurately set to language.charset. <li>LC_ALL: <?php check_string(setlocale(LC_ALL, 0), $ESPCONFIG['lang'].".".$ESPCONFIG['charset']); ?></li> Additional checks in esp_setlocale() may be called for; PHP docs say the return value of setlocale() when a locale is actually set varies from system to system, but also says it should return the locale if set properly. ---------------------------------------------------------------------- >Comment By: Franky Van Liedekerke (liedekef) Date: 2010-02-15 09:37 Message: Indeed many people on this list had this problem and always when I asked them "is the locale installed on your server" the person stopped responding. It is your own problem for selecting a locale not available, but indeed it should be made more fool-proof. I'll take a look at this! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=108956&aid=2951148&group_id=8956 |
|
From: SourceForge.net <no...@so...> - 2010-02-13 09:26:52
|
Bugs item #2951148, was opened at 2010-02-13 09:26 Message generated for change (Tracker Item Submitted) made by You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=108956&aid=2951148&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.3 Status: Open Resolution: None Priority: 5 Private: No Submitted By: https://www.google.com/accounts () Assigned to: Nobody/Anonymous (nobody) Summary: esp_setlocale quietly fails to set up locale Initial Comment: System: Linux (Ubuntu, Hardy), PHP5, Apache2, gettext compiled in When the en_US.UTF-8 locale is not available on the host, setlocale() will quietly fail to change the locale. esp_setlocale($lang) will also quietly fail. (I presume this is true if ANY locale you attempt to use is not available on the host, when using the gettext native extension). One noticeable symptom is that test.php reports gettext is available and real but "%%%% Gettext Test Failed" is still displayed. I see messages on the mailing list about this issue. For the most part this is a minor issue; the failure will mostly be unnoticed as the failover language is English. However, poor suckers like me who try to modify the en_US localization file will be very confused. The output of test.php may also be confusing. The root cause of the problem can be resolved by installing the en_US.UTF-8 locale. In ubuntu, sudo locale-gen en_US.UTF-8 Note that "locale -a" will list existing locales. On the php_ESP side, when the locale is not set correctly, this should be detected and reported. For example, adding this code at the appropriate place in test.php will retrieve the current locale setting and ensure it was accurately set to language.charset. <li>LC_ALL: <?php check_string(setlocale(LC_ALL, 0), $ESPCONFIG['lang'].".".$ESPCONFIG['charset']); ?></li> Additional checks in esp_setlocale() may be called for; PHP docs say the return value of setlocale() when a locale is actually set varies from system to system, but also says it should return the locale if set properly. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=108956&aid=2951148&group_id=8956 |
|
From: SourceForge.net <no...@so...> - 2010-01-25 09:36:58
|
Feature Requests 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=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: Closed Priority: 5 Private: No Submitted By: kswartz (kswartz) Assigned to: Franky Van Liedekerke (liedekef) 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: 2010-01-25 10:36 Message: I'm closing this, since it's now possible to set the section in the GET-request so you can point authenticated users to page 1 again directly (or let them continue where they left off) ---------------------------------------------------------------------- Comment By: Franky Van Liedekerke (liedekef) Date: 2009-07-27 20:38 Message: I've committed a small change to handler.php to fix this (it removes sec=x from the url if present) Franky ---------------------------------------------------------------------- Comment By: Franky Van Liedekerke (liedekef) Date: 2009-07-27 19:19 Message: Well, maybe in 2.1.1 it is a reset, but in later versions the old answers are still there :-) You really should update, because you're now mixing code from 2.1.1, 2.1.4 and your own ... and the behaviour you expect will change when you update. But about the save part: you're right about the link. I saw that, but was too lazy ;-) I'll fix it now. Franky ---------------------------------------------------------------------- Comment By: bishop (bishopb) Date: 2009-07-27 19:10 Message: Along these lines, I'll mention that I'm working on (very slowly) a patch to dashboard that would effect an actual response delete, not a response reset as I think we're working on here (note my definition way down below in comment #2). I don't know if that should go in this ticket or not. ---------------------------------------------------------------------- Comment By: kswartz (kswartz) Date: 2009-07-27 19:01 Message: Hi Franky, Okay, looking much better. I saved a survey on page 3, then quit my browser, restarted, logged in, and typed in the URL for the survey with "sec=1" added to the URL. This worked fine. None of the answers were pre-filled in, which is in line with the feature request here. I was able to continue through past the point where I saved it without any issue (I had a problem with that the first time I tried it, but I'll chalk that up to interim code changes, as I couldn't reproduce it). It also worked if I entered the URL directly, without going through the dashboard. The only remaining problem I noticed is that you're not taking the "sec=##" out of the URL for the <form> action attribute. This causes the link to resume the survey when you save it to be wrong, and it has sec=##, but not name=xxx. ---------------------------------------------------------------------- Comment By: Franky Van Liedekerke (liedekef) Date: 2009-07-25 12:30 Message: It should be fixed in SVN now, but remember: it only works when you define "sec=x" on the URL and only at the beginning of the session. So for a resume to work with this parameter, you need to close your browser (all browser windows) first and then reopen the browser (so a new session is started and you need to log in again). I've also cleaned up some other mess concerning userid, this parameter was junk anyway. Franky ---------------------------------------------------------------------- Comment By: Franky Van Liedekerke (liedekef) Date: 2009-07-25 10:37 Message: Ah, sorry about the closing paren prob, didn't got around to testing it. I'll test it out today, shouldn't be that difficult to fix :-) Franky ---------------------------------------------------------------------- Comment By: kswartz (kswartz) Date: 2009-07-25 01:28 Message: Hmm. Picked up the new handler-prefix.php, and it hasn't changed the behavior for me; it's stlil not picking up sec from the request param. I remember thinking before this /might/ have to do with some php-level configuration, but I think that was where I started to run out of time. (I should have taken better notes on this particular issue.) Also, you're missing a closing paren on line 123. ---------------------------------------------------------------------- Comment By: Franky Van Liedekerke (liedekef) Date: 2009-07-25 00:42 Message: Go to http://phpesp.svn.sourceforge.net/viewvc/phpesp?view=rev revision 1122 (the latest one) show the changed files. In fact, only the handler-prefix.php change is needed I believe ... Franky ---------------------------------------------------------------------- Comment By: kswartz (kswartz) Date: 2009-07-25 00:37 Message: Cool! Thanks, Franky. If you want, I can test it on top of my install (which is still at 2.1.2, because I haven't had time to copy over all my customizations yet). Let me know which files have changed, and I can pull them down and give it a try. ---------------------------------------------------------------------- Comment By: Franky Van Liedekerke (liedekef) Date: 2009-07-24 23:12 Message: Well, I can guess why: for authenticated surveys, the section-variable (sec) always gets set to the latest section filled-in upon resume. Now I've added the code to allow to set the section in the get-request as well (and cleaned up the code a bit) Franky ---------------------------------------------------------------------- Comment By: kswartz (kswartz) Date: 2009-07-24 20:49 Message: Hi, Well, that solved the problem with the userid variable getting munged, but it still doesn't go to page 1. I think the issue here is that the REQUEST variable is not overriding the SESSION variable, but, unfortunately, I've been off this project for the past couple of months, so I haven't had much time to look into it deeper. ---------------------------------------------------------------------- Comment By: Franky Van Liedekerke (liedekef) Date: 2009-07-24 11:33 Message: Well, it seems this is old code that still got stuck in. Probably removing the 2 wrongif-statement will not change anything here. So I would remove if (!empty($_REQUEST['userid'])) and also elseif(!empty($_SERVER['QUERY_STRING'])) { Could that fix it for you then? Franky ---------------------------------------------------------------------- Comment By: bishop (bishopb) Date: 2009-04-30 17:15 Message: kswartz> I'm kind of scratching my head here: under what conditions would that test kswartz> actually be valid? I'm not at all familiar with the whys in handler, but just guessing, maybe when the survey is in test mode? But, regardless, that whole conditional is voodoo. It starts out with "if empty request userid" then within it says "if not empty request userid"? Total black magic. ---------------------------------------------------------------------- Comment By: kswartz (kswartz) Date: 2009-04-30 06:43 Message: Okay, figured out why putting "&sec=1" in the query string doesn't work. It's because of this section in handler-prefix.php: if(empty($_REQUEST['userid'])) { // find remote user id (takes the first non-empty of the following) // 1. a GET variable named 'userid' // 2. the REMOTE_USER set by HTTP-Authentication // 3. the query string // 4. the remote ip address if (!empty($_REQUEST['userid'])) { $_REQUEST['userid'] = $_REQUEST['userid']; } elseif(!empty($_SERVER['REMOTE_USER'])) { $_REQUEST['userid'] = $_SERVER['REMOTE_USER']; ---> } elseif(!empty($_SERVER['QUERY_STRING'])) { $_REQUEST['userid'] = urldecode($_SERVER['QUERY_STRING']); } else { $_REQUEST['userid'] = $_SERVER['REMOTE_ADDR']; } } The line with "--->" in front is the condition that's triggering inappropriately. When the first two tests fail, the query_string "sec=1" is matched here, and it sets userid to that. I'm kind of scratching my head here: under what conditions would that test actually be valid? I'm finding that even if I modify that line as follows, though: } elseif(!empty($_SERVER['QUERY_STRING']) && (strpos($_SERVER['QUERY_STRING'],'=')===FALSE)) { it doesn't mess with the userid variable, but it still doesn't modify the value of sid. ---------------------------------------------------------------------- Comment By: kswartz (kswartz) Date: 2009-03-10 22: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 19: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 18: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 18: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 13: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 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=358956&aid=2676835&group_id=8956 |
|
From: SourceForge.net <no...@so...> - 2010-01-25 09:34:28
|
Feature Requests item #2933959, was opened at 2010-01-17 21:32 Message generated for change (Settings changed) made by liedekef You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=358956&aid=2933959&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 Priority: 5 Private: No Submitted By: Gurdeep Singh (gurdeep22) >Assigned to: Franky Van Liedekerke (liedekef) Summary: duplicate survey name Initial Comment: multiple surveys cannot be created with a single name. > Now if multiple users access the tool then it is hard to create a new survey everytime with a unique name. It is an important usability aspect and it require solution. Possible solution: If survey ID is appended to the newly created survey name automatically than it will give you a unique survey name itself. or username can also be appended to keep the survey name unique. ---------------------------------------------------------------------- Comment By: Franky Van Liedekerke (liedekef) Date: 2010-01-25 10:34 Message: This feature has been added to the SVN tree. It will be available in the next release of phpESP. For instructions on obtaining sources from SVN please see: http://sourceforge.net/cvs/?group_id=8956 ---------------------------------------------------------------------- Comment By: bishop (bishopb) Date: 2010-01-22 17:24 Message: I visually reviewed the SVN patchset, and it looked good to me. However, I was reluctant to put my imprimatur since Gurdeep reported an issue. Assuming that was just a case of not fully patching, then Franky I trust your unit testing (:)) and suggest closing this one out. ---------------------------------------------------------------------- Comment By: Franky Van Liedekerke (liedekef) Date: 2010-01-22 13:53 Message: I've gotten no response any more after my latest commits, does this mean everybody is happy and I can close the ticket? ---------------------------------------------------------------------- Comment By: Franky Van Liedekerke (liedekef) Date: 2010-01-20 10:22 Message: More files have changed than just those 2, see http://phpesp.svn.sourceforge.net/viewvc/phpesp?view=rev&revision=1143 ---------------------------------------------------------------------- Comment By: Gurdeep Singh (gurdeep22) Date: 2010-01-20 00:56 Message: Heh, Updating the survey.php and finish.inc file is now creating a survey by ID reference. But still you cannot create a survey with duplicate entry. ---------------------------------------------------------------------- Comment By: Franky Van Liedekerke (liedekef) Date: 2010-01-19 23:37 Message: Heh, it seems that changing the xml for this (thus the database structure) and an extra "ORDER BY id ASC" in public/survey.php solves it already. Now just some change in admin/include/tab/finish.inc so the by-name reference disappears from the info, version change in admin/phpESP.ini.php.fixed (othierwise the xml changes don't get picked up ok) and done. Check out svn for the changes and come back to me with comments please. ---------------------------------------------------------------------- Comment By: Franky Van Liedekerke (liedekef) Date: 2010-01-19 23:09 Message: Well, just making the duplicate check user bound (username+survey name as unique DB key) won't cut it for people doing/using the by-name reference now ... this is the easy part btw (just a change in an xml file) I agree that using the first survey found if multiple matches is quirky, but it handles every current situation. Proposal (since it is a svn thingie anyway): I'll cook up a small patch doing what I suggested, resulting in minimal changes for everybody for now and lets test it out :-) ---------------------------------------------------------------------- Comment By: bishop (bishopb) Date: 2010-01-19 20:45 Message: > The thing is, I don't want to stop using the by-name reference just yet. > Suppose you've mailed a survey with a by-name reference to 10.000 persons > and they have 6 months or so to fill it in? These things happen in > governmental organisations (believe me, I know). Sure do, and we want to keep support for them. My proposal maintains backward compatibilty for by-name surveys, while moving the entire system to by-ID, without resulting in cases that are, IMO :), quirky: namely, using the first survey found if multiple matches. I think we can all agree, however, that we should make the duplicate check user bound (ie, a natural key of <user name, survey name>). I'd say we do that now, and I think that might meet Gurdeep's need, and assuming so, we can close this ticket and move the by-name action to its own ticket. ---------------------------------------------------------------------- Comment By: Franky Van Liedekerke (liedekef) Date: 2010-01-19 19:59 Message: The thing is, I don't want to stop using the by-name reference just yet. Suppose you've mailed a survey with a by-name reference to 10.000 persons and they have 6 months or so to fill it in? These things happen in governmental organisations (believe me, I know). For know I believe the first steps to be: - remove the duplicate check (and change the db to use a survey name-user combo as unique db constraint) - for "?name=" syntax use the first survey found (if multiple surveys match the same name) - remove as much of by-name references as possible in the admin backend code (eg. when doing "test" surveys) and replacing by "?id=" In a next step we can further build down by-name reference, by no longer allowing it at all. Seems reasonable easy to code up for now... Franky ---------------------------------------------------------------------- Comment By: bishop (bishopb) Date: 2010-01-19 17:02 Message: Also, if a survey is requested by name, we lookup the ID then throw a 301 - Moved Permanently header to ensure that we do all that we can to stop using the by-name reference. ---------------------------------------------------------------------- Comment By: bishop (bishopb) Date: 2010-01-19 17:00 Message: Suppose name uniqueness is dropped in version X. When upgrading to version X, we know that all surveys with an ID less than or equal to MAX(Survey.ID) := N will have a unique name (as they were created in version < X) and we can record N for reference. Then, when we're resolving a name to an ID, we do eg "SELECT ID FROM Surveys WHERE name=? AND ID < N". In other words, we only look for a survey by name for those surveys created in earlier versions, and we don't care about name uniqueness when given an ID. In effect, we're automating the configuration option you suggest and making it transparent to the end user. If we remove name uniqueness, what is that going to do to the user experience? It'll be possible to create two surveys with the same name, so then how do they tell which is which at a glance? Perhaps what we really want is: a) Change all references to a survey by ID, per the logic presented above b) Enforce a natural key of <survey name, creating user> That way, the software references by ID and can always find a unique survey, and a person cannot ever create a survey with the same title and potentially get confused as to which is which. Thoughts? ---------------------------------------------------------------------- Comment By: Franky Van Liedekerke (liedekef) Date: 2010-01-19 15:11 Message: Bishop, the issue with just removing the duplicate check would result in problems for people having created current surveys that they mailed out using "?name=" syntax, and where newly created surveys get the same name. So maybe my suggestion is the best of all: making the duplicate check optional by using a configuration option. Or even better: just removing the duplicate check, and for "?name=" syntax use the first survey found (if multiple surveys match the same name), but also removing as much of "?name=" references as possible in the admin backend code (eg. when doing "test" surveys) and replacing by "?id=" I don't like suggesting names (too much coding for very little result), and using an ID for a survey that is not yet created is difficult :-) ---------------------------------------------------------------------- Comment By: bishop (bishopb) Date: 2010-01-19 14:06 Message: Another option: always suggest a survey name, allowing the user to override if desired. If the override collides, suggest a new one. For example, when creating a new survey, the survey name field displays pre-filled with "SURVEY_1234" (where 1234 is the next ID) or "SURVEY_bob_19-1-2010" (where bob is the username and 19-1-2010 is today's date in the locale DMY format). If the user clicks on the survey name field, the pre-filled is erased. But, Franky, so long as we're talking about getting rid of name uniqueness, why not just do it? Existing deployments will not be affected, as the name is already unique. New deployments will simply start using ID. We always check to see if survey name is given on the URL, and we try to resolve that to an ID, and if it fails owing to duplicate, we throw an error indicating as such. ---------------------------------------------------------------------- Comment By: Franky Van Liedekerke (liedekef) Date: 2010-01-19 10:14 Message: Ok, another way of doing it: take away the uniquess on the database column for survey names and work with an option that lets you define wether or not the name must be unique. If the option is "name must be unique" then we give an error if the name is already in use and you need to choose another one (no autocreation of another name for now). If the option is "name must not be unique" then we don't check if the name is already in use, but you might lose the possibility to refer to surveys by name (not that much of a limitation) if more than one survey with the same name exists. Franky ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2010-01-19 09:29 Message: But if you as a user have to think about a unique name every time you create a survey is bit irritating. It directly impacts the usability of application. For an example my application is for academic insitiutions in which instructors creates surveys and time sheets and send them to students participating in team projects. Most of the instructors will try to keep the identical name for their surveys like "timesheet week 1 " or so and as the number of surveys increases finding a unique name may become a trouble for them. Automatically suggesting a name for a survey if that name already exists is a good idea instead of prepending an ID to all survey names. ---------------------------------------------------------------------- Comment By: bishop (bishopb) Date: 2010-01-18 15:06 Message: > the thing is that people can access a survey by doing "?name=SURVEYNAME" > in the URL, therefore the survey name needs to be unique. It was like this > before I took over the project, so I didn't want to break that > functionality. So for now the name needs to be always unique. Agreed -- this should not be touched now. But I meant to suggest when we're designing version 3 we should consider whether we need to keep access by name (natural key) or if access by ID (surrogate key) is just as good. My inclination, without having done any diligence in reviewing the code, is that surrogate key is fine. > But it shouldn't impact existing surveys in any way, only surveys that you can edit are impacted, and these are > never online. Could you give an example of such a use case? Sure, suppose I'm a designer, logged into the admin side. I'm creating a survey for my first period class and I want to give it a name like 'APPSTATP1' so that it looks something like the subject matter. With the new code, I can't have a name like that, because it'll prepend the ID onto the front, so I can never name a survey something entirely appropriate to the subject domain. But suppose that was fixed so that only duplicate survey names get modified. Further suppose I had a survey from last year with my desired name. (Being a survey that recurs on the same subject matter makes this a likely case.) There's a collision, and the patch gives it an automatic name, like '1321APPSTATP1'. Suddenly, that name is no longer obvious and difficult to remember. In this case, I (as the designer) would prefer to be told that the survey name isn't unique and that I need to make it unique, which which case I'd give it a name containing a time signature, like 'APPSTATP1_2010'. Instead of actually saving with a new name, can't we throw an error as now, but recommend a new name, perhaps automatically filling in the survey name field with the recommended name? That way, the user can quickly get a survey with a unique name if he doesn't care about the name particularly, or he can take corrective action to make a relevant unique name. ---------------------------------------------------------------------- Comment By: Franky Van Liedekerke (liedekef) Date: 2010-01-18 10:18 Message: Hi Bishop, the thing is that people can access a survey by doing "?name=SURVEYNAME" in the URL, therefore the survey name needs to be unique. It was like this before I took over the project, so I didn't want to break that functionality. So for now the name needs to be always unique. But it shouldn't impact existing surveys in any way, only surveys that you can edit are impacted, and these are never online. Could you give an example of such a use case? ---------------------------------------------------------------------- Comment By: bishop (bishopb) Date: 2010-01-18 01:14 Message: Automatically adding a number, in all cases, will probably break some existing use cases. Perhaps: 1. Make this a configuration option: "Do you want to generate a unique survey name if creating a new one with an existing name?" Boolean. Default = No. 2. If so configured, atomically test for existence and, if already exists, append the survey ID as in the patch. If not so configured, fail. This would keep existing behavior while allowing the new functionality. Of course, survey ID is already unique, so having the survey name act as a natural key is redundant. Moving into the next major version, we might want to consider whether we need both the surrogate ID and the natural name keys. ---------------------------------------------------------------------- Comment By: Gurdeep Singh (gurdeep22) Date: 2010-01-17 22:57 Message: Yeah its working. i just checked it , it prepends the survey id to the survey name and thus generating unique name every time. But survey Id get prepends to every survey name and not only to those that have duplicate name . this is a good solution for me. I can move ahead now. Thank You very much. Gurdeep ---------------------------------------------------------------------- Comment By: Franky Van Liedekerke (liedekef) Date: 2010-01-17 22:31 Message: Ok, I made some changed to admin/include/function/survey_update.inc that prepends the survey ID if not present, and readding it every time it gets removed, so the chance of getting a double name is next to zero now. Try out the updated version (see attachment in this feature request) and see if it solves the problem for you. If it does, I'll include it in the code with an extra line explaining where the ID comes from. Unless some other people don't agree with this? I didn't want to do it based on the username or userID because that would disclose user information to the outside world, not a wanted effect. Franky ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=358956&aid=2933959&group_id=8956 |
|
From: SourceForge.net <no...@so...> - 2010-01-22 16:24:41
|
Feature Requests item #2933959, was opened at 2010-01-17 15:32 Message generated for change (Comment added) made by bishopb You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=358956&aid=2933959&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: Gurdeep Singh (gurdeep22) Assigned to: Nobody/Anonymous (nobody) Summary: duplicate survey name Initial Comment: multiple surveys cannot be created with a single name. > Now if multiple users access the tool then it is hard to create a new survey everytime with a unique name. It is an important usability aspect and it require solution. Possible solution: If survey ID is appended to the newly created survey name automatically than it will give you a unique survey name itself. or username can also be appended to keep the survey name unique. ---------------------------------------------------------------------- >Comment By: bishop (bishopb) Date: 2010-01-22 11:24 Message: I visually reviewed the SVN patchset, and it looked good to me. However, I was reluctant to put my imprimatur since Gurdeep reported an issue. Assuming that was just a case of not fully patching, then Franky I trust your unit testing (:)) and suggest closing this one out. ---------------------------------------------------------------------- Comment By: Franky Van Liedekerke (liedekef) Date: 2010-01-22 07:53 Message: I've gotten no response any more after my latest commits, does this mean everybody is happy and I can close the ticket? ---------------------------------------------------------------------- Comment By: Franky Van Liedekerke (liedekef) Date: 2010-01-20 04:22 Message: More files have changed than just those 2, see http://phpesp.svn.sourceforge.net/viewvc/phpesp?view=rev&revision=1143 ---------------------------------------------------------------------- Comment By: Gurdeep Singh (gurdeep22) Date: 2010-01-19 18:56 Message: Heh, Updating the survey.php and finish.inc file is now creating a survey by ID reference. But still you cannot create a survey with duplicate entry. ---------------------------------------------------------------------- Comment By: Franky Van Liedekerke (liedekef) Date: 2010-01-19 17:37 Message: Heh, it seems that changing the xml for this (thus the database structure) and an extra "ORDER BY id ASC" in public/survey.php solves it already. Now just some change in admin/include/tab/finish.inc so the by-name reference disappears from the info, version change in admin/phpESP.ini.php.fixed (othierwise the xml changes don't get picked up ok) and done. Check out svn for the changes and come back to me with comments please. ---------------------------------------------------------------------- Comment By: Franky Van Liedekerke (liedekef) Date: 2010-01-19 17:09 Message: Well, just making the duplicate check user bound (username+survey name as unique DB key) won't cut it for people doing/using the by-name reference now ... this is the easy part btw (just a change in an xml file) I agree that using the first survey found if multiple matches is quirky, but it handles every current situation. Proposal (since it is a svn thingie anyway): I'll cook up a small patch doing what I suggested, resulting in minimal changes for everybody for now and lets test it out :-) ---------------------------------------------------------------------- Comment By: bishop (bishopb) Date: 2010-01-19 14:45 Message: > The thing is, I don't want to stop using the by-name reference just yet. > Suppose you've mailed a survey with a by-name reference to 10.000 persons > and they have 6 months or so to fill it in? These things happen in > governmental organisations (believe me, I know). Sure do, and we want to keep support for them. My proposal maintains backward compatibilty for by-name surveys, while moving the entire system to by-ID, without resulting in cases that are, IMO :), quirky: namely, using the first survey found if multiple matches. I think we can all agree, however, that we should make the duplicate check user bound (ie, a natural key of <user name, survey name>). I'd say we do that now, and I think that might meet Gurdeep's need, and assuming so, we can close this ticket and move the by-name action to its own ticket. ---------------------------------------------------------------------- Comment By: Franky Van Liedekerke (liedekef) Date: 2010-01-19 13:59 Message: The thing is, I don't want to stop using the by-name reference just yet. Suppose you've mailed a survey with a by-name reference to 10.000 persons and they have 6 months or so to fill it in? These things happen in governmental organisations (believe me, I know). For know I believe the first steps to be: - remove the duplicate check (and change the db to use a survey name-user combo as unique db constraint) - for "?name=" syntax use the first survey found (if multiple surveys match the same name) - remove as much of by-name references as possible in the admin backend code (eg. when doing "test" surveys) and replacing by "?id=" In a next step we can further build down by-name reference, by no longer allowing it at all. Seems reasonable easy to code up for now... Franky ---------------------------------------------------------------------- Comment By: bishop (bishopb) Date: 2010-01-19 11:02 Message: Also, if a survey is requested by name, we lookup the ID then throw a 301 - Moved Permanently header to ensure that we do all that we can to stop using the by-name reference. ---------------------------------------------------------------------- Comment By: bishop (bishopb) Date: 2010-01-19 11:00 Message: Suppose name uniqueness is dropped in version X. When upgrading to version X, we know that all surveys with an ID less than or equal to MAX(Survey.ID) := N will have a unique name (as they were created in version < X) and we can record N for reference. Then, when we're resolving a name to an ID, we do eg "SELECT ID FROM Surveys WHERE name=? AND ID < N". In other words, we only look for a survey by name for those surveys created in earlier versions, and we don't care about name uniqueness when given an ID. In effect, we're automating the configuration option you suggest and making it transparent to the end user. If we remove name uniqueness, what is that going to do to the user experience? It'll be possible to create two surveys with the same name, so then how do they tell which is which at a glance? Perhaps what we really want is: a) Change all references to a survey by ID, per the logic presented above b) Enforce a natural key of <survey name, creating user> That way, the software references by ID and can always find a unique survey, and a person cannot ever create a survey with the same title and potentially get confused as to which is which. Thoughts? ---------------------------------------------------------------------- Comment By: Franky Van Liedekerke (liedekef) Date: 2010-01-19 09:11 Message: Bishop, the issue with just removing the duplicate check would result in problems for people having created current surveys that they mailed out using "?name=" syntax, and where newly created surveys get the same name. So maybe my suggestion is the best of all: making the duplicate check optional by using a configuration option. Or even better: just removing the duplicate check, and for "?name=" syntax use the first survey found (if multiple surveys match the same name), but also removing as much of "?name=" references as possible in the admin backend code (eg. when doing "test" surveys) and replacing by "?id=" I don't like suggesting names (too much coding for very little result), and using an ID for a survey that is not yet created is difficult :-) ---------------------------------------------------------------------- Comment By: bishop (bishopb) Date: 2010-01-19 08:06 Message: Another option: always suggest a survey name, allowing the user to override if desired. If the override collides, suggest a new one. For example, when creating a new survey, the survey name field displays pre-filled with "SURVEY_1234" (where 1234 is the next ID) or "SURVEY_bob_19-1-2010" (where bob is the username and 19-1-2010 is today's date in the locale DMY format). If the user clicks on the survey name field, the pre-filled is erased. But, Franky, so long as we're talking about getting rid of name uniqueness, why not just do it? Existing deployments will not be affected, as the name is already unique. New deployments will simply start using ID. We always check to see if survey name is given on the URL, and we try to resolve that to an ID, and if it fails owing to duplicate, we throw an error indicating as such. ---------------------------------------------------------------------- Comment By: Franky Van Liedekerke (liedekef) Date: 2010-01-19 04:14 Message: Ok, another way of doing it: take away the uniquess on the database column for survey names and work with an option that lets you define wether or not the name must be unique. If the option is "name must be unique" then we give an error if the name is already in use and you need to choose another one (no autocreation of another name for now). If the option is "name must not be unique" then we don't check if the name is already in use, but you might lose the possibility to refer to surveys by name (not that much of a limitation) if more than one survey with the same name exists. Franky ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2010-01-19 03:29 Message: But if you as a user have to think about a unique name every time you create a survey is bit irritating. It directly impacts the usability of application. For an example my application is for academic insitiutions in which instructors creates surveys and time sheets and send them to students participating in team projects. Most of the instructors will try to keep the identical name for their surveys like "timesheet week 1 " or so and as the number of surveys increases finding a unique name may become a trouble for them. Automatically suggesting a name for a survey if that name already exists is a good idea instead of prepending an ID to all survey names. ---------------------------------------------------------------------- Comment By: bishop (bishopb) Date: 2010-01-18 09:06 Message: > the thing is that people can access a survey by doing "?name=SURVEYNAME" > in the URL, therefore the survey name needs to be unique. It was like this > before I took over the project, so I didn't want to break that > functionality. So for now the name needs to be always unique. Agreed -- this should not be touched now. But I meant to suggest when we're designing version 3 we should consider whether we need to keep access by name (natural key) or if access by ID (surrogate key) is just as good. My inclination, without having done any diligence in reviewing the code, is that surrogate key is fine. > But it shouldn't impact existing surveys in any way, only surveys that you can edit are impacted, and these are > never online. Could you give an example of such a use case? Sure, suppose I'm a designer, logged into the admin side. I'm creating a survey for my first period class and I want to give it a name like 'APPSTATP1' so that it looks something like the subject matter. With the new code, I can't have a name like that, because it'll prepend the ID onto the front, so I can never name a survey something entirely appropriate to the subject domain. But suppose that was fixed so that only duplicate survey names get modified. Further suppose I had a survey from last year with my desired name. (Being a survey that recurs on the same subject matter makes this a likely case.) There's a collision, and the patch gives it an automatic name, like '1321APPSTATP1'. Suddenly, that name is no longer obvious and difficult to remember. In this case, I (as the designer) would prefer to be told that the survey name isn't unique and that I need to make it unique, which which case I'd give it a name containing a time signature, like 'APPSTATP1_2010'. Instead of actually saving with a new name, can't we throw an error as now, but recommend a new name, perhaps automatically filling in the survey name field with the recommended name? That way, the user can quickly get a survey with a unique name if he doesn't care about the name particularly, or he can take corrective action to make a relevant unique name. ---------------------------------------------------------------------- Comment By: Franky Van Liedekerke (liedekef) Date: 2010-01-18 04:18 Message: Hi Bishop, the thing is that people can access a survey by doing "?name=SURVEYNAME" in the URL, therefore the survey name needs to be unique. It was like this before I took over the project, so I didn't want to break that functionality. So for now the name needs to be always unique. But it shouldn't impact existing surveys in any way, only surveys that you can edit are impacted, and these are never online. Could you give an example of such a use case? ---------------------------------------------------------------------- Comment By: bishop (bishopb) Date: 2010-01-17 19:14 Message: Automatically adding a number, in all cases, will probably break some existing use cases. Perhaps: 1. Make this a configuration option: "Do you want to generate a unique survey name if creating a new one with an existing name?" Boolean. Default = No. 2. If so configured, atomically test for existence and, if already exists, append the survey ID as in the patch. If not so configured, fail. This would keep existing behavior while allowing the new functionality. Of course, survey ID is already unique, so having the survey name act as a natural key is redundant. Moving into the next major version, we might want to consider whether we need both the surrogate ID and the natural name keys. ---------------------------------------------------------------------- Comment By: Gurdeep Singh (gurdeep22) Date: 2010-01-17 16:57 Message: Yeah its working. i just checked it , it prepends the survey id to the survey name and thus generating unique name every time. But survey Id get prepends to every survey name and not only to those that have duplicate name . this is a good solution for me. I can move ahead now. Thank You very much. Gurdeep ---------------------------------------------------------------------- Comment By: Franky Van Liedekerke (liedekef) Date: 2010-01-17 16:31 Message: Ok, I made some changed to admin/include/function/survey_update.inc that prepends the survey ID if not present, and readding it every time it gets removed, so the chance of getting a double name is next to zero now. Try out the updated version (see attachment in this feature request) and see if it solves the problem for you. If it does, I'll include it in the code with an extra line explaining where the ID comes from. Unless some other people don't agree with this? I didn't want to do it based on the username or userID because that would disclose user information to the outside world, not a wanted effect. Franky ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=358956&aid=2933959&group_id=8956 |
|
From: SourceForge.net <no...@so...> - 2010-01-22 13:15:40
|
Feature Requests item #2864740, was opened at 2009-09-23 05:44 Message generated for change (Comment added) made by liedekef You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=358956&aid=2864740&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: Nobody/Anonymous (nobody) >Assigned to: Franky Van Liedekerke (liedekef) Summary: http://www.opensourcecms.com/ Initial Comment: This is a great application. You should submit this product to OpenSourceCMS.com (http://www.opensourcecms.com/). They will host working demo versions of the latest release so people can try the product. The will also provide alink to your site for the download. Right now there is only one product on there that has 'survey' functionality and it isn't a dedicated survey product. ---------------------------------------------------------------------- >Comment By: Franky Van Liedekerke (liedekef) Date: 2010-01-22 14:15 Message: Well, let me try to get it included there. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=358956&aid=2864740&group_id=8956 |
|
From: SourceForge.net <no...@so...> - 2010-01-22 13:11:23
|
Bugs item #1467924, was opened at 2006-04-10 21:35 Message generated for change (Settings changed) made by liedekef You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=108956&aid=1467924&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: None >Status: Closed >Resolution: Out of Date Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Checkbox Question Export Data Bug Report Initial Comment: Just to let you know, we've had trouble with checkbox questions in phpESP. The tool is not able to export the data for a couple of our questions to csv, though it can make use of it in its own survey results interface. ---------------------------------------------------------------------- >Comment By: Franky Van Liedekerke (liedekef) Date: 2010-01-22 14:11 Message: out of date and not enough info provided, closing ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=108956&aid=1467924&group_id=8956 |
|
From: SourceForge.net <no...@so...> - 2010-01-22 13:10:15
|
Bugs item #1945462, was opened at 2008-04-18 09:48 Message generated for change (Comment added) made by liedekef You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=108956&aid=1945462&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: v2.0.2 >Status: Closed >Resolution: Invalid Priority: 5 Private: No Submitted By: Artur Kusmierek (arturmail) Assigned to: Nobody/Anonymous (nobody) Summary: incorrectly data when exporting Initial Comment: I've noticed that exported data from larger surveys are different from data generated by "View Results from a Survey" and data received via submission e-mails! The only way to get the proper data from MySql database is to export data directly from MySql database (i.e. phpMyAdmin) and sort them in i.e. MS Excel firstly by "response_id" field and secondly by "choice_id". It is not an issue when the survey has 1 or 2 to answers (I can't repeat this error on small group of answered surveys). Maybe it is connected with save survey sessions (getting back later to finish, the "choice_id" field is not set one after another from one person's answer). -- Regards, Artur ---------------------------------------------------------------------- >Comment By: Franky Van Liedekerke (liedekef) Date: 2010-01-22 14:10 Message: I never really found a problem here, so unless the original reporter provides a better script of reproducing this, I'm closing this. ---------------------------------------------------------------------- Comment By: Artur Kusmierek (arturmail) Date: 2008-04-18 12:43 Message: Logged In: YES user_id=2066340 Originator: YES I tried to attach screenshots as a file but looks messy to me. This particual responce id is 91. I'm not an expert but in simple words for me it looks like when tha data is gathering via www and e-mail it is sorted by responce_id and choice_id (don't sure about question_id if it can get tricky). But when the data is being exported it is sorted only by responce_id and question_id (not choice_id) which causes unsorted answers within particular questions. File Added: Rysunek1.jpg ---------------------------------------------------------------------- Comment By: Artur Kusmierek (arturmail) Date: 2008-04-18 12:00 Message: Logged In: YES user_id=2066340 Originator: YES File Added: email.jpg ---------------------------------------------------------------------- Comment By: Artur Kusmierek (arturmail) Date: 2008-04-18 11:59 Message: Logged In: YES user_id=2066340 Originator: YES File Added: www.jpg ---------------------------------------------------------------------- Comment By: Franky Van Liedekerke (liedekef) Date: 2008-04-18 09:55 Message: Logged In: YES user_id=109671 Originator: NO Hi, could you tell me what you mean by differences? An example would be great to track down the problem ... I will see what the save survey sessions do for now and see if I can detect a problem there. Franky ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=108956&aid=1945462&group_id=8956 |
|
From: SourceForge.net <no...@so...> - 2010-01-22 13:05:54
|
Bugs item #1475519, was opened at 2006-04-24 15:02 Message generated for change (Comment added) made by liedekef You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=108956&aid=1475519&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: v1.8 >Status: Closed Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Survey development centres each question Initial Comment: Just installed 1.8.1. I noticed while Previewing and Testing a survey under development that each question in the display is centred. After Activating, each question is left aligned, as expected. For my test I chose Mystic as the Theme. .../neil patterson ---------------------------------------------------------------------- >Comment By: Franky Van Liedekerke (liedekef) Date: 2010-01-22 14:05 Message: I'm going to close this one: preview and test are to see the questions. If wanting to test the layout: make a copy of the survey, activate it and test that against your layout. Since I would advise just to integrate this into your own design, I won't spend much time on internal old themes. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=108956&aid=1475519&group_id=8956 |
|
From: SourceForge.net <no...@so...> - 2010-01-22 13:02:47
|
Bugs item #1086003, was opened at 2004-12-15 20:22 Message generated for change (Settings changed) made by liedekef You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=108956&aid=1086003&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: Ian Tresman (iantresman) Assigned to: Nobody/Anonymous (nobody) Summary: Cross-reference calculates incorrectly? Initial Comment: http://phpesp.sourceforge.net/demo/admin/manage.php?where=results&sid=4402&type=cross 1. This survey, if I cross-reference question (2) Age, with question (12) How much time would you need, the combined total in the bottom right corner does not equal the total of the column or bottom row totals. 2. It would be very useful to hve the option to be able to display the cross-tabulated results as percentages. 3. It would be useful of the URL could be in the "Post" format so that people could INCLUDE the resulting table in other pages. Regards, Ian ---------------------------------------------------------------------- Comment By: Franky Van Liedekerke (liedekef) Date: 2010-01-22 14:02 Message: I'm closing this bug ticket since it doesn't seem to be valid any more, for the others: if still needed, please create feature requests. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=108956&aid=1086003&group_id=8956 |
|
From: SourceForge.net <no...@so...> - 2010-01-22 13:02:41
|
Bugs item #1086003, was opened at 2004-12-15 20:22 Message generated for change (Comment added) made by liedekef You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=108956&aid=1086003&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: Ian Tresman (iantresman) Assigned to: Nobody/Anonymous (nobody) Summary: Cross-reference calculates incorrectly? Initial Comment: http://phpesp.sourceforge.net/demo/admin/manage.php?where=results&sid=4402&type=cross 1. This survey, if I cross-reference question (2) Age, with question (12) How much time would you need, the combined total in the bottom right corner does not equal the total of the column or bottom row totals. 2. It would be very useful to hve the option to be able to display the cross-tabulated results as percentages. 3. It would be useful of the URL could be in the "Post" format so that people could INCLUDE the resulting table in other pages. Regards, Ian ---------------------------------------------------------------------- >Comment By: Franky Van Liedekerke (liedekef) Date: 2010-01-22 14:02 Message: I'm closing this bug ticket since it doesn't seem to be valid any more, for the others: if still needed, please create feature requests. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=108956&aid=1086003&group_id=8956 |
|
From: SourceForge.net <no...@so...> - 2010-01-22 13:01:14
|
Bugs item #1362398, was opened at 2005-11-21 00:42 Message generated for change (Settings changed) made by liedekef You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=108956&aid=1362398&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.8 >Status: Closed Resolution: Out of Date Priority: 5 Private: No Submitted By: James Crook (merlot02) Assigned to: Nobody/Anonymous (nobody) Summary: qnType class isn't being applied to question tables Initial Comment: If I change the qnType class in a new css file, it does not change the style for the text next to yes/no questions, multiple choice etc, where the text is within it's own table. I think the style is not applied to the created table for these question types, and because it is a new table it does not inherit from the containing cell. Example: http://www.chocchipmm.com/phpESP/examples/classes.html Note that the first question has the correct style applied, the next few do not. phpesp 1.8 rc2, php4.something ---------------------------------------------------------------------- Comment By: Franky Van Liedekerke (liedekef) Date: 2009-04-22 10:41 Message: The latest production release already contains the fix, please update. ---------------------------------------------------------------------- Comment By: Franky Van Liedekerke (liedekef) Date: 2009-04-22 10:41 Message: If this is still the case, please reopen this ticket ---------------------------------------------------------------------- Comment By: James Crook (merlot02) Date: 2005-11-22 02:49 Message: Logged In: YES user_id=1380592 I've posted a patch to fix the problem. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=108956&aid=1362398&group_id=8956 |
|
From: SourceForge.net <no...@so...> - 2010-01-22 13:00:30
|
Bugs item #1027980, was opened at 2004-09-14 17:07 Message generated for change (Settings changed) made by liedekef You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=108956&aid=1027980&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: Closed Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Zero value in choice_id on required field Initial Comment: My survey has a large number of 'response_single' replies which are marked as 'required'. The survey handler treats this perfectly - i.e. respondents are blocked from passing onto next question before the previous has been answered. When reviewing the database I notice that approx 40 out of 6000 rows in the 'response_single' table have a zero-value (0) in it for the field 'choice_id'. Since all the underlying questions are "required" I cannot understand how that should be possible. I have tried very hard to provoke this error without luck. Mostly the surveys are run with permission to save and resume but even when I have turned that off I see the problem occassionally. I enclose a dump of the 'response_single' table. Thanks, Sren Voigt ---------------------------------------------------------------------- Comment By: Franky Van Liedekerke (liedekef) Date: 2010-01-22 14:00 Message: way out of date and should be fixed in any 2.x version ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2004-09-16 13:58 Message: Logged In: NO Well you are right for all of the cases exept one. When a respondent exits before the survey is completed, that creates zero responses which is obviously quite sensible. And admitted - that does bring down the number of problem responses to one. Still this one bugs me. My sections / pages have two (r_single) questions and a (r_text) question each. Relative to the r_single-table a respondent should never have more than two zero responses. >From the file I include the respondent_id 124 has four zero responses. response_id question_id choice_id 124 2666 0 124 2665 0 124 2669 6505 124 2670 6510 124 2673 6513 124 2674 6518 124 2677 6523 124 2678 6528 124 2681 6533 124 2682 6538 124 2685 6545 124 2686 6550 124 2689 6555 124 2690 6560 124 2694 6570 124 2693 6565 124 2698 6578 124 2697 6573 124 2702 6590 124 2701 6585 124 2706 6598 124 2705 6593 124 2710 6608 124 2709 6603 124 2714 6620 124 2713 6615 124 2717 6625 124 2718 6630 124 2722 6640 124 2721 6635 124 2726 6650 124 2725 6645 124 2730 6658 124 2729 6653 124 2734 6670 124 2733 6664 124 2738 6680 124 2737 6675 124 2741 6683 124 2742 6688 124 2746 6698 124 2745 6693 124 2750 6708 124 2749 6703 124 2754 6718 124 2753 6713 124 2758 6728 124 2757 6723 124 2762 6739 124 2761 6734 124 2767 0 124 2765 0 In the case of respondent_id 124 she has provided zero- responses for section 1 but has perfectly valid responses until she exits before the last page. I cannot understand how this respondent was allowed to go beyond page 1 without providing answers. And yes - I have tested that phpESP really does require input on this first page. I have tried to exit and come back but seemingly phpESP treats this correctly - I am coming back on the correct first page. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2004-09-14 17:43 Message: Logged In: NO Are you sure that the responses w/ zeros were completed? select id from response where complete = 'Y'; -James ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=108956&aid=1027980&group_id=8956 |
|
From: SourceForge.net <no...@so...> - 2010-01-22 13:00:23
|
Bugs item #1027980, was opened at 2004-09-14 17:07 Message generated for change (Comment added) made by liedekef You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=108956&aid=1027980&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: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Zero value in choice_id on required field Initial Comment: My survey has a large number of 'response_single' replies which are marked as 'required'. The survey handler treats this perfectly - i.e. respondents are blocked from passing onto next question before the previous has been answered. When reviewing the database I notice that approx 40 out of 6000 rows in the 'response_single' table have a zero-value (0) in it for the field 'choice_id'. Since all the underlying questions are "required" I cannot understand how that should be possible. I have tried very hard to provoke this error without luck. Mostly the surveys are run with permission to save and resume but even when I have turned that off I see the problem occassionally. I enclose a dump of the 'response_single' table. Thanks, Sren Voigt ---------------------------------------------------------------------- >Comment By: Franky Van Liedekerke (liedekef) Date: 2010-01-22 14:00 Message: way out of date and should be fixed in any 2.x version ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2004-09-16 13:58 Message: Logged In: NO Well you are right for all of the cases exept one. When a respondent exits before the survey is completed, that creates zero responses which is obviously quite sensible. And admitted - that does bring down the number of problem responses to one. Still this one bugs me. My sections / pages have two (r_single) questions and a (r_text) question each. Relative to the r_single-table a respondent should never have more than two zero responses. >From the file I include the respondent_id 124 has four zero responses. response_id question_id choice_id 124 2666 0 124 2665 0 124 2669 6505 124 2670 6510 124 2673 6513 124 2674 6518 124 2677 6523 124 2678 6528 124 2681 6533 124 2682 6538 124 2685 6545 124 2686 6550 124 2689 6555 124 2690 6560 124 2694 6570 124 2693 6565 124 2698 6578 124 2697 6573 124 2702 6590 124 2701 6585 124 2706 6598 124 2705 6593 124 2710 6608 124 2709 6603 124 2714 6620 124 2713 6615 124 2717 6625 124 2718 6630 124 2722 6640 124 2721 6635 124 2726 6650 124 2725 6645 124 2730 6658 124 2729 6653 124 2734 6670 124 2733 6664 124 2738 6680 124 2737 6675 124 2741 6683 124 2742 6688 124 2746 6698 124 2745 6693 124 2750 6708 124 2749 6703 124 2754 6718 124 2753 6713 124 2758 6728 124 2757 6723 124 2762 6739 124 2761 6734 124 2767 0 124 2765 0 In the case of respondent_id 124 she has provided zero- responses for section 1 but has perfectly valid responses until she exits before the last page. I cannot understand how this respondent was allowed to go beyond page 1 without providing answers. And yes - I have tested that phpESP really does require input on this first page. I have tried to exit and come back but seemingly phpESP treats this correctly - I am coming back on the correct first page. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2004-09-14 17:43 Message: Logged In: NO Are you sure that the responses w/ zeros were completed? select id from response where complete = 'Y'; -James ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=108956&aid=1027980&group_id=8956 |
|
From: SourceForge.net <no...@so...> - 2010-01-22 12:59:01
|
Bugs item #712214, was opened at 2003-03-30 18:03 Message generated for change (Comment added) made by liedekef You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=108956&aid=712214&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: None >Status: Closed Resolution: None Priority: 5 Private: No Submitted By: A. Lougheed (aprillougheed) Assigned to: James Flemer (jimmerman) Summary: docs out of date concerning respondent signup Initial Comment: I've read all the documentation and the mailing list archives and the instructions in the files, etc. I'm SO stuck on this question: Is it possible to have the user signup for a username and password that will allow them to partially fill out the survey, save it and then come back later, login and complete the survey? Is this even possible???? I see instructions about the handler-prefix.php and the hander.php, but I can't figure out how to use this in a PHP file. Thanks in advance for your help. Regards, April Lougheed gu...@gu... ---------------------------------------------------------------------- >Comment By: Franky Van Liedekerke (liedekef) Date: 2010-01-22 13:58 Message: resuming is possible without any problems. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=108956&aid=712214&group_id=8956 |
|
From: SourceForge.net <no...@so...> - 2010-01-22 12:58:12
|
Bugs item #960930, was opened at 2004-05-26 17:50 Message generated for change (Comment added) made by liedekef You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=108956&aid=960930&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: v1.6.1 >Status: Closed Resolution: None Priority: 5 Private: No Submitted By: Tom Ingberg (tingberg) Assigned to: Nobody/Anonymous (nobody) Summary: All texts cannot be translated Initial Comment: Hello again... I just translated phpESP in Finnish. The problem is that some texts in user interface are still in english. For example when editing a survey, everything but the title "Survey Design" and bottom buttons (General, questions, order, preview, finish) is in Finnish. (Well, upper tabs are images and therefore untranslated too at the moment...) I have translated these texts. At the moment there are only 28 untranslated messages, mainly in cross tabulation section. I'll attach my messages.po and .mo files. -Tom ---------------------------------------------------------------------- >Comment By: Franky Van Liedekerke (liedekef) Date: 2010-01-22 13:58 Message: closing this, should be all fixed by now ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=108956&aid=960930&group_id=8956 |
|
From: SourceForge.net <no...@so...> - 2010-01-22 12:55:32
|
Feature Requests item #2669570, was opened at 2009-03-06 22:40 Message generated for change (Settings changed) made by liedekef You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=358956&aid=2669570&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: Cannot create conditions on questions with multiple answers Initial Comment: Most conditions are based on radio buttons, but it's reasonable to expect that you may want to display questions according to selected checkboxes on a question that allows more than one answer. For instance, if a question asks: "What kind of vehicle(s) do you own? [ ] Motorcycle [ ] Car [ ] SUV [ ] Minivan " You may want to ask additional questions in a future section if they have a motorcycle, and other additional questions if they have a car. The workaround is to split this up into separate questions and use Yes/No radio buttons. For example: "Do you drive a motorcycle? () Yes () No Do you drive a car? () Yes () No ... " This isn't necessarily a bad idea -- it may make reporting easier. But if you have a "checklist" of, say, ten items, this could make the survey considerably long by turning one question into ten. The fix as I see it is to add a new conditional operation called "contains". For instance, you would say "Show question 42 is question 21 CONTAINS Motorcycle". The code fix is pretty easy: 1) if the response is an array, convert it to a comma-separated scalar (e.g.: "Motorcycle,Car,SUV" 2) perform your SQL query with LIKE '%$RESPONSE_VALUE%' in the where clause. ---------------------------------------------------------------------- Comment By: Franky Van Liedekerke (liedekef) Date: 2009-03-07 00:35 Message: Well, feel free to make a patch available ... Franky ---------------------------------------------------------------------- Comment By: kswartz (kswartz) Date: 2009-03-06 22:41 Message: Sorry, quick update: this is true for version 2.0.2. I haven't had a chance to look at 2.1.* yet, so if this is fixed there, my apologies. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=358956&aid=2669570&group_id=8956 |
|
From: SourceForge.net <no...@so...> - 2010-01-22 12:53:17
|
Feature Requests item #2933959, was opened at 2010-01-17 21:32 Message generated for change (Comment added) made by liedekef You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=358956&aid=2933959&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: Gurdeep Singh (gurdeep22) Assigned to: Nobody/Anonymous (nobody) Summary: duplicate survey name Initial Comment: multiple surveys cannot be created with a single name. > Now if multiple users access the tool then it is hard to create a new survey everytime with a unique name. It is an important usability aspect and it require solution. Possible solution: If survey ID is appended to the newly created survey name automatically than it will give you a unique survey name itself. or username can also be appended to keep the survey name unique. ---------------------------------------------------------------------- >Comment By: Franky Van Liedekerke (liedekef) Date: 2010-01-22 13:53 Message: I've gotten no response any more after my latest commits, does this mean everybody is happy and I can close the ticket? ---------------------------------------------------------------------- Comment By: Franky Van Liedekerke (liedekef) Date: 2010-01-20 10:22 Message: More files have changed than just those 2, see http://phpesp.svn.sourceforge.net/viewvc/phpesp?view=rev&revision=1143 ---------------------------------------------------------------------- Comment By: Gurdeep Singh (gurdeep22) Date: 2010-01-20 00:56 Message: Heh, Updating the survey.php and finish.inc file is now creating a survey by ID reference. But still you cannot create a survey with duplicate entry. ---------------------------------------------------------------------- Comment By: Franky Van Liedekerke (liedekef) Date: 2010-01-19 23:37 Message: Heh, it seems that changing the xml for this (thus the database structure) and an extra "ORDER BY id ASC" in public/survey.php solves it already. Now just some change in admin/include/tab/finish.inc so the by-name reference disappears from the info, version change in admin/phpESP.ini.php.fixed (othierwise the xml changes don't get picked up ok) and done. Check out svn for the changes and come back to me with comments please. ---------------------------------------------------------------------- Comment By: Franky Van Liedekerke (liedekef) Date: 2010-01-19 23:09 Message: Well, just making the duplicate check user bound (username+survey name as unique DB key) won't cut it for people doing/using the by-name reference now ... this is the easy part btw (just a change in an xml file) I agree that using the first survey found if multiple matches is quirky, but it handles every current situation. Proposal (since it is a svn thingie anyway): I'll cook up a small patch doing what I suggested, resulting in minimal changes for everybody for now and lets test it out :-) ---------------------------------------------------------------------- Comment By: bishop (bishopb) Date: 2010-01-19 20:45 Message: > The thing is, I don't want to stop using the by-name reference just yet. > Suppose you've mailed a survey with a by-name reference to 10.000 persons > and they have 6 months or so to fill it in? These things happen in > governmental organisations (believe me, I know). Sure do, and we want to keep support for them. My proposal maintains backward compatibilty for by-name surveys, while moving the entire system to by-ID, without resulting in cases that are, IMO :), quirky: namely, using the first survey found if multiple matches. I think we can all agree, however, that we should make the duplicate check user bound (ie, a natural key of <user name, survey name>). I'd say we do that now, and I think that might meet Gurdeep's need, and assuming so, we can close this ticket and move the by-name action to its own ticket. ---------------------------------------------------------------------- Comment By: Franky Van Liedekerke (liedekef) Date: 2010-01-19 19:59 Message: The thing is, I don't want to stop using the by-name reference just yet. Suppose you've mailed a survey with a by-name reference to 10.000 persons and they have 6 months or so to fill it in? These things happen in governmental organisations (believe me, I know). For know I believe the first steps to be: - remove the duplicate check (and change the db to use a survey name-user combo as unique db constraint) - for "?name=" syntax use the first survey found (if multiple surveys match the same name) - remove as much of by-name references as possible in the admin backend code (eg. when doing "test" surveys) and replacing by "?id=" In a next step we can further build down by-name reference, by no longer allowing it at all. Seems reasonable easy to code up for now... Franky ---------------------------------------------------------------------- Comment By: bishop (bishopb) Date: 2010-01-19 17:02 Message: Also, if a survey is requested by name, we lookup the ID then throw a 301 - Moved Permanently header to ensure that we do all that we can to stop using the by-name reference. ---------------------------------------------------------------------- Comment By: bishop (bishopb) Date: 2010-01-19 17:00 Message: Suppose name uniqueness is dropped in version X. When upgrading to version X, we know that all surveys with an ID less than or equal to MAX(Survey.ID) := N will have a unique name (as they were created in version < X) and we can record N for reference. Then, when we're resolving a name to an ID, we do eg "SELECT ID FROM Surveys WHERE name=? AND ID < N". In other words, we only look for a survey by name for those surveys created in earlier versions, and we don't care about name uniqueness when given an ID. In effect, we're automating the configuration option you suggest and making it transparent to the end user. If we remove name uniqueness, what is that going to do to the user experience? It'll be possible to create two surveys with the same name, so then how do they tell which is which at a glance? Perhaps what we really want is: a) Change all references to a survey by ID, per the logic presented above b) Enforce a natural key of <survey name, creating user> That way, the software references by ID and can always find a unique survey, and a person cannot ever create a survey with the same title and potentially get confused as to which is which. Thoughts? ---------------------------------------------------------------------- Comment By: Franky Van Liedekerke (liedekef) Date: 2010-01-19 15:11 Message: Bishop, the issue with just removing the duplicate check would result in problems for people having created current surveys that they mailed out using "?name=" syntax, and where newly created surveys get the same name. So maybe my suggestion is the best of all: making the duplicate check optional by using a configuration option. Or even better: just removing the duplicate check, and for "?name=" syntax use the first survey found (if multiple surveys match the same name), but also removing as much of "?name=" references as possible in the admin backend code (eg. when doing "test" surveys) and replacing by "?id=" I don't like suggesting names (too much coding for very little result), and using an ID for a survey that is not yet created is difficult :-) ---------------------------------------------------------------------- Comment By: bishop (bishopb) Date: 2010-01-19 14:06 Message: Another option: always suggest a survey name, allowing the user to override if desired. If the override collides, suggest a new one. For example, when creating a new survey, the survey name field displays pre-filled with "SURVEY_1234" (where 1234 is the next ID) or "SURVEY_bob_19-1-2010" (where bob is the username and 19-1-2010 is today's date in the locale DMY format). If the user clicks on the survey name field, the pre-filled is erased. But, Franky, so long as we're talking about getting rid of name uniqueness, why not just do it? Existing deployments will not be affected, as the name is already unique. New deployments will simply start using ID. We always check to see if survey name is given on the URL, and we try to resolve that to an ID, and if it fails owing to duplicate, we throw an error indicating as such. ---------------------------------------------------------------------- Comment By: Franky Van Liedekerke (liedekef) Date: 2010-01-19 10:14 Message: Ok, another way of doing it: take away the uniquess on the database column for survey names and work with an option that lets you define wether or not the name must be unique. If the option is "name must be unique" then we give an error if the name is already in use and you need to choose another one (no autocreation of another name for now). If the option is "name must not be unique" then we don't check if the name is already in use, but you might lose the possibility to refer to surveys by name (not that much of a limitation) if more than one survey with the same name exists. Franky ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2010-01-19 09:29 Message: But if you as a user have to think about a unique name every time you create a survey is bit irritating. It directly impacts the usability of application. For an example my application is for academic insitiutions in which instructors creates surveys and time sheets and send them to students participating in team projects. Most of the instructors will try to keep the identical name for their surveys like "timesheet week 1 " or so and as the number of surveys increases finding a unique name may become a trouble for them. Automatically suggesting a name for a survey if that name already exists is a good idea instead of prepending an ID to all survey names. ---------------------------------------------------------------------- Comment By: bishop (bishopb) Date: 2010-01-18 15:06 Message: > the thing is that people can access a survey by doing "?name=SURVEYNAME" > in the URL, therefore the survey name needs to be unique. It was like this > before I took over the project, so I didn't want to break that > functionality. So for now the name needs to be always unique. Agreed -- this should not be touched now. But I meant to suggest when we're designing version 3 we should consider whether we need to keep access by name (natural key) or if access by ID (surrogate key) is just as good. My inclination, without having done any diligence in reviewing the code, is that surrogate key is fine. > But it shouldn't impact existing surveys in any way, only surveys that you can edit are impacted, and these are > never online. Could you give an example of such a use case? Sure, suppose I'm a designer, logged into the admin side. I'm creating a survey for my first period class and I want to give it a name like 'APPSTATP1' so that it looks something like the subject matter. With the new code, I can't have a name like that, because it'll prepend the ID onto the front, so I can never name a survey something entirely appropriate to the subject domain. But suppose that was fixed so that only duplicate survey names get modified. Further suppose I had a survey from last year with my desired name. (Being a survey that recurs on the same subject matter makes this a likely case.) There's a collision, and the patch gives it an automatic name, like '1321APPSTATP1'. Suddenly, that name is no longer obvious and difficult to remember. In this case, I (as the designer) would prefer to be told that the survey name isn't unique and that I need to make it unique, which which case I'd give it a name containing a time signature, like 'APPSTATP1_2010'. Instead of actually saving with a new name, can't we throw an error as now, but recommend a new name, perhaps automatically filling in the survey name field with the recommended name? That way, the user can quickly get a survey with a unique name if he doesn't care about the name particularly, or he can take corrective action to make a relevant unique name. ---------------------------------------------------------------------- Comment By: Franky Van Liedekerke (liedekef) Date: 2010-01-18 10:18 Message: Hi Bishop, the thing is that people can access a survey by doing "?name=SURVEYNAME" in the URL, therefore the survey name needs to be unique. It was like this before I took over the project, so I didn't want to break that functionality. So for now the name needs to be always unique. But it shouldn't impact existing surveys in any way, only surveys that you can edit are impacted, and these are never online. Could you give an example of such a use case? ---------------------------------------------------------------------- Comment By: bishop (bishopb) Date: 2010-01-18 01:14 Message: Automatically adding a number, in all cases, will probably break some existing use cases. Perhaps: 1. Make this a configuration option: "Do you want to generate a unique survey name if creating a new one with an existing name?" Boolean. Default = No. 2. If so configured, atomically test for existence and, if already exists, append the survey ID as in the patch. If not so configured, fail. This would keep existing behavior while allowing the new functionality. Of course, survey ID is already unique, so having the survey name act as a natural key is redundant. Moving into the next major version, we might want to consider whether we need both the surrogate ID and the natural name keys. ---------------------------------------------------------------------- Comment By: Gurdeep Singh (gurdeep22) Date: 2010-01-17 22:57 Message: Yeah its working. i just checked it , it prepends the survey id to the survey name and thus generating unique name every time. But survey Id get prepends to every survey name and not only to those that have duplicate name . this is a good solution for me. I can move ahead now. Thank You very much. Gurdeep ---------------------------------------------------------------------- Comment By: Franky Van Liedekerke (liedekef) Date: 2010-01-17 22:31 Message: Ok, I made some changed to admin/include/function/survey_update.inc that prepends the survey ID if not present, and readding it every time it gets removed, so the chance of getting a double name is next to zero now. Try out the updated version (see attachment in this feature request) and see if it solves the problem for you. If it does, I'll include it in the code with an extra line explaining where the ID comes from. Unless some other people don't agree with this? I didn't want to do it based on the username or userID because that would disclose user information to the outside world, not a wanted effect. Franky ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=358956&aid=2933959&group_id=8956 |
|
From: SourceForge.net <no...@so...> - 2010-01-20 09:22:14
|
Feature Requests item #2933959, was opened at 2010-01-17 21:32 Message generated for change (Comment added) made by liedekef You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=358956&aid=2933959&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: Gurdeep Singh (gurdeep22) Assigned to: Nobody/Anonymous (nobody) Summary: duplicate survey name Initial Comment: multiple surveys cannot be created with a single name. > Now if multiple users access the tool then it is hard to create a new survey everytime with a unique name. It is an important usability aspect and it require solution. Possible solution: If survey ID is appended to the newly created survey name automatically than it will give you a unique survey name itself. or username can also be appended to keep the survey name unique. ---------------------------------------------------------------------- >Comment By: Franky Van Liedekerke (liedekef) Date: 2010-01-20 10:22 Message: More files have changed than just those 2, see http://phpesp.svn.sourceforge.net/viewvc/phpesp?view=rev&revision=1143 ---------------------------------------------------------------------- Comment By: Gurdeep Singh (gurdeep22) Date: 2010-01-20 00:56 Message: Heh, Updating the survey.php and finish.inc file is now creating a survey by ID reference. But still you cannot create a survey with duplicate entry. ---------------------------------------------------------------------- Comment By: Franky Van Liedekerke (liedekef) Date: 2010-01-19 23:37 Message: Heh, it seems that changing the xml for this (thus the database structure) and an extra "ORDER BY id ASC" in public/survey.php solves it already. Now just some change in admin/include/tab/finish.inc so the by-name reference disappears from the info, version change in admin/phpESP.ini.php.fixed (othierwise the xml changes don't get picked up ok) and done. Check out svn for the changes and come back to me with comments please. ---------------------------------------------------------------------- Comment By: Franky Van Liedekerke (liedekef) Date: 2010-01-19 23:09 Message: Well, just making the duplicate check user bound (username+survey name as unique DB key) won't cut it for people doing/using the by-name reference now ... this is the easy part btw (just a change in an xml file) I agree that using the first survey found if multiple matches is quirky, but it handles every current situation. Proposal (since it is a svn thingie anyway): I'll cook up a small patch doing what I suggested, resulting in minimal changes for everybody for now and lets test it out :-) ---------------------------------------------------------------------- Comment By: bishop (bishopb) Date: 2010-01-19 20:45 Message: > The thing is, I don't want to stop using the by-name reference just yet. > Suppose you've mailed a survey with a by-name reference to 10.000 persons > and they have 6 months or so to fill it in? These things happen in > governmental organisations (believe me, I know). Sure do, and we want to keep support for them. My proposal maintains backward compatibilty for by-name surveys, while moving the entire system to by-ID, without resulting in cases that are, IMO :), quirky: namely, using the first survey found if multiple matches. I think we can all agree, however, that we should make the duplicate check user bound (ie, a natural key of <user name, survey name>). I'd say we do that now, and I think that might meet Gurdeep's need, and assuming so, we can close this ticket and move the by-name action to its own ticket. ---------------------------------------------------------------------- Comment By: Franky Van Liedekerke (liedekef) Date: 2010-01-19 19:59 Message: The thing is, I don't want to stop using the by-name reference just yet. Suppose you've mailed a survey with a by-name reference to 10.000 persons and they have 6 months or so to fill it in? These things happen in governmental organisations (believe me, I know). For know I believe the first steps to be: - remove the duplicate check (and change the db to use a survey name-user combo as unique db constraint) - for "?name=" syntax use the first survey found (if multiple surveys match the same name) - remove as much of by-name references as possible in the admin backend code (eg. when doing "test" surveys) and replacing by "?id=" In a next step we can further build down by-name reference, by no longer allowing it at all. Seems reasonable easy to code up for now... Franky ---------------------------------------------------------------------- Comment By: bishop (bishopb) Date: 2010-01-19 17:02 Message: Also, if a survey is requested by name, we lookup the ID then throw a 301 - Moved Permanently header to ensure that we do all that we can to stop using the by-name reference. ---------------------------------------------------------------------- Comment By: bishop (bishopb) Date: 2010-01-19 17:00 Message: Suppose name uniqueness is dropped in version X. When upgrading to version X, we know that all surveys with an ID less than or equal to MAX(Survey.ID) := N will have a unique name (as they were created in version < X) and we can record N for reference. Then, when we're resolving a name to an ID, we do eg "SELECT ID FROM Surveys WHERE name=? AND ID < N". In other words, we only look for a survey by name for those surveys created in earlier versions, and we don't care about name uniqueness when given an ID. In effect, we're automating the configuration option you suggest and making it transparent to the end user. If we remove name uniqueness, what is that going to do to the user experience? It'll be possible to create two surveys with the same name, so then how do they tell which is which at a glance? Perhaps what we really want is: a) Change all references to a survey by ID, per the logic presented above b) Enforce a natural key of <survey name, creating user> That way, the software references by ID and can always find a unique survey, and a person cannot ever create a survey with the same title and potentially get confused as to which is which. Thoughts? ---------------------------------------------------------------------- Comment By: Franky Van Liedekerke (liedekef) Date: 2010-01-19 15:11 Message: Bishop, the issue with just removing the duplicate check would result in problems for people having created current surveys that they mailed out using "?name=" syntax, and where newly created surveys get the same name. So maybe my suggestion is the best of all: making the duplicate check optional by using a configuration option. Or even better: just removing the duplicate check, and for "?name=" syntax use the first survey found (if multiple surveys match the same name), but also removing as much of "?name=" references as possible in the admin backend code (eg. when doing "test" surveys) and replacing by "?id=" I don't like suggesting names (too much coding for very little result), and using an ID for a survey that is not yet created is difficult :-) ---------------------------------------------------------------------- Comment By: bishop (bishopb) Date: 2010-01-19 14:06 Message: Another option: always suggest a survey name, allowing the user to override if desired. If the override collides, suggest a new one. For example, when creating a new survey, the survey name field displays pre-filled with "SURVEY_1234" (where 1234 is the next ID) or "SURVEY_bob_19-1-2010" (where bob is the username and 19-1-2010 is today's date in the locale DMY format). If the user clicks on the survey name field, the pre-filled is erased. But, Franky, so long as we're talking about getting rid of name uniqueness, why not just do it? Existing deployments will not be affected, as the name is already unique. New deployments will simply start using ID. We always check to see if survey name is given on the URL, and we try to resolve that to an ID, and if it fails owing to duplicate, we throw an error indicating as such. ---------------------------------------------------------------------- Comment By: Franky Van Liedekerke (liedekef) Date: 2010-01-19 10:14 Message: Ok, another way of doing it: take away the uniquess on the database column for survey names and work with an option that lets you define wether or not the name must be unique. If the option is "name must be unique" then we give an error if the name is already in use and you need to choose another one (no autocreation of another name for now). If the option is "name must not be unique" then we don't check if the name is already in use, but you might lose the possibility to refer to surveys by name (not that much of a limitation) if more than one survey with the same name exists. Franky ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2010-01-19 09:29 Message: But if you as a user have to think about a unique name every time you create a survey is bit irritating. It directly impacts the usability of application. For an example my application is for academic insitiutions in which instructors creates surveys and time sheets and send them to students participating in team projects. Most of the instructors will try to keep the identical name for their surveys like "timesheet week 1 " or so and as the number of surveys increases finding a unique name may become a trouble for them. Automatically suggesting a name for a survey if that name already exists is a good idea instead of prepending an ID to all survey names. ---------------------------------------------------------------------- Comment By: bishop (bishopb) Date: 2010-01-18 15:06 Message: > the thing is that people can access a survey by doing "?name=SURVEYNAME" > in the URL, therefore the survey name needs to be unique. It was like this > before I took over the project, so I didn't want to break that > functionality. So for now the name needs to be always unique. Agreed -- this should not be touched now. But I meant to suggest when we're designing version 3 we should consider whether we need to keep access by name (natural key) or if access by ID (surrogate key) is just as good. My inclination, without having done any diligence in reviewing the code, is that surrogate key is fine. > But it shouldn't impact existing surveys in any way, only surveys that you can edit are impacted, and these are > never online. Could you give an example of such a use case? Sure, suppose I'm a designer, logged into the admin side. I'm creating a survey for my first period class and I want to give it a name like 'APPSTATP1' so that it looks something like the subject matter. With the new code, I can't have a name like that, because it'll prepend the ID onto the front, so I can never name a survey something entirely appropriate to the subject domain. But suppose that was fixed so that only duplicate survey names get modified. Further suppose I had a survey from last year with my desired name. (Being a survey that recurs on the same subject matter makes this a likely case.) There's a collision, and the patch gives it an automatic name, like '1321APPSTATP1'. Suddenly, that name is no longer obvious and difficult to remember. In this case, I (as the designer) would prefer to be told that the survey name isn't unique and that I need to make it unique, which which case I'd give it a name containing a time signature, like 'APPSTATP1_2010'. Instead of actually saving with a new name, can't we throw an error as now, but recommend a new name, perhaps automatically filling in the survey name field with the recommended name? That way, the user can quickly get a survey with a unique name if he doesn't care about the name particularly, or he can take corrective action to make a relevant unique name. ---------------------------------------------------------------------- Comment By: Franky Van Liedekerke (liedekef) Date: 2010-01-18 10:18 Message: Hi Bishop, the thing is that people can access a survey by doing "?name=SURVEYNAME" in the URL, therefore the survey name needs to be unique. It was like this before I took over the project, so I didn't want to break that functionality. So for now the name needs to be always unique. But it shouldn't impact existing surveys in any way, only surveys that you can edit are impacted, and these are never online. Could you give an example of such a use case? ---------------------------------------------------------------------- Comment By: bishop (bishopb) Date: 2010-01-18 01:14 Message: Automatically adding a number, in all cases, will probably break some existing use cases. Perhaps: 1. Make this a configuration option: "Do you want to generate a unique survey name if creating a new one with an existing name?" Boolean. Default = No. 2. If so configured, atomically test for existence and, if already exists, append the survey ID as in the patch. If not so configured, fail. This would keep existing behavior while allowing the new functionality. Of course, survey ID is already unique, so having the survey name act as a natural key is redundant. Moving into the next major version, we might want to consider whether we need both the surrogate ID and the natural name keys. ---------------------------------------------------------------------- Comment By: Gurdeep Singh (gurdeep22) Date: 2010-01-17 22:57 Message: Yeah its working. i just checked it , it prepends the survey id to the survey name and thus generating unique name every time. But survey Id get prepends to every survey name and not only to those that have duplicate name . this is a good solution for me. I can move ahead now. Thank You very much. Gurdeep ---------------------------------------------------------------------- Comment By: Franky Van Liedekerke (liedekef) Date: 2010-01-17 22:31 Message: Ok, I made some changed to admin/include/function/survey_update.inc that prepends the survey ID if not present, and readding it every time it gets removed, so the chance of getting a double name is next to zero now. Try out the updated version (see attachment in this feature request) and see if it solves the problem for you. If it does, I'll include it in the code with an extra line explaining where the ID comes from. Unless some other people don't agree with this? I didn't want to do it based on the username or userID because that would disclose user information to the outside world, not a wanted effect. Franky ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=358956&aid=2933959&group_id=8956 |
|
From: SourceForge.net <no...@so...> - 2010-01-19 23:56:50
|
Feature Requests item #2933959, was opened at 2010-01-17 12:32 Message generated for change (Comment added) made by gurdeep22 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=358956&aid=2933959&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: Gurdeep Singh (gurdeep22) Assigned to: Nobody/Anonymous (nobody) Summary: duplicate survey name Initial Comment: multiple surveys cannot be created with a single name. > Now if multiple users access the tool then it is hard to create a new survey everytime with a unique name. It is an important usability aspect and it require solution. Possible solution: If survey ID is appended to the newly created survey name automatically than it will give you a unique survey name itself. or username can also be appended to keep the survey name unique. ---------------------------------------------------------------------- Comment By: Gurdeep Singh (gurdeep22) Date: 2010-01-19 15:56 Message: Heh, Updating the survey.php and finish.inc file is now creating a survey by ID reference. But still you cannot create a survey with duplicate entry. ---------------------------------------------------------------------- Comment By: Franky Van Liedekerke (liedekef) Date: 2010-01-19 14:37 Message: Heh, it seems that changing the xml for this (thus the database structure) and an extra "ORDER BY id ASC" in public/survey.php solves it already. Now just some change in admin/include/tab/finish.inc so the by-name reference disappears from the info, version change in admin/phpESP.ini.php.fixed (othierwise the xml changes don't get picked up ok) and done. Check out svn for the changes and come back to me with comments please. ---------------------------------------------------------------------- Comment By: Franky Van Liedekerke (liedekef) Date: 2010-01-19 14:09 Message: Well, just making the duplicate check user bound (username+survey name as unique DB key) won't cut it for people doing/using the by-name reference now ... this is the easy part btw (just a change in an xml file) I agree that using the first survey found if multiple matches is quirky, but it handles every current situation. Proposal (since it is a svn thingie anyway): I'll cook up a small patch doing what I suggested, resulting in minimal changes for everybody for now and lets test it out :-) ---------------------------------------------------------------------- Comment By: bishop (bishopb) Date: 2010-01-19 11:45 Message: > The thing is, I don't want to stop using the by-name reference just yet. > Suppose you've mailed a survey with a by-name reference to 10.000 persons > and they have 6 months or so to fill it in? These things happen in > governmental organisations (believe me, I know). Sure do, and we want to keep support for them. My proposal maintains backward compatibilty for by-name surveys, while moving the entire system to by-ID, without resulting in cases that are, IMO :), quirky: namely, using the first survey found if multiple matches. I think we can all agree, however, that we should make the duplicate check user bound (ie, a natural key of <user name, survey name>). I'd say we do that now, and I think that might meet Gurdeep's need, and assuming so, we can close this ticket and move the by-name action to its own ticket. ---------------------------------------------------------------------- Comment By: Franky Van Liedekerke (liedekef) Date: 2010-01-19 10:59 Message: The thing is, I don't want to stop using the by-name reference just yet. Suppose you've mailed a survey with a by-name reference to 10.000 persons and they have 6 months or so to fill it in? These things happen in governmental organisations (believe me, I know). For know I believe the first steps to be: - remove the duplicate check (and change the db to use a survey name-user combo as unique db constraint) - for "?name=" syntax use the first survey found (if multiple surveys match the same name) - remove as much of by-name references as possible in the admin backend code (eg. when doing "test" surveys) and replacing by "?id=" In a next step we can further build down by-name reference, by no longer allowing it at all. Seems reasonable easy to code up for now... Franky ---------------------------------------------------------------------- Comment By: bishop (bishopb) Date: 2010-01-19 08:02 Message: Also, if a survey is requested by name, we lookup the ID then throw a 301 - Moved Permanently header to ensure that we do all that we can to stop using the by-name reference. ---------------------------------------------------------------------- Comment By: bishop (bishopb) Date: 2010-01-19 08:00 Message: Suppose name uniqueness is dropped in version X. When upgrading to version X, we know that all surveys with an ID less than or equal to MAX(Survey.ID) := N will have a unique name (as they were created in version < X) and we can record N for reference. Then, when we're resolving a name to an ID, we do eg "SELECT ID FROM Surveys WHERE name=? AND ID < N". In other words, we only look for a survey by name for those surveys created in earlier versions, and we don't care about name uniqueness when given an ID. In effect, we're automating the configuration option you suggest and making it transparent to the end user. If we remove name uniqueness, what is that going to do to the user experience? It'll be possible to create two surveys with the same name, so then how do they tell which is which at a glance? Perhaps what we really want is: a) Change all references to a survey by ID, per the logic presented above b) Enforce a natural key of <survey name, creating user> That way, the software references by ID and can always find a unique survey, and a person cannot ever create a survey with the same title and potentially get confused as to which is which. Thoughts? ---------------------------------------------------------------------- Comment By: Franky Van Liedekerke (liedekef) Date: 2010-01-19 06:11 Message: Bishop, the issue with just removing the duplicate check would result in problems for people having created current surveys that they mailed out using "?name=" syntax, and where newly created surveys get the same name. So maybe my suggestion is the best of all: making the duplicate check optional by using a configuration option. Or even better: just removing the duplicate check, and for "?name=" syntax use the first survey found (if multiple surveys match the same name), but also removing as much of "?name=" references as possible in the admin backend code (eg. when doing "test" surveys) and replacing by "?id=" I don't like suggesting names (too much coding for very little result), and using an ID for a survey that is not yet created is difficult :-) ---------------------------------------------------------------------- Comment By: bishop (bishopb) Date: 2010-01-19 05:06 Message: Another option: always suggest a survey name, allowing the user to override if desired. If the override collides, suggest a new one. For example, when creating a new survey, the survey name field displays pre-filled with "SURVEY_1234" (where 1234 is the next ID) or "SURVEY_bob_19-1-2010" (where bob is the username and 19-1-2010 is today's date in the locale DMY format). If the user clicks on the survey name field, the pre-filled is erased. But, Franky, so long as we're talking about getting rid of name uniqueness, why not just do it? Existing deployments will not be affected, as the name is already unique. New deployments will simply start using ID. We always check to see if survey name is given on the URL, and we try to resolve that to an ID, and if it fails owing to duplicate, we throw an error indicating as such. ---------------------------------------------------------------------- Comment By: Franky Van Liedekerke (liedekef) Date: 2010-01-19 01:14 Message: Ok, another way of doing it: take away the uniquess on the database column for survey names and work with an option that lets you define wether or not the name must be unique. If the option is "name must be unique" then we give an error if the name is already in use and you need to choose another one (no autocreation of another name for now). If the option is "name must not be unique" then we don't check if the name is already in use, but you might lose the possibility to refer to surveys by name (not that much of a limitation) if more than one survey with the same name exists. Franky ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2010-01-19 00:29 Message: But if you as a user have to think about a unique name every time you create a survey is bit irritating. It directly impacts the usability of application. For an example my application is for academic insitiutions in which instructors creates surveys and time sheets and send them to students participating in team projects. Most of the instructors will try to keep the identical name for their surveys like "timesheet week 1 " or so and as the number of surveys increases finding a unique name may become a trouble for them. Automatically suggesting a name for a survey if that name already exists is a good idea instead of prepending an ID to all survey names. ---------------------------------------------------------------------- Comment By: bishop (bishopb) Date: 2010-01-18 06:06 Message: > the thing is that people can access a survey by doing "?name=SURVEYNAME" > in the URL, therefore the survey name needs to be unique. It was like this > before I took over the project, so I didn't want to break that > functionality. So for now the name needs to be always unique. Agreed -- this should not be touched now. But I meant to suggest when we're designing version 3 we should consider whether we need to keep access by name (natural key) or if access by ID (surrogate key) is just as good. My inclination, without having done any diligence in reviewing the code, is that surrogate key is fine. > But it shouldn't impact existing surveys in any way, only surveys that you can edit are impacted, and these are > never online. Could you give an example of such a use case? Sure, suppose I'm a designer, logged into the admin side. I'm creating a survey for my first period class and I want to give it a name like 'APPSTATP1' so that it looks something like the subject matter. With the new code, I can't have a name like that, because it'll prepend the ID onto the front, so I can never name a survey something entirely appropriate to the subject domain. But suppose that was fixed so that only duplicate survey names get modified. Further suppose I had a survey from last year with my desired name. (Being a survey that recurs on the same subject matter makes this a likely case.) There's a collision, and the patch gives it an automatic name, like '1321APPSTATP1'. Suddenly, that name is no longer obvious and difficult to remember. In this case, I (as the designer) would prefer to be told that the survey name isn't unique and that I need to make it unique, which which case I'd give it a name containing a time signature, like 'APPSTATP1_2010'. Instead of actually saving with a new name, can't we throw an error as now, but recommend a new name, perhaps automatically filling in the survey name field with the recommended name? That way, the user can quickly get a survey with a unique name if he doesn't care about the name particularly, or he can take corrective action to make a relevant unique name. ---------------------------------------------------------------------- Comment By: Franky Van Liedekerke (liedekef) Date: 2010-01-18 01:18 Message: Hi Bishop, the thing is that people can access a survey by doing "?name=SURVEYNAME" in the URL, therefore the survey name needs to be unique. It was like this before I took over the project, so I didn't want to break that functionality. So for now the name needs to be always unique. But it shouldn't impact existing surveys in any way, only surveys that you can edit are impacted, and these are never online. Could you give an example of such a use case? ---------------------------------------------------------------------- Comment By: bishop (bishopb) Date: 2010-01-17 16:14 Message: Automatically adding a number, in all cases, will probably break some existing use cases. Perhaps: 1. Make this a configuration option: "Do you want to generate a unique survey name if creating a new one with an existing name?" Boolean. Default = No. 2. If so configured, atomically test for existence and, if already exists, append the survey ID as in the patch. If not so configured, fail. This would keep existing behavior while allowing the new functionality. Of course, survey ID is already unique, so having the survey name act as a natural key is redundant. Moving into the next major version, we might want to consider whether we need both the surrogate ID and the natural name keys. ---------------------------------------------------------------------- Comment By: Gurdeep Singh (gurdeep22) Date: 2010-01-17 13:57 Message: Yeah its working. i just checked it , it prepends the survey id to the survey name and thus generating unique name every time. But survey Id get prepends to every survey name and not only to those that have duplicate name . this is a good solution for me. I can move ahead now. Thank You very much. Gurdeep ---------------------------------------------------------------------- Comment By: Franky Van Liedekerke (liedekef) Date: 2010-01-17 13:31 Message: Ok, I made some changed to admin/include/function/survey_update.inc that prepends the survey ID if not present, and readding it every time it gets removed, so the chance of getting a double name is next to zero now. Try out the updated version (see attachment in this feature request) and see if it solves the problem for you. If it does, I'll include it in the code with an extra line explaining where the ID comes from. Unless some other people don't agree with this? I didn't want to do it based on the username or userID because that would disclose user information to the outside world, not a wanted effect. Franky ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=358956&aid=2933959&group_id=8956 |
24 messages has been excluded from this view by a project administrator.
