[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: Closed
Priority: 5
Private: No
Submitted By: kswartz (kswartz)
Assigned to: Franky Van Liedekerke (liedekef)
Summary: Need ability for user to delete incomplete survey

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

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

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

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

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

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

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

>Comment By: Franky Van Liedekerke (liedekef)
Date: 2010-01-25 10:36

Message:
I'm closing this, since it's now possible to set the section in the
GET-request so you can point authenticated users to page 1 again directly
(or let them continue where they left off)

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

Comment By: Franky Van Liedekerke (liedekef)
Date: 2009-07-27 20:38

Message:
I've committed a small change to handler.php to fix this (it removes sec=x
from the url if present)

Franky

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

Comment By: Franky Van Liedekerke (liedekef)
Date: 2009-07-27 19:19

Message:
Well, maybe in 2.1.1 it is a reset, but in later versions the old answers
are still there :-) You really should update, because you're now mixing
code from 2.1.1, 2.1.4 and your own ... and the behaviour you expect will
change when you update.
But about the save part: you're right about the link. I saw that, but was
too lazy ;-)
I'll fix it now.

Franky

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

Comment By: bishop (bishopb)
Date: 2009-07-27 19:10

Message:
Along these lines, I'll mention that I'm working on (very slowly) a patch
to dashboard that would effect an actual response delete, not a response
reset as I think we're working on here (note my definition way down below
in comment #2).  I don't know if that should go in this ticket or not.

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

Comment By: kswartz (kswartz)
Date: 2009-07-27 19:01

Message:
Hi Franky,

Okay, looking much better.

I saved a survey on page 3, then quit my browser, restarted, logged in,
and typed in the URL for the survey with "sec=1" added to the URL. This
worked fine. None of the answers were pre-filled in, which is in line with
the feature request here. I was able to continue through past the point
where I saved it without any issue (I had a problem with that the first
time I tried it, but I'll chalk that up to interim code changes, as I
couldn't reproduce it). It also worked if I entered the URL directly,
without going through the dashboard.

The only remaining problem I noticed is that you're not taking the
"sec=##" out of the URL for the <form> action attribute. This causes the
link to resume the survey when you save it to be wrong, and it has sec=##,
but not name=xxx.


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

Comment By: Franky Van Liedekerke (liedekef)
Date: 2009-07-25 12:30

Message:
It should be fixed in SVN now, but remember: it only works when you define
"sec=x" on the URL and only at the beginning of the session. So for a
resume to work with this parameter, you need to close your browser (all
browser windows) first and then reopen the browser (so a new session is
started and you need to log in again).
I've also cleaned up some other mess concerning userid, this parameter was
junk anyway.

Franky

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

Comment By: Franky Van Liedekerke (liedekef)
Date: 2009-07-25 10:37

Message:
Ah, sorry about the closing paren prob, didn't got around to testing it.
I'll test it out today, shouldn't be that difficult to fix :-)

Franky

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

Comment By: kswartz (kswartz)
Date: 2009-07-25 01:28

Message:
Hmm. Picked up the new handler-prefix.php, and it hasn't changed the
behavior for me; it's stlil not picking up sec from the request param. I
remember thinking before this /might/ have to do with some php-level
configuration, but I think that was where I started to run out of time. (I
should have taken better notes on this particular issue.)

Also, you're missing a closing paren on line 123.

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

Comment By: Franky Van Liedekerke (liedekef)
Date: 2009-07-25 00:42

Message:
Go to http://phpesp.svn.sourceforge.net/viewvc/phpesp?view=rev
revision 1122 (the latest one) show the changed files. In fact, only the
handler-prefix.php change is needed I believe ...

Franky

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

Comment By: kswartz (kswartz)
Date: 2009-07-25 00:37

Message:
Cool! Thanks, Franky. If you want, I can test it on top of my install
(which is still at 2.1.2, because I haven't had time to copy over all my
customizations yet). Let me know which files have changed, and I can pull
them down and give it a try.

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

Comment By: Franky Van Liedekerke (liedekef)
Date: 2009-07-24 23:12

Message:
Well, I can guess why: for authenticated surveys, the section-variable
(sec) always gets set to the latest section filled-in upon resume. Now I've
added the code to allow to set the section in the get-request as well (and
cleaned up the code a bit)

Franky

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

Comment By: kswartz (kswartz)
Date: 2009-07-24 20:49

Message:
Hi,

Well, that solved the problem with the userid variable getting munged, but
it still doesn't go to page 1. I think the issue here is that the REQUEST
variable is not overriding the SESSION variable, but, unfortunately, I've
been off this project for the past couple of months, so I haven't had much
time to look into it deeper.

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

Comment By: Franky Van Liedekerke (liedekef)
Date: 2009-07-24 11:33

Message:
Well, it seems this is old code that still got stuck in. Probably removing
the 2 wrongif-statement will not change anything here. So I would remove
if (!empty($_REQUEST['userid'])) 
and also
elseif(!empty($_SERVER['QUERY_STRING'])) {

Could that fix it for you then?

Franky

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

Comment By: bishop (bishopb)
Date: 2009-04-30 17:15

Message:
kswartz> I'm kind of scratching my head here: under what conditions would
that test
kswartz> actually be valid?

I'm not at all familiar with the whys in handler, but just guessing, maybe
when the survey is in test mode?  

But, regardless, that whole conditional is voodoo.  It starts out with "if
empty request userid" then within it says "if not empty request userid"? 
Total black magic.

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

Comment By: kswartz (kswartz)
Date: 2009-04-30 06:43

Message:
Okay, figured out why putting "&sec=1" in the query string doesn't work.
It's because of this section in handler-prefix.php:

    if(empty($_REQUEST['userid'])) {
        // find remote user id (takes the first non-empty of the
following)
        //  1. a GET variable named 'userid'
        //  2. the REMOTE_USER set by HTTP-Authentication
        //  3. the query string
        //  4. the remote ip address
        if (!empty($_REQUEST['userid'])) {
            $_REQUEST['userid'] = $_REQUEST['userid'];
        } elseif(!empty($_SERVER['REMOTE_USER'])) {
            $_REQUEST['userid'] = $_SERVER['REMOTE_USER'];
--->        } elseif(!empty($_SERVER['QUERY_STRING'])) {
            $_REQUEST['userid'] = urldecode($_SERVER['QUERY_STRING']);
        } else {
            $_REQUEST['userid'] = $_SERVER['REMOTE_ADDR'];
        }
    }


The line with "--->" in front is the condition that's triggering
inappropriately. When the first two tests fail, the query_string "sec=1" is
matched here, and it sets userid to that.

I'm kind of scratching my head here: under what conditions would that test
actually be valid? I'm finding that even if I modify that line as follows,
though:

        } elseif(!empty($_SERVER['QUERY_STRING']) &&
(strpos($_SERVER['QUERY_STRING'],'=')===FALSE)) {

it doesn't mess with the userid variable, but it still doesn't modify the
value of sid.

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

Comment By: kswartz (kswartz)
Date: 2009-03-10 22:30

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

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

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

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

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

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

---

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Thanks again.


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

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

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

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

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

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

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

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

Franky

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

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