phpesp-devel — Discussion of the development of phpESP

[phpesp-dev] [ phpesp-Feature Requests-2864740 ] http://www.opensourcecms.com/

[SourceForge.net <no...@so...>]

Feature Requests item #2864740, was opened at 2009-09-23 03:44
Message generated for change (Tracker Item Submitted) made by nobody
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: Nobody/Anonymous (nobody)
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.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=358956&aid=2864740&group_id=8956

[phpesp-dev] [ phpesp-Feature Requests-2771716 ] Allow possible answers to have associated "credit"

[SourceForge.net <no...@so...>]

Feature Requests item #2771716, was opened at 2009-04-18 01:08
Message generated for change (Comment added) made by nobody
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=358956&aid=2771716&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: survey format
Group: None
Status: Closed
Priority: 5
Private: No
Submitted By: bishop (bishopb)
Assigned to: bishop (bishopb)
Summary: Allow possible answers to have associated "credit"

Initial Comment:
The core of phpESP functionality is "ask question, record answer."  This
functionality applies to surveys ("tell me your opinion") and to
examinations ("tell me what you know").

However, examinations get graded, which means each possible answer contributes
numerically to an overall score.  For example, say you have a 20 question exam
with a 100 point scale.  Each question is worth 5 points.  Some questions may
have a strictly right answer (credit=5), while the rest are strictly wrong
(credit=0).  Other questions may have strictly right, partially right
(credit=4, 3, 2, or 1), and strictly wrong answers.  The survey designer makes
these decisions when creating their examination.

The scope of this feature request is to add a "credit" value for each possible
answer in a question supporting possible answers (Yes/No, Radio, Checkbox,
Rate, etc.)  This would be added as an additional column in the answer matrix
on the question definition of the survey creator.  For every answer entry box,
there would be an entry box into which a number may be entered.  This is the
response "credit".  For example:

    LABEL                     CREDIT
 1. [_____________________]   [____]
 2. [_____________________]   [____]
 3. [_____________________]   [____]
 4. [_____________________]   [____]
 5. [_____________________]   [____]
 6. [_____________________]   [____]
 7. [_____________________]   [____]
 8. [_____________________]   [____]
 9. [_____________________]   [____]
10. [_____________________]   [____]


The "possible score" is the sum of the all maximum possible response credits.
For example, 20 questions, each with a maximum credit of 5, yields a "possible
score" of 100.  Since the "possible score" is constant, it should be computed
and stored in the survey definition.

For a completed survey, the "score" is the sum of all specific response's credit.
For example, 20 questions, each with a maximum credit of 5, all strictly
right/strictly wrong questions, missing one would yield a "score" of 95.
Since this is constant once the response is marked as complete, store this in the
response definition.

Allow the admin to enter any numeric value, including negative and floating
point numbers.  (Because we cannot predict exotic uses, we should be
maximally flexible.)  Deny any value that is not numeric.  Any question
without credits, or any question that does not make use of possible
answers, contributes nothing (that is, 0) to the score and possible score.

Show the score on the "thank you" page after completing a survey, as
"Score: N out of M (P%)".  For example, "Score 95 out of 100 (95%)".

Also show the score on the "Navigate Individual Respondent Submissions" page,
at the top of the page, in the same format as for the thank you page.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2009-09-23 03:26

Message:
I'm interested.  If you are going down this route, then have you considered
adding QTI XML 2.0 Support (http://www.imsglobal.org/question/) which would
allow instructors to import question databases provided by 3rd parties or
to author their questions in desktop software such as "Respondus"
(http://www.respondus.com/products/respondus.shtml).

QTI's xml formats are well documented and well thought out covering many
instructional question formats that are useful to all levels of education,
including multiple choice, ordering, matching, gap matching, inline choice,
text entry, hottext, hotspot, slider, etc.

Many of these formats would also work as survey formats, such as slider as
an alternate to Likert style questions (i.e. 1= Agree 3 = neutral
5=Disagree).  Even ordering for a questions like "If stranded on a desert
island, put these items in the order from most important to least important
for survival" would be great.

----------------------------------------------------------------------

Comment By: bishop (bishopb)
Date: 2009-05-29 18:59

Message:
Thanks Franky!

i'd like to note that the implementation differs from the requirements
above, as follows:
1. The score is not cached in the response.
2. The respondent's score is not shown on the thank you page; however, the
score is shown on each summary page, along with any feedback.
3. The score is not shown on the "Navigate Individual Respondent
Submissions".
4. There is no concept of "total possible score".

I decided not to implement these "admin" type features until further use
cases present themselves.  For example, instead of computing the total
possible score as the sum of all credit, it may make sense to allow the
admin to enter the total possible score on the survey definition page.

Since there isn't any voting capability in SourceForge (AFAIK), anyone
wishing to see particular functionality please comment in this ticket.

----------------------------------------------------------------------

Comment By: Franky Van Liedekerke (liedekef)
Date: 2009-05-28 21:04

Message:
nice work!

Franky

----------------------------------------------------------------------

Comment By: bishop (bishopb)
Date: 2009-05-28 18:55

Message:
I have committed this to SVN. It will be publically available in the next
release; anyone wanting a preview now should export the phpesp trunk.

----------------------------------------------------------------------

Comment By: bishop (bishopb)
Date: 2009-05-28 14:45

Message:
Revised design: only question types of radio buttons, check boxes, and
dropdown box will be able to assign credit to possible answers.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=358956&aid=2771716&group_id=8956

[phpesp-dev] [ phpesp-Patches-2862454 ] Support multiple email addresses

[SourceForge.net <no...@so...>]

Patches item #2862454, was opened at 2009-09-20 03:11
Message generated for change (Tracker Item Submitted) made by nobody
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=308956&aid=2862454&group_id=8956

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Support multiple email addresses

Initial Comment:
This patch will allow you to specify multiple emails, separated by ; 

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=308956&aid=2862454&group_id=8956

[phpesp-dev] [ phpesp-Patches-2852945 ] Patch Set for Rate (i.e. Type 8) Labels

[SourceForge.net <no...@so...>]

Patches item #2852945, was opened at 2009-09-06 16:09
Message generated for change (Tracker Item Submitted) made by jimbysf
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=308956&aid=2852945&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: Jim Brown (jimbysf)
Assigned to: Nobody/Anonymous (nobody)
Summary: Patch Set for Rate (i.e. Type 8) Labels

Initial Comment:
Here is a gzipped tarball with some patches, and other information on my implementation of individualized rate labels. 
This is not ready for general usage since it does not include support in the GUI for adding rate labels.  The labels are
added via the customized  phpespmod.pl script (included).

The README.txt file contains the information needed to get started.  There is also an example typescript showing
how it's done.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=308956&aid=2852945&group_id=8956

[phpesp-dev] [ phpesp-Patches-2848901 ] Bug fix in signup.php

[SourceForge.net <no...@so...>]

Patches item #2848901, was opened at 2009-09-02 01:08
Message generated for change (Tracker Item Submitted) made by stevet103
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=308956&aid=2848901&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: SteveT (stevet103)
Assigned to: Nobody/Anonymous (nobody)
Summary: Bug fix in signup.php

Initial Comment:
I found a bug in signup.php that causes a sql error when a user attempts to signup for a private survey.  

For phpesp v2.1.3 the change is on line 114,
to change FROM:
    array_push($sqlv, addslashes($signup_realm) );
to change TO:
    array_push($sqlv, _addslashes($signup_realm) );
Note all that is added is the "underscore" in front of the addslashes function.

I actually found this typo in phpesp v1.8.5 (since that's what my free webserver installed) and then checked v2.1.3 and the same bug exists there.
I tested this fix with phpesp v1.8.5 on my local windows server as well as my free webserver and this fixed the problem and users could then signup for the private surveys that I created with phpesp and using the the survey link provided by phpesp.  I would "assume" this would work on v2.1.3 as well since this
code part (lines 114 to 122 where the execute_sql function is called) has remained the same across the versions.

Hope this helps.
Regards,
Steve T.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=308956&aid=2848901&group_id=8956

[phpesp-dev] [ phpesp-Feature Requests-2072351 ] Labels for ratings grid

[SourceForge.net <no...@so...>]

Feature Requests item #2072351, was opened at 2008-08-25 00:24
Message generated for change (Comment added) made by jimbysf
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=358956&aid=2072351&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: Sam Karpluk (skarpluk)
Assigned to: Nobody/Anonymous (nobody)
Summary: Labels for ratings grid

Initial Comment:
I think it would be a good addition to optionally apply labels to the rating grid options. Right now they are numbered 1...n, so you can have a scale of, say, 1, 2, 3, 4, 5 as your headings on the grid. I think it would be useful to label these, such as Strongly Disagree(1), Disagree(2), Neutral(3), Agree(4), Strongly Agree(5).

 

----------------------------------------------------------------------

Comment By: Jim Brown (jimbysf)
Date: 2009-08-29 10:54

Message:
I have some code that does this. I'll post it as a patch.  Be aware that it
performs well on the back-end (i.e. survey display, and input) but there is
no support for adding labels in the management GUI.  

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=358956&aid=2072351&group_id=8956

[phpesp-dev] [ phpesp-Feature Requests-2676835 ] Need ability for user to delete incomplete survey

[SourceForge.net <no...@so...>]

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: Open
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: 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

[phpesp-dev] [ phpesp-Feature Requests-2676835 ] Need ability for user to delete incomplete survey

[SourceForge.net <no...@so...>]

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: Open
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: 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

[phpesp-dev] [ phpesp-Feature Requests-2676835 ] Need ability for user to delete incomplete survey

[SourceForge.net <no...@so...>]

Feature Requests item #2676835, was opened at 2009-03-09 19:46
Message generated for change (Comment added) made by bishopb
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=358956&aid=2676835&group_id=8956

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
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: bishop (bishopb)
Date: 2009-07-27 13: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 13: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 06: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 04: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-24 19: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-24 18: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-24 18: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 17: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 14: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 05: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 11: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 00: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 17: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 14:50

Message:
I would think that sec=1 would do it, as that sets the section.  Upon
cursory review of the code (handler.php down to survey_render.php), that
looks correct.  Can you include your modified URL and a little more
description of the "sets the hidden user id parameter to 'sec=1'" problem?

Re: survey_reset() vs. survey_delete().  Your situation does sound like it
could go both ways, so the easiest thing to do would be to link to a
"delete" handler right on the survey.  That handler (say delete.php) takes
the response ID and blows away the survey (via survey_delete()), then links
back (or throws a header) to the dashboard.  That would be ad-hoc and could
be kept out of the phpESP source tree for your own use.

But, to implement this to production would require some more
fortification.  The delete handler, for example, would need to also
corroborate the SID to prevent delete attacks.  We would also want to add
per-survey control over whether responses may be deleted by the
respondent.

Were there to be a survey_reset(), that would need to figure out the
default values and set the entries to those defaults, opting to null if no
defaults were defined.  (I don't recall if we have a definition of "default
values", so setting to null always would be appropriate.)  Nonetheless, I
don't think a survey_reset() would waste the response table rows: it would
simply update them to the default values (eg null).  (And then possibly
increment a reset_counter in the statistics table.)

----------------------------------------------------------------------

Comment By: kswartz (kswartz)
Date: 2009-03-10 13:59

Message:
BTW, I've joined the developer's mailing list. If that is a more
appropriate forum for discussions of this nature in the future, please let
me know, and I'll do that. I logged a request mainly because I thought
there was strong support for this to be a generic enhancement, and there
might be a patch resulting from the discussion (possibly from me).

----------------------------------------------------------------------

Comment By: kswartz (kswartz)
Date: 2009-03-10 13:58

Message:
This is great. Thank you for the ideas!

How do you link back to the first page of a survey? I tried adding
"&sec=1" to the URL, but then it sets the hidden userid parameter to
"sec=1". (That looks like a bug, by the way. :) )

Actually, my use case is really more of a deletion, than a reset, but
either one would work.

The survey we've implemented is used to request and gather information
about using another software product in conjunction with our own. The use
case I envision is that the respondent decides they don't want to use that
product after doing the research. But the survey has to be filled out once
for each product they want to use, so if the user finds something else he
wants to use, he has to fill out a new survey, starting from scratch.

In our case, nothing from the original survey would be preserved, except
for about 3 questions (of roughly 100) with information identifying the
requester. [If this were going to be a 100% custom solution for us, I might
consider preserving that data. I've been trying not to make too many
changes like that, however, as it'll make it harder for me to contribute
other fixes I've made back to the project.]

Now, in our case, there are no default values -- everything is blank to
start out. In that case, the only difference between resetting and deleting
the survey that I can see is that deleting it removes a row from the
response table. Both options would still remove all the rows from the
response_* child tables (again, that's specific to this case, where none of
the questions have default values). Is that an accurate assessment?

Thanks again.


----------------------------------------------------------------------

Comment By: bishop (bishopb)
Date: 2009-03-10 08:13

Message:
I'm with Franky, at least in addressing a valid navigation use case ("user
wants to review or change submitted responses, starting from the
beginning").

I'd also like to define the semantic differences of "resetting" a survey's
responses and "deleting" a survey.  The former keeps the survey, but
initializes responses to default values.  The latter removes any indication
that the user every began the survey.  It's entirely possible that
"resetting" is allowed (and desired), but "deleting" is not.  I can also
see cases where you'd want to record the number of resets (for statistical
analysis on the effectiveness of your surveys).

Your description of the problem sounds more like resetting, than deleting.
 If that is the case, I would not reuse the admin survey_delete() code
based on response ID.  Instead, I'd write a new function (say
survey_reset()) and expose it both in admin (keyed off of response ID) and
in userland (as at least a link on the survey itself, possibly (though not
recommended) with a link on the dashboard).

----------------------------------------------------------------------

Comment By: Franky Van Liedekerke (liedekef)
Date: 2009-03-10 03:36

Message:
How about just providing a link to the first page of the survey? You can do
this at the bottom, top, anywhere within the current survey ...

Franky

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=358956&aid=2676835&group_id=8956

[phpesp-dev] [ phpesp-Feature Requests-2676835 ] Need ability for user to delete incomplete survey

[SourceForge.net <no...@so...>]

Feature Requests item #2676835, was opened at 2009-03-09 16:46
Message generated for change (Comment added) made by kswartz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=358956&aid=2676835&group_id=8956

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Priority: 5
Private: No
Submitted By: kswartz (kswartz)
Assigned to: 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: kswartz (kswartz)
Date: 2009-07-27 10: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 03: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 01: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-24 16: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-24 15: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-24 15: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 14: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 11: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 02: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 08: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-29 21: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 14:30

Message:
This is the URL I was using to try and jump to page 1:

http://localhost/techeval/public/survey.php?sec=1&name=ebstecheval

However, it just reloads the page I saved on. When I do a view source,  I
see this:

<input type="hidden" name="userid" value="sec=1" />
<input type="hidden" name="sid" value="3" />
<input type="hidden" name="rid" value="113" />
<input type="hidden" name="sec" value="3" />

Not sure if it's relevant, but this is a private survey, with navigation
and save/resume enabled.

Of course, overriding the URL on the browser bar is mixing GET parameters
with POST parameters. If handler.php looks at the POST parameter over the
GET one, then putting it in a URL won't work. I'll have to use a JavaScript
handler to update the sec hidden field to something like 2, then pretend
the user hit the Prev button. (I don't even know if that'll work, just a
guess.)

---

I totally agree about productizing any such solution. I would also want to
harden it by comparing the owner of the current session and the owner of
the survey, and only allow a delete (or reset) if they match. The
per-survey control is something I can forego for my own purposes, although
I would certainly agree with the need for that in the product.

Regarding the resetting option, when you say: "Nonetheless, I don't think
a survey_reset() would waste the response table rows: it would simply
update them to the default values (eg null).", I see a problem with that if
the questions are marked as required. It might technically work if you're
only enforcing that constraint through the UI, but I'm visualizing a
scenario in which the user manually tweaks the URL to jump to the last page
and submit his survey -- now full of unanswered questions that require a
value. (I'm also making an assumption here that a null value is not an
acceptable answer when one is required. Functionally, I think that's
appropriate.)

----------------------------------------------------------------------

Comment By: bishop (bishopb)
Date: 2009-03-10 11:50

Message:
I would think that sec=1 would do it, as that sets the section.  Upon
cursory review of the code (handler.php down to survey_render.php), that
looks correct.  Can you include your modified URL and a little more
description of the "sets the hidden user id parameter to 'sec=1'" problem?

Re: survey_reset() vs. survey_delete().  Your situation does sound like it
could go both ways, so the easiest thing to do would be to link to a
"delete" handler right on the survey.  That handler (say delete.php) takes
the response ID and blows away the survey (via survey_delete()), then links
back (or throws a header) to the dashboard.  That would be ad-hoc and could
be kept out of the phpESP source tree for your own use.

But, to implement this to production would require some more
fortification.  The delete handler, for example, would need to also
corroborate the SID to prevent delete attacks.  We would also want to add
per-survey control over whether responses may be deleted by the
respondent.

Were there to be a survey_reset(), that would need to figure out the
default values and set the entries to those defaults, opting to null if no
defaults were defined.  (I don't recall if we have a definition of "default
values", so setting to null always would be appropriate.)  Nonetheless, I
don't think a survey_reset() would waste the response table rows: it would
simply update them to the default values (eg null).  (And then possibly
increment a reset_counter in the statistics table.)

----------------------------------------------------------------------

Comment By: kswartz (kswartz)
Date: 2009-03-10 10:59

Message:
BTW, I've joined the developer's mailing list. If that is a more
appropriate forum for discussions of this nature in the future, please let
me know, and I'll do that. I logged a request mainly because I thought
there was strong support for this to be a generic enhancement, and there
might be a patch resulting from the discussion (possibly from me).

----------------------------------------------------------------------

Comment By: kswartz (kswartz)
Date: 2009-03-10 10:58

Message:
This is great. Thank you for the ideas!

How do you link back to the first page of a survey? I tried adding
"&sec=1" to the URL, but then it sets the hidden userid parameter to
"sec=1". (That looks like a bug, by the way. :) )

Actually, my use case is really more of a deletion, than a reset, but
either one would work.

The survey we've implemented is used to request and gather information
about using another software product in conjunction with our own. The use
case I envision is that the respondent decides they don't want to use that
product after doing the research. But the survey has to be filled out once
for each product they want to use, so if the user finds something else he
wants to use, he has to fill out a new survey, starting from scratch.

In our case, nothing from the original survey would be preserved, except
for about 3 questions (of roughly 100) with information identifying the
requester. [If this were going to be a 100% custom solution for us, I might
consider preserving that data. I've been trying not to make too many
changes like that, however, as it'll make it harder for me to contribute
other fixes I've made back to the project.]

Now, in our case, there are no default values -- everything is blank to
start out. In that case, the only difference between resetting and deleting
the survey that I can see is that deleting it removes a row from the
response table. Both options would still remove all the rows from the
response_* child tables (again, that's specific to this case, where none of
the questions have default values). Is that an accurate assessment?

Thanks again.


----------------------------------------------------------------------

Comment By: bishop (bishopb)
Date: 2009-03-10 05:13

Message:
I'm with Franky, at least in addressing a valid navigation use case ("user
wants to review or change submitted responses, starting from the
beginning").

I'd also like to define the semantic differences of "resetting" a survey's
responses and "deleting" a survey.  The former keeps the survey, but
initializes responses to default values.  The latter removes any indication
that the user every began the survey.  It's entirely possible that
"resetting" is allowed (and desired), but "deleting" is not.  I can also
see cases where you'd want to record the number of resets (for statistical
analysis on the effectiveness of your surveys).

Your description of the problem sounds more like resetting, than deleting.
 If that is the case, I would not reuse the admin survey_delete() code
based on response ID.  Instead, I'd write a new function (say
survey_reset()) and expose it both in admin (keyed off of response ID) and
in userland (as at least a link on the survey itself, possibly (though not
recommended) with a link on the dashboard).

----------------------------------------------------------------------

Comment By: Franky Van Liedekerke (liedekef)
Date: 2009-03-10 00:36

Message:
How about just providing a link to the first page of the survey? You can do
this at the bottom, top, anywhere within the current survey ...

Franky

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=358956&aid=2676835&group_id=8956

[phpesp-dev] [ phpesp-Feature Requests-1445933 ] add 'line break" tag to break long questions/text

[SourceForge.net <no...@so...>]

Feature Requests item #1445933, was opened at 2006-03-08 22:15
Message generated for change (Comment added) made by liedekef
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=358956&aid=1445933&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: Closed
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: add 'line break" tag to break long questions/text

Initial Comment:
be nice to have a "\n" feature (or newline feature) 
so that if you have a long introductory text or 
section header you can have a line break or two. 

----------------------------------------------------------------------

>Comment By: Franky Van Liedekerke (liedekef)
Date: 2009-07-26 01:02

Message:
the text of a question can be html, you can also add section breaks where
ever you want. Also "section text" as a question type might help you here.

Frankt

----------------------------------------------------------------------

Comment By: Lexus (lexus78)
Date: 2006-03-30 17:02

Message:
Logged In: YES 
user_id=1253202

>From my experience you can easily enter HTML code in the
question texts.

Therefore it what you are looking for can be achieved by
writing <br />

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=358956&aid=1445933&group_id=8956

[phpesp-dev] [ phpesp-Feature Requests-1480092 ] mySQL and md5??

[SourceForge.net <no...@so...>]

Feature Requests item #1480092, was opened at 2006-05-02 01:33
Message generated for change (Comment added) made by liedekef
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=358956&aid=1480092&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: J Peterson (jpeter1491)
Assigned to: Nobody/Anonymous (nobody)
Summary: mySQL and md5??

Initial Comment:
Hello, first I have to say this is a great program.  
Thank you!

Here is my problem...  I manage a website that users 
have already registered for, and their passwords are 
md5 encrypted.  How can I change phpESP to read the 
md5 hash that I copied over from another table?  I've 
tried changing all 'PASSWORD($password)' to 'md5
($password)' to no avail.  I've looked all over the 
README files, FAQs, and searched the mail archives.  
Any other suggestions??  I really appreciate your 
help.

phpESP ver: 1.8.1
mySQL ver: 3.23.58

john [at] johnpetersonpictures [dot] com

----------------------------------------------------------------------

>Comment By: Franky Van Liedekerke (liedekef)
Date: 2009-07-26 01:00

Message:
sorry, but this is not a feature request ... and probably out of date
already as well

Franky

----------------------------------------------------------------------

Comment By: kswartz (kswartz)
Date: 2009-04-21 20:56

Message:
My apologies on the OLD_PASSWORD comment - I misread the problem
description. And, actually, the use of OLD_PASSWORD isn't as simple as I
laid it out to be. It is required not when you are using a pre-4.1 version
of MySQL, but when you are using /client libraries/ from MySQL 4.0 or
earlier to connect to a MySQL server running 4.1 or later. (I hit this
problem on my own installation, as I only had limited control over updating
the system libraries on my machine.)

So it's not as simple as checking the version of the database server to
know which one to use. Using md5, however, gets rid of this problem
altogether, since it's behavior is consistent regardless of the database
client or server version. So I like the enhancement for that reason, in
addition to bishop's observation that it can be applied to multiple
databases, and less database-specific code has many advantages.

Of course, after recent events, one has to also assume that MySQL and
Oracle will, in fact, remain separate in the long run. ;-)

----------------------------------------------------------------------

Comment By: bishop (bishopb)
Date: 2009-04-21 15:07

Message:
The less database specific code, the better, IMO.  Of course, we should
have the flexibility to utilize db-specific code, when needed for
performance or other technical reasons.  I'd vote to put this in the
roadmap for discussion in v3.

----------------------------------------------------------------------

Comment By: Franky Van Liedekerke (liedekef)
Date: 2009-04-21 14:53

Message:
True, on all points.
Even then, maybe md5 is better than using mysql password function ... then
we can eliminate some database specific code and use md5 everywhere, no?
But on the other hand, updating from PASSWORD to MD5 will be a real pain
ita ...

Franky

----------------------------------------------------------------------

Comment By: bishop (bishopb)
Date: 2009-04-21 14:25

Message:
I would also recommend updating phpESP to the latest version.  And MySQL
3... I personally don't support any more.

----------------------------------------------------------------------

Comment By: bishop (bishopb)
Date: 2009-04-21 14:24

Message:
Most password-related functionality comes from the db_crypt() function in
phpESP/admin/include/lib/espdatalib.inc

I would start by changing that function to return MD5, like the Oracle
case does.  There are two other references to PASSWORD() in that file, and
those may need to be updated, too.

As for the PASSWORD v. OLD_PASSWORD issue, that should probably also be
handled in the db_crypt() function.

----------------------------------------------------------------------

Comment By: Franky Van Liedekerke (liedekef)
Date: 2009-04-21 09:27

Message:
Well, the original ticket owner wants to replace PASSWORD by md5 calls, so
wether or not it is OLD_PASSWORD or PASSWORD, it doesn't matter :-)

----------------------------------------------------------------------

Comment By: kswartz (kswartz)
Date: 2009-04-21 09:02

Message:
If you're running with a version of MySQL older than 5.0, you need to
change the references of PASSWORD() to OLD_PASSWORD(). See
http://dev.mysql.com/doc/refman/5.0/en/encryption-functions.html#function_old-password
.

If the documentation doesn't state that MySQL 5.x or later is required,
then technically this is a bug (but could arguably be a doc bug).

----------------------------------------------------------------------

Comment By: Franky Van Liedekerke (liedekef)
Date: 2009-04-20 10:17

Message:
This is not a bug, so moving to feature request.

Franky

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=358956&aid=1480092&group_id=8956

[phpesp-dev] [ phpesp-Feature Requests-1974528 ] unique answers within a question

[SourceForge.net <no...@so...>]

Feature Requests item #1974528, was opened at 2008-05-27 11:29
Message generated for change (Comment added) made by liedekef
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=358956&aid=1974528&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: Artur Kusmierek (arturmail)
Assigned to: Nobody/Anonymous (nobody)
Summary: unique answers within a question

Initial Comment:
Is there any chance to get unique answers within one question? For example in a rate one the options are: "1", "2" and "3" and these shouldn't repeat so I should get one "1" rank, one "2" rank and one "3" rank within one question.

----------------------------------------------------------------------

>Comment By: Franky Van Liedekerke (liedekef)
Date: 2009-07-26 00:58

Message:
The latest stable version should provide for this.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2008-11-04 22:28

Message:
unique answers within a question   	 Private: (?)
No
Is there any chance to get unique answers within one question? For
example
in a rate one the options are: "1", "2" and "3" and these shouldn't
repeat
so I should get one "1" rank, one "2" rank and one "3" rank within one
question.

----------------------------------------------------------------------

Comment By: Artur Kusmierek (arturmail)
Date: 2008-05-27 13:22

Message:
Logged In: YES 
user_id=2066340
Originator: YES

I've noticed but this is not a solution for my problem. I would like
uniquely rank a question within a range (for example from 1 to 3). I cannot
use textbox, essay or numerical type of question because a respondent is
able to put some ranks out of my range (in this particular case for example
"5").

----------------------------------------------------------------------

Comment By: Franky Van Liedekerke (liedekef)
Date: 2008-05-27 12:13

Message:
Logged In: YES 
user_id=109671
Originator: NO

unique answers are possible for certain types of questions (textbox,
essay, numerical), see the changelog in version 2.1.0

Franky

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=358956&aid=1974528&group_id=8956

[phpesp-dev] [ phpesp-Feature Requests-2827042 ] Support request

[SourceForge.net <no...@so...>]

Feature Requests item #2827042, was opened at 2009-07-25 17:06
Message generated for change (Comment added) made by liedekef
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=358956&aid=2827042&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: Deleted
Priority: 1
Private: No
Submitted By: John Brown (johnbs1)
Assigned to: Nobody/Anonymous (nobody)
Summary: Support request

Initial Comment:
Attempting to develop an independent survey in regards clergy abuse. Seeking the assistance of someone competent in the use of phpESP. 

http://mybrokensociety.com/survey

----------------------------------------------------------------------

>Comment By: Franky Van Liedekerke (liedekef)
Date: 2009-07-26 00:56

Message:
I agree here: post your request to the mailing list (it light even be that
I respond to it

Franky

----------------------------------------------------------------------

Comment By: bishop (bishopb)
Date: 2009-07-25 18:09

Message:
I'm not certain how this qualifies as a "feature request".  Do you have a
particular modification you wish to have made to the phpESP software?

If you simply have questions about phpESP, the best route to address those
questions is to join the phpESP general mailing list and discuss there:
https://lists.sourceforge.net/lists/listinfo/phpesp-general

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=358956&aid=2827042&group_id=8956

[phpesp-dev] [ phpesp-Feature Requests-2827042 ] Support request

[SourceForge.net <no...@so...>]

Feature Requests item #2827042, was opened at 2009-07-25 11:06
Message generated for change (Comment added) made by bishopb
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=358956&aid=2827042&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: 1
Private: No
Submitted By: John Brown (johnbs1)
Assigned to: Nobody/Anonymous (nobody)
Summary: Support request

Initial Comment:
Attempting to develop an independent survey in regards clergy abuse. Seeking the assistance of someone competent in the use of phpESP. 

http://mybrokensociety.com/survey

----------------------------------------------------------------------

>Comment By: bishop (bishopb)
Date: 2009-07-25 12:09

Message:
I'm not certain how this qualifies as a "feature request".  Do you have a
particular modification you wish to have made to the phpESP software?

If you simply have questions about phpESP, the best route to address those
questions is to join the phpESP general mailing list and discuss there:
https://lists.sourceforge.net/lists/listinfo/phpesp-general

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=358956&aid=2827042&group_id=8956

[phpesp-dev] [ phpesp-Feature Requests-2827042 ] Support request

[SourceForge.net <no...@so...>]

Feature Requests item #2827042, was opened at 2009-07-26 01:06
Message generated for change (Tracker Item Submitted) made by johnbs1
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=358956&aid=2827042&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: John Brown (johnbs1)
Assigned to: Nobody/Anonymous (nobody)
Summary: Support request

Initial Comment:
Attempting to develop an independent survey in regards clergy abuse. Seeking the assistance of someone competent in the use of phpESP. 

http://mybrokensociety.com/survey

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=358956&aid=2827042&group_id=8956

[phpesp-dev] [ phpesp-Feature Requests-2676835 ] Need ability for user to delete incomplete survey

[SourceForge.net <no...@so...>]

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: Open
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: 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

[phpesp-dev] [ phpesp-Feature Requests-2676835 ] Need ability for user to delete incomplete survey

[SourceForge.net <no...@so...>]

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: Open
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: 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

[phpesp-dev] [ phpesp-Feature Requests-2676835 ] Need ability for user to delete incomplete survey

[SourceForge.net <no...@so...>]

Feature Requests item #2676835, was opened at 2009-03-09 16:46
Message generated for change (Comment added) made by kswartz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=358956&aid=2676835&group_id=8956

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Priority: 5
Private: No
Submitted By: kswartz (kswartz)
Assigned to: 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: kswartz (kswartz)
Date: 2009-07-24 16: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-24 15: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-24 15: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 14: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 11: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 02: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 08: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-29 21: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 14:30

Message:
This is the URL I was using to try and jump to page 1:

http://localhost/techeval/public/survey.php?sec=1&name=ebstecheval

However, it just reloads the page I saved on. When I do a view source,  I
see this:

<input type="hidden" name="userid" value="sec=1" />
<input type="hidden" name="sid" value="3" />
<input type="hidden" name="rid" value="113" />
<input type="hidden" name="sec" value="3" />

Not sure if it's relevant, but this is a private survey, with navigation
and save/resume enabled.

Of course, overriding the URL on the browser bar is mixing GET parameters
with POST parameters. If handler.php looks at the POST parameter over the
GET one, then putting it in a URL won't work. I'll have to use a JavaScript
handler to update the sec hidden field to something like 2, then pretend
the user hit the Prev button. (I don't even know if that'll work, just a
guess.)

---

I totally agree about productizing any such solution. I would also want to
harden it by comparing the owner of the current session and the owner of
the survey, and only allow a delete (or reset) if they match. The
per-survey control is something I can forego for my own purposes, although
I would certainly agree with the need for that in the product.

Regarding the resetting option, when you say: "Nonetheless, I don't think
a survey_reset() would waste the response table rows: it would simply
update them to the default values (eg null).", I see a problem with that if
the questions are marked as required. It might technically work if you're
only enforcing that constraint through the UI, but I'm visualizing a
scenario in which the user manually tweaks the URL to jump to the last page
and submit his survey -- now full of unanswered questions that require a
value. (I'm also making an assumption here that a null value is not an
acceptable answer when one is required. Functionally, I think that's
appropriate.)

----------------------------------------------------------------------

Comment By: bishop (bishopb)
Date: 2009-03-10 11:50

Message:
I would think that sec=1 would do it, as that sets the section.  Upon
cursory review of the code (handler.php down to survey_render.php), that
looks correct.  Can you include your modified URL and a little more
description of the "sets the hidden user id parameter to 'sec=1'" problem?

Re: survey_reset() vs. survey_delete().  Your situation does sound like it
could go both ways, so the easiest thing to do would be to link to a
"delete" handler right on the survey.  That handler (say delete.php) takes
the response ID and blows away the survey (via survey_delete()), then links
back (or throws a header) to the dashboard.  That would be ad-hoc and could
be kept out of the phpESP source tree for your own use.

But, to implement this to production would require some more
fortification.  The delete handler, for example, would need to also
corroborate the SID to prevent delete attacks.  We would also want to add
per-survey control over whether responses may be deleted by the
respondent.

Were there to be a survey_reset(), that would need to figure out the
default values and set the entries to those defaults, opting to null if no
defaults were defined.  (I don't recall if we have a definition of "default
values", so setting to null always would be appropriate.)  Nonetheless, I
don't think a survey_reset() would waste the response table rows: it would
simply update them to the default values (eg null).  (And then possibly
increment a reset_counter in the statistics table.)

----------------------------------------------------------------------

Comment By: kswartz (kswartz)
Date: 2009-03-10 10:59

Message:
BTW, I've joined the developer's mailing list. If that is a more
appropriate forum for discussions of this nature in the future, please let
me know, and I'll do that. I logged a request mainly because I thought
there was strong support for this to be a generic enhancement, and there
might be a patch resulting from the discussion (possibly from me).

----------------------------------------------------------------------

Comment By: kswartz (kswartz)
Date: 2009-03-10 10:58

Message:
This is great. Thank you for the ideas!

How do you link back to the first page of a survey? I tried adding
"&sec=1" to the URL, but then it sets the hidden userid parameter to
"sec=1". (That looks like a bug, by the way. :) )

Actually, my use case is really more of a deletion, than a reset, but
either one would work.

The survey we've implemented is used to request and gather information
about using another software product in conjunction with our own. The use
case I envision is that the respondent decides they don't want to use that
product after doing the research. But the survey has to be filled out once
for each product they want to use, so if the user finds something else he
wants to use, he has to fill out a new survey, starting from scratch.

In our case, nothing from the original survey would be preserved, except
for about 3 questions (of roughly 100) with information identifying the
requester. [If this were going to be a 100% custom solution for us, I might
consider preserving that data. I've been trying not to make too many
changes like that, however, as it'll make it harder for me to contribute
other fixes I've made back to the project.]

Now, in our case, there are no default values -- everything is blank to
start out. In that case, the only difference between resetting and deleting
the survey that I can see is that deleting it removes a row from the
response table. Both options would still remove all the rows from the
response_* child tables (again, that's specific to this case, where none of
the questions have default values). Is that an accurate assessment?

Thanks again.


----------------------------------------------------------------------

Comment By: bishop (bishopb)
Date: 2009-03-10 05:13

Message:
I'm with Franky, at least in addressing a valid navigation use case ("user
wants to review or change submitted responses, starting from the
beginning").

I'd also like to define the semantic differences of "resetting" a survey's
responses and "deleting" a survey.  The former keeps the survey, but
initializes responses to default values.  The latter removes any indication
that the user every began the survey.  It's entirely possible that
"resetting" is allowed (and desired), but "deleting" is not.  I can also
see cases where you'd want to record the number of resets (for statistical
analysis on the effectiveness of your surveys).

Your description of the problem sounds more like resetting, than deleting.
 If that is the case, I would not reuse the admin survey_delete() code
based on response ID.  Instead, I'd write a new function (say
survey_reset()) and expose it both in admin (keyed off of response ID) and
in userland (as at least a link on the survey itself, possibly (though not
recommended) with a link on the dashboard).

----------------------------------------------------------------------

Comment By: Franky Van Liedekerke (liedekef)
Date: 2009-03-10 00:36

Message:
How about just providing a link to the first page of the survey? You can do
this at the bottom, top, anywhere within the current survey ...

Franky

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=358956&aid=2676835&group_id=8956

[phpesp-dev] [ phpesp-Feature Requests-2676835 ] Need ability for user to delete incomplete survey

[SourceForge.net <no...@so...>]

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: Open
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: 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

[phpesp-dev] [ phpesp-Feature Requests-2676835 ] Need ability for user to delete incomplete survey

[SourceForge.net <no...@so...>]

Feature Requests item #2676835, was opened at 2009-03-09 16:46
Message generated for change (Comment added) made by kswartz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=358956&aid=2676835&group_id=8956

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Priority: 5
Private: No
Submitted By: kswartz (kswartz)
Assigned to: 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: kswartz (kswartz)
Date: 2009-07-24 15: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 14: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 11: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 02: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 08: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-29 21: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 14:30

Message:
This is the URL I was using to try and jump to page 1:

http://localhost/techeval/public/survey.php?sec=1&name=ebstecheval

However, it just reloads the page I saved on. When I do a view source,  I
see this:

<input type="hidden" name="userid" value="sec=1" />
<input type="hidden" name="sid" value="3" />
<input type="hidden" name="rid" value="113" />
<input type="hidden" name="sec" value="3" />

Not sure if it's relevant, but this is a private survey, with navigation
and save/resume enabled.

Of course, overriding the URL on the browser bar is mixing GET parameters
with POST parameters. If handler.php looks at the POST parameter over the
GET one, then putting it in a URL won't work. I'll have to use a JavaScript
handler to update the sec hidden field to something like 2, then pretend
the user hit the Prev button. (I don't even know if that'll work, just a
guess.)

---

I totally agree about productizing any such solution. I would also want to
harden it by comparing the owner of the current session and the owner of
the survey, and only allow a delete (or reset) if they match. The
per-survey control is something I can forego for my own purposes, although
I would certainly agree with the need for that in the product.

Regarding the resetting option, when you say: "Nonetheless, I don't think
a survey_reset() would waste the response table rows: it would simply
update them to the default values (eg null).", I see a problem with that if
the questions are marked as required. It might technically work if you're
only enforcing that constraint through the UI, but I'm visualizing a
scenario in which the user manually tweaks the URL to jump to the last page
and submit his survey -- now full of unanswered questions that require a
value. (I'm also making an assumption here that a null value is not an
acceptable answer when one is required. Functionally, I think that's
appropriate.)

----------------------------------------------------------------------

Comment By: bishop (bishopb)
Date: 2009-03-10 11:50

Message:
I would think that sec=1 would do it, as that sets the section.  Upon
cursory review of the code (handler.php down to survey_render.php), that
looks correct.  Can you include your modified URL and a little more
description of the "sets the hidden user id parameter to 'sec=1'" problem?

Re: survey_reset() vs. survey_delete().  Your situation does sound like it
could go both ways, so the easiest thing to do would be to link to a
"delete" handler right on the survey.  That handler (say delete.php) takes
the response ID and blows away the survey (via survey_delete()), then links
back (or throws a header) to the dashboard.  That would be ad-hoc and could
be kept out of the phpESP source tree for your own use.

But, to implement this to production would require some more
fortification.  The delete handler, for example, would need to also
corroborate the SID to prevent delete attacks.  We would also want to add
per-survey control over whether responses may be deleted by the
respondent.

Were there to be a survey_reset(), that would need to figure out the
default values and set the entries to those defaults, opting to null if no
defaults were defined.  (I don't recall if we have a definition of "default
values", so setting to null always would be appropriate.)  Nonetheless, I
don't think a survey_reset() would waste the response table rows: it would
simply update them to the default values (eg null).  (And then possibly
increment a reset_counter in the statistics table.)

----------------------------------------------------------------------

Comment By: kswartz (kswartz)
Date: 2009-03-10 10:59

Message:
BTW, I've joined the developer's mailing list. If that is a more
appropriate forum for discussions of this nature in the future, please let
me know, and I'll do that. I logged a request mainly because I thought
there was strong support for this to be a generic enhancement, and there
might be a patch resulting from the discussion (possibly from me).

----------------------------------------------------------------------

Comment By: kswartz (kswartz)
Date: 2009-03-10 10:58

Message:
This is great. Thank you for the ideas!

How do you link back to the first page of a survey? I tried adding
"&sec=1" to the URL, but then it sets the hidden userid parameter to
"sec=1". (That looks like a bug, by the way. :) )

Actually, my use case is really more of a deletion, than a reset, but
either one would work.

The survey we've implemented is used to request and gather information
about using another software product in conjunction with our own. The use
case I envision is that the respondent decides they don't want to use that
product after doing the research. But the survey has to be filled out once
for each product they want to use, so if the user finds something else he
wants to use, he has to fill out a new survey, starting from scratch.

In our case, nothing from the original survey would be preserved, except
for about 3 questions (of roughly 100) with information identifying the
requester. [If this were going to be a 100% custom solution for us, I might
consider preserving that data. I've been trying not to make too many
changes like that, however, as it'll make it harder for me to contribute
other fixes I've made back to the project.]

Now, in our case, there are no default values -- everything is blank to
start out. In that case, the only difference between resetting and deleting
the survey that I can see is that deleting it removes a row from the
response table. Both options would still remove all the rows from the
response_* child tables (again, that's specific to this case, where none of
the questions have default values). Is that an accurate assessment?

Thanks again.


----------------------------------------------------------------------

Comment By: bishop (bishopb)
Date: 2009-03-10 05:13

Message:
I'm with Franky, at least in addressing a valid navigation use case ("user
wants to review or change submitted responses, starting from the
beginning").

I'd also like to define the semantic differences of "resetting" a survey's
responses and "deleting" a survey.  The former keeps the survey, but
initializes responses to default values.  The latter removes any indication
that the user every began the survey.  It's entirely possible that
"resetting" is allowed (and desired), but "deleting" is not.  I can also
see cases where you'd want to record the number of resets (for statistical
analysis on the effectiveness of your surveys).

Your description of the problem sounds more like resetting, than deleting.
 If that is the case, I would not reuse the admin survey_delete() code
based on response ID.  Instead, I'd write a new function (say
survey_reset()) and expose it both in admin (keyed off of response ID) and
in userland (as at least a link on the survey itself, possibly (though not
recommended) with a link on the dashboard).

----------------------------------------------------------------------

Comment By: Franky Van Liedekerke (liedekef)
Date: 2009-03-10 00:36

Message:
How about just providing a link to the first page of the survey? You can do
this at the bottom, top, anywhere within the current survey ...

Franky

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=358956&aid=2676835&group_id=8956

[phpesp-dev] [ phpesp-Feature Requests-2676835 ] Need ability for user to delete incomplete survey

[SourceForge.net <no...@so...>]

Feature Requests item #2676835, was opened at 2009-03-10 00:46
Message generated for change (Settings changed) 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: Open
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: 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

[phpesp-dev] [ phpesp-Feature Requests-2676835 ] Need ability for user to delete incomplete survey

[SourceForge.net <no...@so...>]

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: Open
Priority: 5
Private: No
Submitted By: kswartz (kswartz)
Assigned to: Nobody/Anonymous (nobody)
Summary: Need ability for user to delete incomplete survey

Initial Comment:
I've been making numerous enhancements to phpESP on my own (many of which I'm about to work on giving back), but I'm a bit stumped on how to move forward on this one, and would like some advice (in the absence of an actual fix).

We have a lengthy survey that may be filled out multiple times by our users. The survey has about 100 questions, and may be done over a period of a few days, while the respondent does some research.

We've found that occasionally, a user will want to scrap the survey completely, but still enter a new one. However, any time they sign in and try to start the survey, it always uses their saved one, and starts them where they left off.

We want to introduce the option to DELETE a saved-but-incomplete survey from the dashboard page. I'm up for working on this code myself, but need some advice. Is there a good way to securely reuse the code that does this in the admin pages? Unlike the admin pages, a user doesn't have to be a superuser to delete his OWN survey.

Right now, the workaround we have is to resume the saved survey, and hit the "Previous Page" button all the way back to page 1. Unfortunately, at 20 pages, that's a bit painful.

I am visualizing an additional column on the dashboard page, called "Action". It can show a link to delete a saved survey, OR a link to view (or edit, depending on whether the survey would support it) any previously submitted copies of the survey. That's a separate enhancement request; I just wanted to mention how I saw this one fitting into a bigger picture.

----------------------------------------------------------------------

>Comment By: 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

[phpesp-dev] [ phpesp-Feature Requests-2676835 ] Need ability for user to delete incomplete survey

[SourceForge.net <no...@so...>]

Feature Requests item #2676835, was opened at 2009-03-09 16:46
Message generated for change (Comment added) made by kswartz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=358956&aid=2676835&group_id=8956

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Priority: 5
Private: No
Submitted By: kswartz (kswartz)
Assigned to: Nobody/Anonymous (nobody)
Summary: Need ability for user to delete incomplete survey

Initial Comment:
I've been making numerous enhancements to phpESP on my own (many of which I'm about to work on giving back), but I'm a bit stumped on how to move forward on this one, and would like some advice (in the absence of an actual fix).

We have a lengthy survey that may be filled out multiple times by our users. The survey has about 100 questions, and may be done over a period of a few days, while the respondent does some research.

We've found that occasionally, a user will want to scrap the survey completely, but still enter a new one. However, any time they sign in and try to start the survey, it always uses their saved one, and starts them where they left off.

We want to introduce the option to DELETE a saved-but-incomplete survey from the dashboard page. I'm up for working on this code myself, but need some advice. Is there a good way to securely reuse the code that does this in the admin pages? Unlike the admin pages, a user doesn't have to be a superuser to delete his OWN survey.

Right now, the workaround we have is to resume the saved survey, and hit the "Previous Page" button all the way back to page 1. Unfortunately, at 20 pages, that's a bit painful.

I am visualizing an additional column on the dashboard page, called "Action". It can show a link to delete a saved survey, OR a link to view (or edit, depending on whether the survey would support it) any previously submitted copies of the survey. That's a separate enhancement request; I just wanted to mention how I saw this one fitting into a bigger picture.

----------------------------------------------------------------------

>Comment By: kswartz (kswartz)
Date: 2009-07-24 11: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 02: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 08: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-29 21: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 14:30

Message:
This is the URL I was using to try and jump to page 1:

http://localhost/techeval/public/survey.php?sec=1&name=ebstecheval

However, it just reloads the page I saved on. When I do a view source,  I
see this:

<input type="hidden" name="userid" value="sec=1" />
<input type="hidden" name="sid" value="3" />
<input type="hidden" name="rid" value="113" />
<input type="hidden" name="sec" value="3" />

Not sure if it's relevant, but this is a private survey, with navigation
and save/resume enabled.

Of course, overriding the URL on the browser bar is mixing GET parameters
with POST parameters. If handler.php looks at the POST parameter over the
GET one, then putting it in a URL won't work. I'll have to use a JavaScript
handler to update the sec hidden field to something like 2, then pretend
the user hit the Prev button. (I don't even know if that'll work, just a
guess.)

---

I totally agree about productizing any such solution. I would also want to
harden it by comparing the owner of the current session and the owner of
the survey, and only allow a delete (or reset) if they match. The
per-survey control is something I can forego for my own purposes, although
I would certainly agree with the need for that in the product.

Regarding the resetting option, when you say: "Nonetheless, I don't think
a survey_reset() would waste the response table rows: it would simply
update them to the default values (eg null).", I see a problem with that if
the questions are marked as required. It might technically work if you're
only enforcing that constraint through the UI, but I'm visualizing a
scenario in which the user manually tweaks the URL to jump to the last page
and submit his survey -- now full of unanswered questions that require a
value. (I'm also making an assumption here that a null value is not an
acceptable answer when one is required. Functionally, I think that's
appropriate.)

----------------------------------------------------------------------

Comment By: bishop (bishopb)
Date: 2009-03-10 11:50

Message:
I would think that sec=1 would do it, as that sets the section.  Upon
cursory review of the code (handler.php down to survey_render.php), that
looks correct.  Can you include your modified URL and a little more
description of the "sets the hidden user id parameter to 'sec=1'" problem?

Re: survey_reset() vs. survey_delete().  Your situation does sound like it
could go both ways, so the easiest thing to do would be to link to a
"delete" handler right on the survey.  That handler (say delete.php) takes
the response ID and blows away the survey (via survey_delete()), then links
back (or throws a header) to the dashboard.  That would be ad-hoc and could
be kept out of the phpESP source tree for your own use.

But, to implement this to production would require some more
fortification.  The delete handler, for example, would need to also
corroborate the SID to prevent delete attacks.  We would also want to add
per-survey control over whether responses may be deleted by the
respondent.

Were there to be a survey_reset(), that would need to figure out the
default values and set the entries to those defaults, opting to null if no
defaults were defined.  (I don't recall if we have a definition of "default
values", so setting to null always would be appropriate.)  Nonetheless, I
don't think a survey_reset() would waste the response table rows: it would
simply update them to the default values (eg null).  (And then possibly
increment a reset_counter in the statistics table.)

----------------------------------------------------------------------

Comment By: kswartz (kswartz)
Date: 2009-03-10 10:59

Message:
BTW, I've joined the developer's mailing list. If that is a more
appropriate forum for discussions of this nature in the future, please let
me know, and I'll do that. I logged a request mainly because I thought
there was strong support for this to be a generic enhancement, and there
might be a patch resulting from the discussion (possibly from me).

----------------------------------------------------------------------

Comment By: kswartz (kswartz)
Date: 2009-03-10 10:58

Message:
This is great. Thank you for the ideas!

How do you link back to the first page of a survey? I tried adding
"&sec=1" to the URL, but then it sets the hidden userid parameter to
"sec=1". (That looks like a bug, by the way. :) )

Actually, my use case is really more of a deletion, than a reset, but
either one would work.

The survey we've implemented is used to request and gather information
about using another software product in conjunction with our own. The use
case I envision is that the respondent decides they don't want to use that
product after doing the research. But the survey has to be filled out once
for each product they want to use, so if the user finds something else he
wants to use, he has to fill out a new survey, starting from scratch.

In our case, nothing from the original survey would be preserved, except
for about 3 questions (of roughly 100) with information identifying the
requester. [If this were going to be a 100% custom solution for us, I might
consider preserving that data. I've been trying not to make too many
changes like that, however, as it'll make it harder for me to contribute
other fixes I've made back to the project.]

Now, in our case, there are no default values -- everything is blank to
start out. In that case, the only difference between resetting and deleting
the survey that I can see is that deleting it removes a row from the
response table. Both options would still remove all the rows from the
response_* child tables (again, that's specific to this case, where none of
the questions have default values). Is that an accurate assessment?

Thanks again.


----------------------------------------------------------------------

Comment By: bishop (bishopb)
Date: 2009-03-10 05:13

Message:
I'm with Franky, at least in addressing a valid navigation use case ("user
wants to review or change submitted responses, starting from the
beginning").

I'd also like to define the semantic differences of "resetting" a survey's
responses and "deleting" a survey.  The former keeps the survey, but
initializes responses to default values.  The latter removes any indication
that the user every began the survey.  It's entirely possible that
"resetting" is allowed (and desired), but "deleting" is not.  I can also
see cases where you'd want to record the number of resets (for statistical
analysis on the effectiveness of your surveys).

Your description of the problem sounds more like resetting, than deleting.
 If that is the case, I would not reuse the admin survey_delete() code
based on response ID.  Instead, I'd write a new function (say
survey_reset()) and expose it both in admin (keyed off of response ID) and
in userland (as at least a link on the survey itself, possibly (though not
recommended) with a link on the dashboard).

----------------------------------------------------------------------

Comment By: Franky Van Liedekerke (liedekef)
Date: 2009-03-10 00:36

Message:
How about just providing a link to the first page of the survey? You can do
this at the bottom, top, anywhere within the current survey ...

Franky

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=358956&aid=2676835&group_id=8956

[phpesp-dev] [ phpesp-Feature Requests-2676835 ] Need ability for user to delete incomplete survey

[SourceForge.net <no...@so...>]

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: Open
Priority: 5
Private: No
Submitted By: kswartz (kswartz)
Assigned to: Nobody/Anonymous (nobody)
Summary: Need ability for user to delete incomplete survey

Initial Comment:
I've been making numerous enhancements to phpESP on my own (many of which I'm about to work on giving back), but I'm a bit stumped on how to move forward on this one, and would like some advice (in the absence of an actual fix).

We have a lengthy survey that may be filled out multiple times by our users. The survey has about 100 questions, and may be done over a period of a few days, while the respondent does some research.

We've found that occasionally, a user will want to scrap the survey completely, but still enter a new one. However, any time they sign in and try to start the survey, it always uses their saved one, and starts them where they left off.

We want to introduce the option to DELETE a saved-but-incomplete survey from the dashboard page. I'm up for working on this code myself, but need some advice. Is there a good way to securely reuse the code that does this in the admin pages? Unlike the admin pages, a user doesn't have to be a superuser to delete his OWN survey.

Right now, the workaround we have is to resume the saved survey, and hit the "Previous Page" button all the way back to page 1. Unfortunately, at 20 pages, that's a bit painful.

I am visualizing an additional column on the dashboard page, called "Action". It can show a link to delete a saved survey, OR a link to view (or edit, depending on whether the survey would support it) any previously submitted copies of the survey. That's a separate enhancement request; I just wanted to mention how I saw this one fitting into a bigger picture.

----------------------------------------------------------------------

>Comment By: 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