[phpesp-dev] [ phpesp-Feature Requests-2933959 ] duplicate survey name

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

Feature Requests item #2933959, was opened at 2010-01-17 21:32
Message generated for change (Comment added) made by liedekef
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=358956&aid=2933959&group_id=8956

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

Initial Comment:
multiple surveys cannot be created with a single name. > Now if multiple users  access the tool then it is hard to create a new survey everytime with a unique name.   It is an important usability aspect and it require solution. 

Possible solution:  If  survey ID is appended to the newly created survey name automatically than it will give you a unique survey name itself. 
or username can also be appended to keep the survey name unique. 

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

>Comment By: Franky Van Liedekerke (liedekef)
Date: 2010-01-20 10:22

Message:
More files have changed than just those 2, see
http://phpesp.svn.sourceforge.net/viewvc/phpesp?view=rev&revision=1143

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

Comment By: Gurdeep Singh (gurdeep22)
Date: 2010-01-20 00:56

Message:
Heh, 

Updating the survey.php and finish.inc file is now creating a survey by ID
reference.  But still you cannot create a survey with duplicate entry. 

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

Comment By: Franky Van Liedekerke (liedekef)
Date: 2010-01-19 23:37

Message:
Heh, it seems that changing the xml for this (thus the database structure)
and an extra "ORDER BY id ASC" in public/survey.php solves it already. Now
just some change in admin/include/tab/finish.inc so the by-name reference
disappears from the info, version change in admin/phpESP.ini.php.fixed
(othierwise the xml changes don't get picked up ok) and done.
Check out svn for the changes and come back to me with comments please.

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

Comment By: Franky Van Liedekerke (liedekef)
Date: 2010-01-19 23:09

Message:
Well, just making the duplicate check user bound (username+survey name as
unique DB key) won't cut it for people doing/using the by-name reference
now ... this is the easy part btw (just a change in an xml file)
I agree that using the first survey found if multiple matches is quirky,
but it handles every current situation.
Proposal (since it is a svn thingie anyway): I'll cook up a small patch
doing what I suggested, resulting in minimal changes for everybody for now
and lets test it out :-)

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

Comment By: bishop (bishopb)
Date: 2010-01-19 20:45

Message:
> The thing is, I don't want to stop using the by-name reference just yet.
> Suppose you've mailed a survey with a by-name reference to 10.000
persons
> and they have 6 months or so to fill it in? These things happen in
> governmental organisations (believe me, I know).

Sure do, and we want to keep support for them.  My proposal maintains
backward compatibilty for by-name surveys, while moving the entire system
to by-ID, without resulting in cases that are, IMO :), quirky: namely,
using the first survey found if multiple matches.

I think we can all agree, however, that we should make the duplicate check
user bound (ie, a natural key of <user name, survey name>).  I'd say we do
that now, and I think that might meet Gurdeep's need, and assuming so, we
can close this ticket and move the by-name action to its own ticket.

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

Comment By: Franky Van Liedekerke (liedekef)
Date: 2010-01-19 19:59

Message:
The thing is, I don't want to stop using the by-name reference just yet.
Suppose you've mailed a survey with a by-name reference to 10.000 persons
and they have 6 months or so to fill it in? These things happen in
governmental organisations (believe me, I know).
For know I believe the first steps to be:
- remove the duplicate check (and change the db to use a survey name-user
combo as unique db constraint)
- for "?name=" syntax use the first survey found (if multiple surveys
match the same name)
- remove as much of by-name references as possible in the admin backend
code (eg. when doing "test" surveys) and replacing by "?id="

In a next step we can further build down by-name reference, by no longer
allowing it at all.

Seems reasonable easy to code up for now...

Franky

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

Comment By: bishop (bishopb)
Date: 2010-01-19 17:02

Message:
Also, if a survey is requested by name, we lookup the ID then throw a 301 -
Moved Permanently header to ensure that we do all that we can to stop using
the by-name reference.

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

Comment By: bishop (bishopb)
Date: 2010-01-19 17:00

Message:
Suppose name uniqueness is dropped in version X.  When upgrading to version
X, we know that all surveys with an ID less than or equal to MAX(Survey.ID)
:= N will have a unique name (as they were created in version < X) and we
can record N for reference.  Then, when we're resolving a name to an ID, we
do eg "SELECT ID FROM Surveys WHERE name=? AND ID < N".  In other words, we
only look for a survey by name for those surveys created in earlier
versions, and we don't care about name uniqueness when given an ID.  In
effect, we're automating the configuration option you suggest and making it
transparent to the end user.

If we remove name uniqueness, what is that going to do to the user
experience?  It'll be possible to create two surveys with the same name, so
then how do they tell which is which at a glance?  Perhaps what we really
want is:
a) Change all references to a survey by ID, per the logic presented above
b) Enforce a natural key of <survey name, creating user>

That way, the software references by ID and can always find a unique
survey, and a person cannot ever create a survey with the same title and
potentially get confused as to which is which.  Thoughts?

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

Comment By: Franky Van Liedekerke (liedekef)
Date: 2010-01-19 15:11

Message:
Bishop, the issue with just removing the duplicate check would result in
problems for people having created current surveys that they mailed out
using "?name=" syntax, and where newly created surveys get the same name.
So maybe my suggestion is the best of all: making the duplicate check
optional by using a configuration option.
Or even better: just removing the duplicate check, and for "?name=" syntax
use the first survey found (if multiple surveys match the same name), but
also removing as much of "?name=" references as possible in the admin
backend code (eg. when doing "test" surveys) and replacing by "?id="
I don't like suggesting names (too much coding for very little result),
and using an ID for a survey that is not yet created is difficult :-)

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

Comment By: bishop (bishopb)
Date: 2010-01-19 14:06

Message:
Another option: always suggest a survey name, allowing the user to override
if desired.  If the override collides, suggest a new one.  For example,
when creating a new survey, the survey name field displays  pre-filled with
"SURVEY_1234" (where 1234 is the next ID) or "SURVEY_bob_19-1-2010" (where
bob is the username and 19-1-2010 is today's date in the locale DMY
format).  If the user clicks on the survey name field, the pre-filled is
erased.

But, Franky, so long as we're talking about getting rid of name
uniqueness, why not just do it?  Existing deployments will not be affected,
as the name is already unique.  New deployments will simply start using ID.
 We always check to see if survey name is given on the URL, and we try to
resolve that to an ID, and if it fails owing to duplicate, we throw an
error indicating as such.

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

Comment By: Franky Van Liedekerke (liedekef)
Date: 2010-01-19 10:14

Message:
Ok, another way of doing it:

take away the uniquess on the database column for survey names and work
with an option that lets you define wether or not the name must be unique.
If the option is "name must be unique" then we give an error if the name
is already in use and you need to choose another one (no autocreation of
another name for now).
If the option is "name must not be unique" then we don't check if the name
is already in use, but you might lose the possibility to refer to surveys
by name (not that much of a limitation) if more than one survey with the
same name exists.

Franky

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

Comment By: Nobody/Anonymous (nobody)
Date: 2010-01-19 09:29

Message:
But  if you as a user have to think about a unique name every time you
create a survey is bit irritating. It directly impacts the usability of
application. 

For an example my application is for academic insitiutions in which
instructors creates surveys and time sheets and send them to students
participating in team projects. Most of the instructors will try to keep
the identical name for their surveys like "timesheet week 1 " or so and as
the number of surveys increases finding a unique name may become a trouble
for them.

Automatically suggesting a name for a survey if that name already exists
is a good idea instead of prepending an ID to all survey names. 


  

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

Comment By: bishop (bishopb)
Date: 2010-01-18 15:06

Message:
> the thing is that people can access a survey by doing "?name=SURVEYNAME"
> in the URL, therefore the survey name needs to be unique. It was like
this
> before I took over the project, so I didn't want to break that
> functionality. So for now the name needs to be always unique.

Agreed -- this should not be touched now.  But I meant to suggest when
we're designing version 3 we should consider whether we need to keep access
by name (natural key) or if access by ID (surrogate key) is just as good. 
My inclination, without having done any diligence in reviewing the code, is
that surrogate key is fine.


> But it shouldn't impact existing surveys in any way, only surveys that
you can edit are impacted, and these are 
> never online. Could you give an example of such a use case?

Sure, suppose I'm a designer, logged into the admin side.  I'm creating a
survey for my first period class and I want to give it a name like
'APPSTATP1' so that it looks something like the subject matter.  With the
new code, I can't have a name like that, because it'll prepend the ID onto
the front, so I can never name a survey something entirely appropriate to
the subject domain.

But suppose that was fixed so that only duplicate survey names get
modified.  Further suppose I had a survey from last year with my desired
name.  (Being a survey that recurs on the same subject matter makes this a
likely case.)  There's a collision, and the patch gives it an automatic
name, like '1321APPSTATP1'.  Suddenly, that name is no longer obvious and
difficult to remember.  In this case, I (as the designer) would prefer to
be told that the survey name isn't unique and that I need to make it
unique, which which case I'd give it a name containing a time signature,
like 'APPSTATP1_2010'.

Instead of actually saving with a new name, can't we throw an error as
now, but recommend a new name, perhaps automatically filling in the survey
name field with the recommended name?  That way, the user can quickly get a
survey with a unique name if he doesn't care about the name particularly,
or he can take corrective action to make a relevant unique name.

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

Comment By: Franky Van Liedekerke (liedekef)
Date: 2010-01-18 10:18

Message:
Hi Bishop,

the thing is that people can access a survey by doing "?name=SURVEYNAME"
in the URL, therefore the survey name needs to be unique. It was like this
before I took over the project, so I didn't want to break that
functionality. So for now the name needs to be always unique.
But it shouldn't impact existing surveys in any way, only surveys that you
can edit are impacted, and these are never online. Could you give an
example of such a use case?

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

Comment By: bishop (bishopb)
Date: 2010-01-18 01:14

Message:
Automatically adding a number, in all cases, will probably break some
existing use cases.  Perhaps:

1. Make this a configuration option: "Do you want to generate a unique
survey name if creating a new one with an existing name?"  Boolean. 
Default = No.
2. If so configured, atomically test for existence and, if already exists,
append the survey ID as in the patch.  If not so configured, fail.

This would keep existing behavior while allowing the new functionality.

Of course, survey ID is already unique, so having the survey name act as a
natural key is redundant.  Moving into the next major version, we might
want to consider whether we need both the surrogate ID and the natural name
keys.

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

Comment By: Gurdeep Singh (gurdeep22)
Date: 2010-01-17 22:57

Message:
Yeah its working. i just checked it , it prepends the survey id to the
survey name and  thus generating unique name every time. 

But  survey Id get prepends to every survey name and not only to those
that have duplicate name . 

 this is a good solution for me. I can move ahead now. 

Thank You very much. 

Gurdeep

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

Comment By: Franky Van Liedekerke (liedekef)
Date: 2010-01-17 22:31

Message:
Ok, I made some changed to admin/include/function/survey_update.inc that
prepends the survey ID if not present, and readding it every time it gets
removed, so the chance of getting a double name is next to zero now. Try
out the updated version (see attachment in this feature request) and see if
it solves the problem for you. If it does, I'll include it in the code with
an extra line explaining where the ID comes from.
Unless some other people don't agree with this?
I didn't want to do it based on the username or userID because that would
disclose user information to the outside world, not a wanted effect.

Franky

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

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