Re: [phpesp-dev] Introduction; proposal for phpesp fixes

[Franky V. L. <lie...@te...>]

On Sat, 11 Apr 2009 18:02:19 -0700
Keith Swartz <ph...@on...> wrote:

> Greetings,
> 
> I sure hope this list isn't particularly large. I've been using
> phpesp for several months now, and have made numerous fixes and
> enhancements to the project, which I'd like to give back to the
> community.
> 
> Before logging bugs and submitting patches willy-nilly, I wanted to
> do my first round via the developers list. I welcome any comments on
> these before I submit patches and log bugs -- I want to make sure I'm
> staying consistent with the community that has worked on it for so
> long, and that I remain close to the mission of the product, not
> expecting it to do things it wasn't meant to do. Also, think of this
> as my attempt to introduce myself and describe how much I've looked
> at the product. :)
> 
> Here's the list of major issues I plan to attack, in about this order.
> Signup fails: realm is not quoted in INSERT statement Account
> creation always fails: the insert statement into the respondent table
> is the culprit, because the value of realm is not in single quotes.
> (I gotta wonder, though -- how could this not have come up as a bug
> already?)

Hi Keith, it has come up lately :-) And fixed in the git repo. And
another fix is in progress and being tested by Bishop (hopefully
completed this week). Then I'll release a new version that contains the
latest fixes.
So for now I would suggest: get the git and do your patches against
that. See the latest version of CHANGELOG at
http://phpesp.svn.sourceforge.net/viewvc/phpesp/trunk/phpESP/

> Resume survey link broken after saving in test mode Link to
> resume survey after saving in test mode is missing the survey name.
> 
> Emailed survey results must display questions ordered by position,
> not by id Emailed survey results display questions/answers by order
> of id, rather than by order they are shown in application. If you
> add/remove questions several times, the IDs will definitely not
> represent the order in which the questions are presented. The results
> could be extremely confusing or even wrong, especially if questions
> are worded in such a way that you need to read them in order. (For
> example, if a question just says, "If not, why not?")

not a bug, but an enhancement :-) But you're correct. It should be.

> [Related enhancement: add the question number to the email. I have
> found that when respondents typically correspond with the survey
> administrator, or with other respondents, they reference questions by
> their number, since it's prominently displayed in the survey. For
> instance, "I didn't understand question 12." By including it in the
> results that are emailed, it allows the two to be correlated.]

not a bug, but an enhancement :-) But you're correct. It could be (but
should be optional).

> View private survey results by username i/o rid To view survey
> results, the admin must select from a random number counter. This
> number is of no meaning to anyone, so doesn't serve well as a lookup
> key. With the current implementation, it is impossible to look up
> survey results for a specific user, which is a common use case for
> private surveys.

again an enhancement. And again a good one :-)

> The drop-down should display the username in it so its contents can
> potentially be identified. My solution is to display the username,
> followed by the response ID (rather than a generated counter) in
> parentheses after it. The response ID is included because, unlike the
> counter, this value doesn't change. So an admin might remember, "Oh
> yeah, joeuser's survey with ID 145 is the one with the weird
> answers", and easily retrieve it.

again an enhancement. And again a good one :-)
But a counter is also nice sometimes, so keep both if possible. Some
admins like the counter (even more when the admin is not very technical
at all).

> For public surveys, it should display only the response_id, rather
> than an incremental counter. This is a minor improvement, but a
> useful one, because -- again -- the number will remain fixed. So
> looking up the results for survey 45 will ALWAYS show the results for
> survey 45, even if other surveys or results end up getting purged,
> which may change the number if it were just counting rows returned by
> a SQL query.

well ... wether you use the response id or not, it doesn't say much,
since it's public. If a regular (again non-technical) admin looks at
results, he sometimes likes it more to see a counter . Sometimes it's
easier to say "look at 25th response ..." instead of "look at response
with ID 247"

> This fix doesn't solve every use case -- it only goes so far with
> multiple submissions -- but it's a vast improvement. A further
> improvement, which I included, sorts the drop-down box by username
> followed by response ID, for the same reason.
> 
> This can be done for public surveys as well as private ones, but it's
> much more meaningful for private ones, as querying by IP address is
> going to be almost as useless as querying by response id. My fix only
> applies to private surveys, although a future enhancement could add a
> config option to control this. The first two, by the way, are very
> easy one-line fixes. If someone can easily verify that the first one
> is a bug for all users, I'd advocate putting that into the upcoming
> release. The others can probably wait a little bit if nobody else has
> really complained, and I can provide fixes for those once the
> impending release branches.
> 
> Cheers.
> -- Keith
>    AIM/Y! : kswartz26
> 

Already thanks for any work done on phpESP, it helps to make it better
all the time!

Franky