phpesp-devel — Discussion of the development of phpESP

[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-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

[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-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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Seems reasonable easy to code up for now...

Franky

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Message:
Ok, another way of doing it:

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

Franky

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

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

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

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

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


  

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

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

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

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


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

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

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

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

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

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

Message:
Hi Bishop,

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

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

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

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

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

This would keep existing behavior while allowing the new functionality.

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

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

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

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

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

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

Thank You very much. 

Gurdeep

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

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

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

Franky

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

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

[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-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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Message:
Ok, another way of doing it:

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

Franky

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

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

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

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

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


  

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

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

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

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


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

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

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

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

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

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

Message:
Hi Bishop,

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

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

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

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

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

This would keep existing behavior while allowing the new functionality.

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

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

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

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

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

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

Thank You very much. 

Gurdeep

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

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

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

Franky

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Message:
Ok, another way of doing it:

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

Franky

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

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

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

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

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


  

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

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

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

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


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

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

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

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

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

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

Message:
Hi Bishop,

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

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

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

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

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

This would keep existing behavior while allowing the new functionality.

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

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

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

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

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

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

Thank You very much. 

Gurdeep

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

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

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

Franky

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

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

[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-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

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

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

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

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

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

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

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

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

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

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

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

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

Message:
Ok, another way of doing it:

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

Franky

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

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

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

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

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


  

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

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

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

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


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

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

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

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

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

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

Message:
Hi Bishop,

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

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

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

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

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

This would keep existing behavior while allowing the new functionality.

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

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

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

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

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

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

Thank You very much. 

Gurdeep

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

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

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

Franky

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

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

[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-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

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

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

Feature Requests item #2933959, was opened at 2010-01-17 20:32
Message generated for change (Comment added) made by nobody
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: Nobody/Anonymous (nobody)
Date: 2010-01-19 08: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 14: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 09: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 00: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 21: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 21: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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

Message:
Hi Bishop,

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

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

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

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

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

This would keep existing behavior while allowing the new functionality.

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

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

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

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

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

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

Thank You very much. 

Gurdeep

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

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

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

Franky

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

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

[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-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

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

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

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

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

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

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

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

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

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

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

This would keep existing behavior while allowing the new functionality.

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

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

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

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

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

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

Thank You very much. 

Gurdeep

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

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

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

Franky

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

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

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

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

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

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

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

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

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

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

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

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

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

Thank You very much. 

Gurdeep

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

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

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

Franky

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

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

[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-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

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

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

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

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

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

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

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

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

[phpesp-dev] 2.1.4 has been released

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

For all of you to enjoy: 2.1.4 has been released, long overdue if you
ask me :-)

Enjoy and please do post bug reports and such!

Franky

Re: [phpesp-dev] call for release

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

On Mon, 7 Dec 2009 23:26:27 +0100
Franky Van Liedekerke <lie...@te...> wrote:

> Hi all,
> 
> anything that I forgot that somebody would like to see released? I'm
> planning on releasing 2.1.4, which contains a number of small
> bugfixes, but I'm willing to hold back if any real showstoppers are
> announced here.
> 
> Franky
> 

Hi all,

just to let you know: I'm trying to help along somebody with language
issues. I would appreciate it if others tried out the svn-version in
their language as well (eg. the admin part).
Once I have this figured out, I will release the new version. But for
the impatient: you can self-generate a tar.gz version at sourceforgr:
http://phpesp.svn.sourceforge.net/viewvc/phpesp/trunk/phpESP.tar.gz?view=tar

Franky

Re: [phpesp-dev] call for release

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

On Tue, Dec 8, 2009 at 5:49 PM, Matthew Gregg <mat...@gm...>wrote:

> I'd have no problem switching to Github :-)
>
>
> heheh :-) Although a good remark, not a showstopper :-)

Re: [phpesp-dev] call for release

[Matthew G. <mat...@gm...>]

I'd have no problem switching to Github :-)

On Tue, 2009-12-08 at 11:13 -0500, Bishop Bettini wrote:
> Hi Franky,
> 
> I looked through the list of open bugs (priority order), but nothing  
> jumped out at me as being a showstopper.  My vote: cut the release.
> 
> Probably would be a good idea for us to update the priority on the  
> remaining bugs, so that we have a plan for addressing them.  If only  
> sourceforge wasn't so slow... (5 secs b/w clicks is way too long).
> 
> Regards,
> bishop
> 
> Quoting Franky Van Liedekerke <lie...@te...>:
> 
> > Hi all,
> >
> > anything that I forgot that somebody would like to see released? I'm
> > planning on releasing 2.1.4, which contains a number of small
> > bugfixes, but I'm willing to hold back if any real showstoppers are
> > announced here.
> >
> > Franky
> >
> > ------------------------------------------------------------------------------
> > Return on Information:
> > Google Enterprise Search pays you back
> > Get the facts.
> > http://p.sf.net/sfu/google-dev2dev
> > _______________________________________________
> > phpESP-devel mailing list
> > php...@li...
> > https://lists.sourceforge.net/lists/listinfo/phpesp-devel
> >
> 
> 
> 

Re: [phpesp-dev] call for release

[Bishop B. <ph...@id...>]

Hi Franky,

I looked through the list of open bugs (priority order), but nothing  
jumped out at me as being a showstopper.  My vote: cut the release.

Probably would be a good idea for us to update the priority on the  
remaining bugs, so that we have a plan for addressing them.  If only  
sourceforge wasn't so slow... (5 secs b/w clicks is way too long).

Regards,
bishop

Quoting Franky Van Liedekerke <lie...@te...>:

> Hi all,
>
> anything that I forgot that somebody would like to see released? I'm
> planning on releasing 2.1.4, which contains a number of small
> bugfixes, but I'm willing to hold back if any real showstoppers are
> announced here.
>
> Franky
>
> ------------------------------------------------------------------------------
> Return on Information:
> Google Enterprise Search pays you back
> Get the facts.
> http://p.sf.net/sfu/google-dev2dev
> _______________________________________________
> phpESP-devel mailing list
> php...@li...
> https://lists.sourceforge.net/lists/listinfo/phpesp-devel
>



-- 
Bishop Bettini
ideacode, Inc.
(main) +1 919 341 5170 / (fax) +1 919 521 4100

Visit us on the web at:
ideacode.com          Professional software research and development
reviewmysoftware.com  Improve sales! Review your software before you release
bytejar.com           Solutions to those annoying development problems

[phpesp-dev] call for release

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

Hi all,

anything that I forgot that somebody would like to see released? I'm
planning on releasing 2.1.4, which contains a number of small
bugfixes, but I'm willing to hold back if any real showstoppers are
announced here.

Franky

[phpesp-dev] [ phpesp-Bugs-2897990 ] uninitialized GLOBALS array breaks esp_setlocale()

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

Bugs item #2897990, was opened at 2009-11-15 13:34
Message generated for change (Comment added) made by liedekef
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=108956&aid=2897990&group_id=8956

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: User
>Group: svn
>Status: Closed
Resolution: None
Priority: 5
Private: No
Submitted By: Arjen van Bochoven (bochoven)
Assigned to: Nobody/Anonymous (nobody)
Summary: uninitialized GLOBALS array breaks esp_setlocale()

Initial Comment:
On line 94 of php.ini.fixed, a call is made to esp_setlocale_ex() which in turn calls esp_setlocale() (both live in espi18n.inc). 
On line 110, 114 and 115 of espi18n.inc, esp_setlocale() accesses $ESPCONFIG as a global variable, which is not initialized yet.
Initialization of $GLOBALS['ESPCONFIG'] happens at the end of php.ini.fixed, so after the part that references esp_setlocale();

As a quick fix I moved the initialization part above the esp_setlocale() calls. As a consequence, all references to the ESPCONFIG array that come after that have to be changed to $GLOBALS['ESPCONFIG']

here's my changed code for php.ini.fixed starting on line 91 till the end of the file:

if (isset($GLOBALS)) {
    $GLOBALS['ESPCONFIG'] = $ESPCONFIG;
} else {
    global $ESPCONFIG;
}

// Load I18N support
require_once($GLOBALS['ESPCONFIG']['include_path'] . '/lib/espi18n' . $GLOBALS['ESPCONFIG']['extension']);
if (isset($_REQUEST['lang'])) { 
   esp_setlocale_ex($_REQUEST['lang']);
   $_SESSION['language']=$_REQUEST['lang'];
} elseif (isset($lang)) {
   esp_setlocale_ex($lang);
   $_SESSION['language']=$lang;
} elseif (isset($_SESSION['language'])) {
   esp_setlocale_ex($_SESSION['language']);
} else {
   esp_setlocale_ex();
}


// default thank you messages
$GLOBALS['ESPCONFIG']['thank_head'] = _('Thank You For Completing This Survey.');
$GLOBALS['ESPCONFIG']['thank_body'] = _('Please do not use the back button on your browser to go
back.');

if (!file_exists($GLOBALS['ESPCONFIG']['include_path']. '/funcs'. $GLOBALS['ESPCONFIG']['extension'])) {
    printf('<b>'. _('Unable to find the phpESP %s directory.
			Please check %s to ensure that all paths are set correctly.') .
			'</b>', 'include', 'phpESP.ini.php');
    exit;
}
if (!file_exists($GLOBALS['ESPCONFIG']['css_path'])) {
    printf('<b>'. _('Unable to find the phpESP %s directory.
			Please check %s to ensure that all paths are set correctly.') .
			'</b>', 'css', 'phpESP.ini.php');
    exit;
}



require_once($GLOBALS['ESPCONFIG']['include_path'].'/funcs'.$GLOBALS['ESPCONFIG']['extension']);

?>


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

>Comment By: Franky Van Liedekerke (liedekef)
Date: 2009-11-21 15:01

Message:
Agreed, note added in a new readme.txt file in the examples subdir

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

Comment By: Arjen van Bochoven (bochoven)
Date: 2009-11-21 12:11

Message:
Solved: when I declare the following inside the function:

global $ESPCONFIG;

all is fine, my previous hacking of the config files is unnecessary.

Maybe update documentation to state that when the include is done inside a
function, you have to declare the $ESPCONFIG array as global. 

I am including phpESP in a CMS based on CodeIgniter, a MVC framework. In
CI, views (templates) don't exist in global scope so setting global
$ESPCONFIG; fixes the variable problem.

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

Comment By: Arjen van Bochoven (bochoven)
Date: 2009-11-21 12:04

Message:
Moving the phpESP.first.php to the top of the script does not make a
difference, please mind that I am including /public/handler.php inside a
function. This is indeed a matter of scope, variables that are declared
outside the function are not available within it. In your example, if I
replace

<?php
include("/path/phpESP/public/handler.php");
?>

with

<?php
function survey(){include("/path/phpESP/public/handler.php");}
survey();
?>

I get these messages:

Notice: Undefined variable: ESPCONFIG in /path/phpESP/public/handler.php
on line 26
Notice: Undefined variable: ESPCONFIG in /path/phpESP/public/handler.php
on line 26
Warning: require_once(/funcs) [function.require-once]: failed to open
stream: No such file or directory in /path/phpESP/public/handler.php on
line 26



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

Comment By: Franky Van Liedekerke (liedekef)
Date: 2009-11-18 22:35

Message:
Look at the comments in the examples php files: the include of
public/phpESP.first.php needs to happen BEFORE any output begins (reason:
session initialization etc)
Try this:

<?php
ini_set( 'display_errors', true );
error_reporting(E_ALL);
$lang='nl_NL';
$sid=9;
include("/home/bochoven/php/phpESP/public/phpESP.first.php");
?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8"/>

<title>survey</title>

</head>

<body>

<?php
include("/home/bochoven/php/phpESP/public/handler.php");
?>

</body>
</html>

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

Comment By: Franky Van Liedekerke (liedekef)
Date: 2009-11-18 22:16

Message:
I found this one weird, so I took a deeper look at it. First of all: I
don't like the use of global variables, but that put aside, I believe this
remark to be wrong:
in php, using "global <variablename>", refers to the value of the variable
outside the function, see
http://php.net/manual/en/language.variables.scope.php (example 2).
Using $GLOBALS should be removed as much as possible, but I didn't get
around to doing that (yet), but still it doesn't change the fact that it
remains the same.
What did you see as an error when you claim that "uninitialized GLOBALS
array breaks esp_setlocale()"?

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

Comment By: Arjen van Bochoven (bochoven)
Date: 2009-11-15 20:28

Message:
Hmm, further investigation showed that this problem only arises when you
don't include the handler.php in global space (eg in a function or a
class). I would still want to flag this as a bug. Example code below:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
	"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
	<meta http-equiv="Content-Type" content="text/html; charset=utf-8"/>

	<title>survey</title>
	
</head>

<body>
	
	<?php 
	
	ini_set( 'display_errors', true );
	error_reporting(E_ALL);
	
	function survey()
	{
		$lang='nl_NL';
		$sid=9;
		include("/home/bochoven/php/phpESP/public/phpESP.first.php");
		include("/home/bochoven/php/phpESP/public/handler.php");
	}
	
	survey();
		
	?>

</body>
</html>

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

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

[phpesp-dev] [ phpesp-Bugs-2901695 ] localization espauth-default.inc

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

Bugs item #2901695, was opened at 2009-11-21 12:26
Message generated for change (Comment added) made by liedekef
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=108956&aid=2901695&group_id=8956

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: User
Group: cvs
>Status: Closed
>Resolution: Accepted
Priority: 5
Private: No
Submitted By: Arjen van Bochoven (bochoven)
Assigned to: Nobody/Anonymous (nobody)
Summary: localization espauth-default.inc

Initial Comment:
I found three non-localized error messages in espauth-default.inc:

line 101
                $error_message = "Incorrect User ID or Password, or your account has been disabled/expired.";
should read
                $error_message = _('Incorrect User ID or Password, or your account has been disabled/expired.');

line 138
                $error_message = "Your account has been disabled or you have already completed this survey.";
should read
                $error_message = _('Your account has been disabled or you have already completed this survey.');

line 223
                $error_message = "Incorrect User ID or Password, or your account has been disabled/expired.";
should read
                $error_message = _('Incorrect User ID or Password, or your account has been disabled/expired.');


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

Comment By: Franky Van Liedekerke (liedekef)
Date: 2009-11-21 14:44

Message:
The latest development code contains the fix, please update to the
development code or wait for an official release.

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

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

[phpesp-dev] [ phpesp-Bugs-2901695 ] localization espauth-default.inc

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

Bugs item #2901695, was opened at 2009-11-21 12:26
Message generated for change (Tracker Item Submitted) made by bochoven
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=108956&aid=2901695&group_id=8956

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: User
Group: cvs
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Arjen van Bochoven (bochoven)
Assigned to: Nobody/Anonymous (nobody)
Summary: localization espauth-default.inc

Initial Comment:
I found three non-localized error messages in espauth-default.inc:

line 101
                $error_message = "Incorrect User ID or Password, or your account has been disabled/expired.";
should read
                $error_message = _('Incorrect User ID or Password, or your account has been disabled/expired.');

line 138
                $error_message = "Your account has been disabled or you have already completed this survey.";
should read
                $error_message = _('Your account has been disabled or you have already completed this survey.');

line 223
                $error_message = "Incorrect User ID or Password, or your account has been disabled/expired.";
should read
                $error_message = _('Incorrect User ID or Password, or your account has been disabled/expired.');


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

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