phpesp-devel — Discussion of the development of phpESP

[phpesp-dev] true or false: responses can be recovered if the survey is blown away?

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

All,

I have a question about the phpESP underlying design: if you delete a =20
survey to which a response points, can you still recover the answers =20
given in the response?  For example, say you have this:

mysql> select id,survey_id,complete from response;
+----+-----------+----------+
| id | survey_id | complete |
+----+-----------+----------+
|  7 |        18 | Y        |
|  6 |        18 | Y        |
|  8 |        18 | Y        |
|  9 |        18 | Y        |
| 10 |        18 | Y        |
| 11 |        17 | N        |
| 13 |        20 | N        |
| 14 |        21 | Y        |
+----+-----------+----------+

and then you do this:
delete from survey where id=3D18


Can you get the responses made for response ids 6, 7, 8, 9, and 10?  =20
If so, is there a convenient function to get those responses as an =20
array/object?

Thanks!
bishop

--=20
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] [ phpesp-Patches-1875891 ] UTF-8 in survey.php

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

Patches item #1875891, was opened at 2008-01-20 19:42
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=308956&aid=1875891&group_id=8956

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

Initial Comment:
It's great that everything is handled in UTF-8, but when it comes to actually displaying a survey, suddenly the charset isn't UTF-8 anymore.
I have a short diff, which fixes the problem. 
For the future: maybe think of a common header to include in all files, so that changes take effect on all pages.

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

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

Re: [phpesp-dev] proposal: announcements on the dashboard

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

Yes, announcements would be global, because it's not possible to know =20
a priori what realm a user is in until after authentication.  Per =20
realm "announcements" currently go on the realm-specific surveys, I'd =20
imagine.

Types of announcements include:
* service notifications - "Due to maintenance, the survey system will =20
be down..."
* welcome information - "If you are new to the site, please take a =20
moment to read the help guide..."

etc.

Thoughts?
bishop

Quoting Matthew Gregg <mat...@gm...>:

> Announcements would be global?  All users logging into the dashboard get
> the same announcement?
>
> On Fri, 2008-01-18 at 14:11 -0500, Bishop Bettini wrote:
>> All,
>>
>> I propose to add the following: When the dashboard is enabled (in the
>> configuration file), a new menu item appears on the administrative
>> list.  This menu item would be titled something like "Set log in
>> announcements".  This item takes you to a page where you can view the
>> current, or alter, the announcements shown on the login page.  The
>> announcements will be simple text, accepting HTML, that will appear on
>> the dashboard page.  CSS can be used to control placement, color, etc.
>>
>> Thoughts?
>> bishop
>>
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> phpESP-devel mailing list
> php...@li...
> https://lists.sourceforge.net/lists/listinfo/phpesp-devel
>



--=20
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

Re: [phpesp-dev] proposal: announcements on the dashboard

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

Announcements would be global?  All users logging into the dashboard get
the same announcement?

On Fri, 2008-01-18 at 14:11 -0500, Bishop Bettini wrote:
> All,
> 
> I propose to add the following: When the dashboard is enabled (in the  
> configuration file), a new menu item appears on the administrative  
> list.  This menu item would be titled something like "Set log in  
> announcements".  This item takes you to a page where you can view the  
> current, or alter, the announcements shown on the login page.  The  
> announcements will be simple text, accepting HTML, that will appear on  
> the dashboard page.  CSS can be used to control placement, color, etc.
> 
> Thoughts?
> bishop
> 

[phpesp-dev] proposal: announcements on the dashboard

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

All,

I propose to add the following: When the dashboard is enabled (in the  
configuration file), a new menu item appears on the administrative  
list.  This menu item would be titled something like "Set log in  
announcements".  This item takes you to a page where you can view the  
current, or alter, the announcements shown on the login page.  The  
announcements will be simple text, accepting HTML, that will appear on  
the dashboard page.  CSS can be used to control placement, color, etc.

Thoughts?
bishop

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

Re: [phpesp-dev] concerning post "true or false: phpESP *requires* MySQL?"

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

I'd probably not want to strengthen that statement yet.
On Wed, 2008-01-16 at 17:56 -0500, Bishop Bettini wrote:
> Ok, then I would suggest strengthening the FAQ on this point.   
> Currently reads:
> 
> Q: Does phpESP support databases other than MySQL?
> A: As of version 1.7 database abstraction has been implemented using  
> the ADOdb library. MySQL is the most fully tested, Postgres has not  
> been fully tested and SQLite has some known issues. We would welcome  
> help makeing Postgres and SQLite support as strong as MySQL.
> 
> which doesn't give warm fuzzies for those running PostgreSQL or SQLite. :)
> 
> bishop
> 
> 
> Quoting Franky Van Liedekerke <lie...@te...>:
> 
> > The answer for now should be "yes", as the update/create scripts
> > haven't been touched in quite a while. But in theory, if somebody fixes
> > these, the answer is again "no".
> >
> > Franky
> >
> > -------------------------------------------------------------------------
> > This SF.net email is sponsored by: Microsoft
> > Defy all challenges. Microsoft(R) Visual Studio 2008.
> > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> > _______________________________________________
> > phpESP-devel mailing list
> > php...@li...
> > https://lists.sourceforge.net/lists/listinfo/phpesp-devel
> >
> 
> 
> 

Re: [phpesp-dev] Concerning post "survey availability constrained by date"

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

Sounds good -- code's almost done, too.  Existing surveys will pass =20
right through the date checks (because their corresponding survey =20
entries don't have date values set) and new surveys that set the dates =20
will get appropriately controlled.

bishop

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

> This sounds also great to me. I already thought about this one, but
> never got around to code it, so Bishop: be my guest :) As long as it
> doesn't affect current surveys, it sounds great.
>
> Franky
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> phpESP-devel mailing list
> php...@li...
> https://lists.sourceforge.net/lists/listinfo/phpesp-devel
>



--=20
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

Re: [phpesp-dev] concerning post "true or false: phpESP *requires* MySQL?"

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

Ok, then I would suggest strengthening the FAQ on this point.  =20
Currently reads:

Q: Does phpESP support databases other than MySQL?
A: As of version 1.7 database abstraction has been implemented using =20
the ADOdb library. MySQL is the most fully tested, Postgres has not =20
been fully tested and SQLite has some known issues. We would welcome =20
help makeing Postgres and SQLite support as strong as MySQL.

which doesn't give warm fuzzies for those running PostgreSQL or SQLite. :)

bishop


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

> The answer for now should be "yes", as the update/create scripts
> haven't been touched in quite a while. But in theory, if somebody fixes
> these, the answer is again "no".
>
> Franky
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> phpESP-devel mailing list
> php...@li...
> https://lists.sourceforge.net/lists/listinfo/phpesp-devel
>



--=20
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] SVN email hooks

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

If anyone else wants email notifications for SVN commits let me know and
I'll add you to the list.

Re: [phpesp-dev] patches

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

I've committed all the patches to SVN trunk.
On Wed, 2008-01-16 at 23:36 +0100, Franky Van Liedekerke wrote:
> Hi Bishop,
> 
> I see you've created quite some patches. Could you resubmit these to
> the patch forum, so I can look at these too? I just realized I never
> submitted to the phpesp-devel list, so I missed these and the
> attachment is not available online in the mail archive.
> 
> Franky
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> phpESP-devel mailing list
> php...@li...
> https://lists.sourceforge.net/lists/listinfo/phpesp-devel

Re: [phpesp-dev] Concerning post "ip column addition missing from 1.8.2 to 2.0.2 database upgrade"

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

Hi Franky,

Indeed it was a 1.8.2 install, created from the tarball on butterfat =20
and after running the mysql create and populate scripts.

In that installation, there is no reference to ip column:
$ ls -l scripts/db/
total 44
-rw-r--r-- 1 ideacode.com apache  148 Mar  8  2005 mysql4.x_upgrade.sql
-rw-r--r-- 1 ideacode.com apache 1398 Feb 27  2003 mysql_create.sql
-rw-r--r-- 1 ideacode.com apache 8246 Mar 29  2006 mysql_populate.sql
-rw-r--r-- 1 ideacode.com apache 1073 Feb 27  2003 mysql_update-1.5-1.6.sql
-rw-r--r-- 1 ideacode.com apache 9870 Apr 30  2004 postgres_populate.sql
-rw-r--r-- 1 ideacode.com apache 6852 Apr 30  2004 sqlite_populate.sql
$ grep -i 'ip.*char' scripts/db/*sql
$

But in the latest code, the ip column is mentioned three times:
# ls -l scripts/db/*sql
-rw-r--r-- 1 root root  272 Jan  9 14:43 scripts/db/mysql4.x_upgrade.sql
-rw-r--r-- 1 root root 1398 Jan  9 12:57 scripts/db/mysql_create.sql
-rw-r--r-- 1 root root 8596 Jan  9 14:43 scripts/db/mysql_populate.sql
-rw-r--r-- 1 root root 1119 Jan  9 14:43 scripts/db/mysql_update-1.5-1.6.sql
-rw-r--r-- 1 root root  610 Jan  9 14:43 =20
scripts/db/mysql_update-1.8.2h-1.8.2i.sql
-rw-r--r-- 1 root root  983 Jan  9 14:43 =20
scripts/db/mysql_update-1.8.2k-2.0.0.sql
-rw-r--r-- 1 root root 1050 Jan 16 11:02 =20
scripts/db/mysql_update-2.0.2-2.0.3.sql
-rw-r--r-- 1 root root 9870 Jan  9 14:43 scripts/db/postgres_populate.sql
-rw-r--r-- 1 root root 6852 Jan  9 14:43 scripts/db/sqlite_populate.sql
# grep -i 'ip.*char' scripts/db/*sql
scripts/db/mysql4.x_upgrade.sql:ALTER TABLE `response` ADD COLUMN ip CHAR(64=
);
scripts/db/mysql_populate.sql:  ip              CHAR(64),
scripts/db/mysql_update-1.5-1.6.sql:ALTER TABLE response   ADD COLUMN =20
ip CHAR(64);
#

So... that tells me the ip column was added to the 1.5-1.6 file AFTER =20
releasing the 1.8.2 tarball on butterfat.

bishop

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

> Hi Bishop,
>
> this statement:
>
> ALTER TABLE response   ADD COLUMN ip CHAR(64);
>
> was already in the mysql_update-1.5-1.6.sql file ... I wonder if your
> install really was 1.8.2?
> Or maybe the create script didn't include this column for 1.8.2 and
> decided not to use it then, but I can't say that for sure, that's way
> too long in the past for me and before I started changing it. It
> somebody can confirm this, I'll add this line to the upgrade file.
>
> Franky
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> phpESP-devel mailing list
> php...@li...
> https://lists.sourceforge.net/lists/listinfo/phpesp-devel
>



--=20
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

Re: [phpesp-dev] Concerning post "ip column addition missing from 1.8.2 to 2.0.2 database upgrade"

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

Yup it is, but if he was running a 1.8 version created using a 1.8
mysql_populate script he would have never ran mysql_update-1.5-1.6.sql.
The IP field was added in mysql_populate in revision 918, but not added
to the 1.8.2.x upgrade scripts. So he would have missed getting an IP
field added.   I have added the IP field to the update scripts in SVN.
On Wed, 2008-01-16 at 23:23 +0100, Franky Van Liedekerke wrote:
> Hi Bishop,
> 
> this statement:
> 
> ALTER TABLE response   ADD COLUMN ip CHAR(64);
> 
> was already in the mysql_update-1.5-1.6.sql file ... I wonder if your
> install really was 1.8.2?
> Or maybe the create script didn't include this column for 1.8.2 and
> decided not to use it then, but I can't say that for sure, that's way
> too long in the past for me and before I started changing it. It
> somebody can confirm this, I'll add this line to the upgrade file.
> 
> Franky
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> phpESP-devel mailing list
> php...@li...
> https://lists.sourceforge.net/lists/listinfo/phpesp-devel

[phpesp-dev] Concerning post "survey availability constrained by date"

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

This sounds also great to me. I already thought about this one, but
never got around to code it, so Bishop: be my guest :) As long as it
doesn't affect current surveys, it sounds great.

Franky

[phpesp-dev] patches

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

Hi Bishop,

I see you've created quite some patches. Could you resubmit these to
the patch forum, so I can look at these too? I just realized I never
submitted to the phpesp-devel list, so I missed these and the
attachment is not available online in the mail archive.

Franky

[phpesp-dev] [ phpesp-Bugs-1870884 ] Greg, pls explain fix

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

Bugs item #1870884, was opened at 2008-01-14 07:13
Message generated for change (Comment added) made by liedekef
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=108956&aid=1870884&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: Admin
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Greg, pls explain fix

Initial Comment:
I'm just a cookbook novice trying to set up a survey.  You answered this problem for someone else but I don't know enough to understand your fix.  Can you elaborate or point me to any other documentation?
Thanks,
Rick Perkins
ri...@ad...


Fatal error: Call to a member function on a non-object in /espdatalib.inc on line 124


Date: 2005-08-08 07:26
Sender: greggmcProject AdminAccepting Donations
Logged In: YES 
user_id=14116

Proper fix for this is to check for and init adodb in
handler.php and handler-prefix.php.  I've commited this to CVS.

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

>Comment By: Franky Van Liedekerke (liedekef)
Date: 2008-01-16 23:35

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

Well the answer is easy: update to 2.0.2 and it should be fixed. Examples
can be found in the example subdir ...

Franky

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

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

[phpesp-dev] concerning post "true or false: phpESP *requires* MySQL?"

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

The answer for now should be "yes", as the update/create scripts
haven't been touched in quite a while. But in theory, if somebody fixes
these, the answer is again "no".

Franky

[phpesp-dev] Concerning post "ip column addition missing from 1.8.2 to 2.0.2 database upgrade"

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

Hi Bishop,

this statement:

ALTER TABLE response   ADD COLUMN ip CHAR(64);

was already in the mysql_update-1.5-1.6.sql file ... I wonder if your
install really was 1.8.2?
Or maybe the create script didn't include this column for 1.8.2 and
decided not to use it then, but I can't say that for sure, that's way
too long in the past for me and before I started changing it. It
somebody can confirm this, I'll add this line to the upgrade file.

Franky

[phpesp-dev] respondents, log in, and knowledge of the realm

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

Comments follow below (trail included for reference):

Quoting Bishop Bettini <ph...@id...>:

mg>> Sounds good except for username,password uniqueness.  Currently the way
mg>> users are assigned to multiple realms is that they will have 2 entries
mg>> with the same userid/password different realms(yes that is ugly, don't
mg>> blame me for that :-)).
bb>
bb> Yeah, the <username,realm>, instead of just <username>, uniqueness
bb> issue really gets me.
bb>
bb> Is the purpose of the realm to host multiple different survey groups
bb> with the same code base?  That's my intuition, based on the code: the
bb> division of css especially alludes to that.
bb>
bb> If so, can't we just enforce a <username, password, realm> uniqueness?
bb>  We could implement that transparently (to the user) by salting the
bb> password with the realm.  In fact, it would be quite easy to implement
bb> as there's already that password_upgrade() function that all
bb> authentication goes through -- we just hook into that.

Earlier, I suggested that salting the password with the realm would =20
make <username,password> unique, and while that is true, it doesn't =20
solve the problem.

To use the dashboard, the user provides his username and password.  =20
But, a given <username,password> can match multiple respondents, all =20
in different realms.  If you don't know the realm, you don't know =20
which user has just logged in, which means you can't show a guaranteed =20
list of surveys unique to that user.

Salting the password with the realm won't help because you still don't =20
know what realm this user is in.

I think this username uniqueness issue is not only a problem with the =20
dashboard, but also with existing code.  I'm new here, so I may be way =20
off, so tag me if I'm off base:

FACTS:
1. A survey can have multiple realms accessing it (table=3Daccess)
2. Two respondents can have the same username and password, but =20
different realms (table=3Drespondent)
3. A response has a survey and a username (table=3Dresponse)


SCENARIO:
Suppose you have two respondents:
Username Password Realm
Joe      test     Foo
Joe      test     Bar

And one private survey with two realms accessing it:
Survey    Realm
MySurvey  Foo
MySurvey  bar

Now, Joe (in Foo) hits public/survey.php?name=3DMySurvey and completes =20
the survey.


PROBLEM:
Which Joe answered MySurvey?!?  This is what goes into response:

   Survey   Username
   MySurvey Joe

You can't know which Joe that is, because response presumes that =20
<username, survey_id> is unique, which isn't the case (because a =20
username isn't unique within a survey because a survey *can have more =20
than one realm*).

In fact, what occurs is that what applies for one applies for all: if =20
there's a max response of one, then Joe Foo's answer counts as the max =20
response, so when Joe Bar tries to respond, he gets:

[ Your account has been disabled or you have already completed this survey. =
]

Which occurs precisely because response can't tell the Joe's apart.


SOLUTION:
Either realm has to be added to response, so that the <username,realm> =20
key is unique, or <username> has to be unique.

Option #1, for existing deployments, requires back filling realm into =20
response, but that will fail if any survey grants access to more than =20
one realm that share a username (unless maxresponse happens to be 1 =20
for all surveys in question, then you can know which realm it is).

Option #2, for existing deployments, will require making usernames =20
unique, which can't currently be done from UI (because you can't =20
change a username once created, presumably to avoid changing history).


If I'm reading the code right, and that scenario is right, then there =20
is a bug in the data relationships of existing deployments that should =20
be fixed.  Do we have any idea of how many deployments are sharing =20
usernames across realms?  How many users does this affect?

I would just like to make require username uniqueness moving forward.  =20
That solves the dashboard problem and this bug henceforth.  Thoughts?

bishop

--=20
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

Re: [phpesp-dev] proposal: survey availability constrained by date

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

Sounds great to me.

On Tue, 2008-01-15 at 17:22 -0500, Bishop Bettini wrote:
> All,
> 
> I have a client need to constrain a survey's availability to a given  
> window of time.  In other words, survey 1 is available between dates X  
> and Y only: not before X and not after Y.
> 
> I propose to add an optional opening_date and closing_date column to  
> survey, as well as input elements on the General tab of the survey  
> create/edit page.  The survey logic would alter, as follows:
> 
> A survey is available if and only if:
>   a) the existing access control logic is satisfied, and
>   b) one of the following conditions:
>      If opening and closing are set && opening <= now <= closing
>      If opening set and closing is not set && opening <= now
>      If opening not set and closing is set && now <= closing
>      If opening not set and closing not set
> 
> I would also add a data element to the tables on the dashboard, so a  
> respondent can see the temporal availability.  I'd also need to update  
> the error messages appropriately.  And the help documentation.
> 
> With this addition, no existing data will be affected.  Those who wish  
> to constrain to a given date range may.
> 
> Thoughts?
> 
> bishop
> 

[phpesp-dev] proposal: survey availability constrained by date

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

All,

I have a client need to constrain a survey's availability to a given =20
window of time.  In other words, survey 1 is available between dates X =20
and Y only: not before X and not after Y.

I propose to add an optional opening_date and closing_date column to =20
survey, as well as input elements on the General tab of the survey =20
create/edit page.  The survey logic would alter, as follows:

A survey is available if and only if:
  a) the existing access control logic is satisfied, and
  b) one of the following conditions:
     If opening and closing are set && opening <=3D now <=3D closing
     If opening set and closing is not set && opening <=3D now
     If opening not set and closing is set && now <=3D closing
     If opening not set and closing not set

I would also add a data element to the tables on the dashboard, so a =20
respondent can see the temporal availability.  I'd also need to update =20
the error messages appropriately.  And the help documentation.

With this addition, no existing data will be affected.  Those who wish =20
to constrain to a given date range may.

Thoughts?

bishop

--=20
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] patch: respondent dashboard (formerly "landing page")

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

All,

I have assembled my final patch to support a user "dashboard" page (a =20
respondent's portal to his surveys).  The patch is too large to send =20
to the list.  To access the patch, visit: =20
http://bishop.ideacode.com/~bishop/staging/issue920.tgz

(To apply, untar/ungzip it, patch -p1 < issue920.patch.diff then copy =20
the public/help/*png files to public/help and commit)

The use of this dashboard is explained in the built-in help.  The =20
configuration options are explained in the configuration file.  Here =20
is the brief:

First, an administrator configures whether he wants to use the =20
dashboard at all.  Default is OFF, to remain compatible with previous =20
versions.  Once enabled, a user gets to the dashboard by either =20
hitting public/dashboard.php directly or by hitting public/survey.php =20
without a survey name.

Once at the dashboard, the user has three choices: log in, view the =20
help documentation, or (optionally) see a list of public surveys.  The =20
administrator decides whether or not to engage the list of public =20
surveys via the configuration file.  The default is OFF.

Once logged in, the user sees three panels: my surveys, my history, my =20
tools.  My Surveys lists all surveys the respondent can currently =20
take, using the same logic found elsewhere in the system.  The title, =20
status, and last activity date are shown in a table.  My History lists =20
all surveys the respondent has had access to, but does no longer -- in =20
other words, the surveys that have moved from active to done.  My =20
Tools allows the user to get help, log out, change their profile, =20
change their password, or email help.  The availability of the last =20
three in that list are administrator controlled, via the ini file.


OPEN ISSUE
There is one open issue, and that is with the current =20
<username,password> situation.  This code throws a friendly error to =20
the user in the case where the entered username and password is =20
non-unique.  I will be working on a patch next that will make =20
<username,password> unique by salting the password with the realm.



Please let me know if you have any questions.

bishop

--=20
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

Re: [phpesp-dev] preliminary patch: respondent landing page

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

Quoting Matthew Gregg <mat...@gm...>:

> Thinking more about this...
> On Mon, 2008-01-14 at 20:39 -0500, Bishop Bettini wrote:
>> All,
>>
>> Attached is a preliminary patch to support a "landing page" for
>> respondents.  Here's how it works:  If use_landing =3D true in
>> configuration, then public/landing.php opens up.  That pages shows a
>> login box and any public surveys available in the system.
> I don't like showing all public surveys, since in the general case most
> surveys are "public" but hidden by the fact that the survey name is not
> known. Why can't this page only be accessed after successfully
> authenticating, then show only the info you talk about below?

I think it depends upon use case: some will not want to show all =20
public, while others will want to show them.  Since it can be easily =20
driven by a configuration option, I'll add that in.  Thoughts?

bishop

--=20
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

Re: [phpesp-dev] preliminary patch: respondent landing page

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

On Tue, 2008-01-15 at 08:17 -0500, Bishop Bettini wrote: 
> 
> We could just salt the password with the realm, making the <username,  
> password, realm> tuple unique and bingo, problem solved.
> 
I think this is the way to go, as long as it's done in a way that
doesn't effect existing data.
> 
> > Does this patch build on the previous patches you've sent?  I hope to
> > have time tomorrow to work on reviewing them.
> 
> Unfortunately, yes.  I'm doing all my patching to phpESP (that's  
> separate from client-specific coding) on a single branch, so I'm  
> building on the previous patches.  In this case, there's some overlap  
> in support files.
> 
> 
> Let me know about the salt approach.
> 
> bishop
> 
> > On Mon, 2008-01-14 at 20:39 -0500, Bishop Bettini wrote:
> >> All,
> >>
> >> Attached is a preliminary patch to support a "landing page" for
> >> respondents.  Here's how it works:  If use_landing = true in
> >> configuration, then public/landing.php opens up.  That pages shows a
> >> login box and any public surveys available in the system.
> >>
> >> A respondent enters their username and password, and if valid, goes to
> >> the landing page.  The landing page has three sections.  The first
> >> section lists the surveys the respondent can currently complete (based
> >> on the same availability logic found elsewhere in the app).  The
> >> second section lists the surveys the respondent has had access to, but
> >> does no longer.  For example, surveys that have moved to "done"
> >> status.  The third section are "tools", where the respondent can
> >> change their password, change their profile, get help, or log out.
> >>
> >> I am not quite done with this.  I need to test a little more,
> >> especially the LDAP part.  If anyone already has an LDAP environment
> >> configured, I'd appreciate a test of this against your server.  I also
> >> need to fill out the help pages.  Any review you can provide would be
> >> appreciated.
> >>
> >> I hope to have this patch finished in the next 24 hours.
> >>
> >> Based on how the system is set up, there is one caveat to using the
> >> landing page: <username,password> tuples must be unique throughout the
> >> system.  Currently, the database says <username,realm> is unique, so
> >> when entering a <username,password>, it's possible that the same
> >> username in two different realms has the same password, in which case,
> >> it's impossible to tell which user is which.  Right now, if the system
> >> detects that case, the user is not allowed to log in.
> >>
> >>
> >> Thoughts?
> >>
> >> bishop
> >>
> >> -------------------------------------------------------------------------
> >> Check out the new SourceForge.net Marketplace.
> >> It's the best place to buy or sell services for
> >> just about anything Open Source.
> >> http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
> >> _______________________________________________ phpESP-devel   
> >> mailing list php...@li...   
> >> https://lists.sourceforge.net/lists/listinfo/phpesp-devel
> >
> >
> > -------------------------------------------------------------------------
> > Check out the new SourceForge.net Marketplace.
> > It's the best place to buy or sell services for
> > just about anything Open Source.
> > http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
> > _______________________________________________
> > phpESP-devel mailing list
> > php...@li...
> > https://lists.sourceforge.net/lists/listinfo/phpesp-devel
> >
> 
> 
> 

Re: [phpesp-dev] preliminary patch: respondent landing page

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

Thinking more about this...
On Mon, 2008-01-14 at 20:39 -0500, Bishop Bettini wrote:
> All,
> 
> Attached is a preliminary patch to support a "landing page" for  
> respondents.  Here's how it works:  If use_landing = true in  
> configuration, then public/landing.php opens up.  That pages shows a  
> login box and any public surveys available in the system.
I don't like showing all public surveys, since in the general case most
surveys are "public" but hidden by the fact that the survey name is not
known. Why can't this page only be accessed after successfully
authenticating, then show only the info you talk about below?
> 
> A respondent enters their username and password, and if valid, goes to  
> the landing page.  The landing page has three sections.  The first  
> section lists the surveys the respondent can currently complete (based  
> on the same availability logic found elsewhere in the app).  The  
> second section lists the surveys the respondent has had access to, but  
> does no longer.  For example, surveys that have moved to "done"  
> status.  The third section are "tools", where the respondent can  
> change their password, change their profile, get help, or log out.
> 
> Thoughts?
> 
> bishop
> 
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
> _______________________________________________ phpESP-devel mailing list php...@li... https://lists.sourceforge.net/lists/listinfo/phpesp-devel

Re: [phpesp-dev] preliminary patch: respondent landing page

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

Hi Matthew,

Quoting Matthew Gregg <mat...@gm...>:

> Sounds good except for username,password uniqueness.  Currently the way
> users are assigned to multiple realms is that they will have 2 entries
> with the same userid/password different realms(yes that is ugly, don't
> blame me for that :-)).

Yeah, the <username,realm>, instead of just <username>, uniqueness =20
issue really gets me.

Is the purpose of the realm to host multiple different survey groups =20
with the same code base?  That's my intuition, based on the code: the =20
division of css especially alludes to that.

If so, can't we just enforce a <username, password, realm> uniqueness? =20
  We could implement that transparently (to the user) by salting the =20
password with the realm.  In fact, it would be quite easy to implement =20
as there's already that password_upgrade() function that all =20
authentication goes through -- we just hook into that.


> Why not require that all the surveys on the landing page be in the same
> realm as the user logging in?

I can require that, certainly.  But, I need to know which realm to use =20
in the first place.  Does the user specify the realm from a drop-down =20
(like Windows domains)?  Or is the realm part of the system =20
configuration (like Kerberos)?

Neither one of those sounded good to me: one forces the user to make a =20
choice (bad), the other relies on an admin to do something right (less =20
bad, but still not optimal).

We could just salt the password with the realm, making the <username, =20
password, realm> tuple unique and bingo, problem solved.


> Does this patch build on the previous patches you've sent?  I hope to
> have time tomorrow to work on reviewing them.

Unfortunately, yes.  I'm doing all my patching to phpESP (that's =20
separate from client-specific coding) on a single branch, so I'm =20
building on the previous patches.  In this case, there's some overlap =20
in support files.


Let me know about the salt approach.

bishop

> On Mon, 2008-01-14 at 20:39 -0500, Bishop Bettini wrote:
>> All,
>>
>> Attached is a preliminary patch to support a "landing page" for
>> respondents.  Here's how it works:  If use_landing =3D true in
>> configuration, then public/landing.php opens up.  That pages shows a
>> login box and any public surveys available in the system.
>>
>> A respondent enters their username and password, and if valid, goes to
>> the landing page.  The landing page has three sections.  The first
>> section lists the surveys the respondent can currently complete (based
>> on the same availability logic found elsewhere in the app).  The
>> second section lists the surveys the respondent has had access to, but
>> does no longer.  For example, surveys that have moved to "done"
>> status.  The third section are "tools", where the respondent can
>> change their password, change their profile, get help, or log out.
>>
>> I am not quite done with this.  I need to test a little more,
>> especially the LDAP part.  If anyone already has an LDAP environment
>> configured, I'd appreciate a test of this against your server.  I also
>> need to fill out the help pages.  Any review you can provide would be
>> appreciated.
>>
>> I hope to have this patch finished in the next 24 hours.
>>
>> Based on how the system is set up, there is one caveat to using the
>> landing page: <username,password> tuples must be unique throughout the
>> system.  Currently, the database says <username,realm> is unique, so
>> when entering a <username,password>, it's possible that the same
>> username in two different realms has the same password, in which case,
>> it's impossible to tell which user is which.  Right now, if the system
>> detects that case, the user is not allowed to log in.
>>
>>
>> Thoughts?
>>
>> bishop
>>
>> -------------------------------------------------------------------------
>> Check out the new SourceForge.net Marketplace.
>> It's the best place to buy or sell services for
>> just about anything Open Source.
>> http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketpl=
ace
>> _______________________________________________ phpESP-devel  =20
>> mailing list php...@li...  =20
>> https://lists.sourceforge.net/lists/listinfo/phpesp-devel
>
>
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketpla=
ce
> _______________________________________________
> phpESP-devel mailing list
> php...@li...
> https://lists.sourceforge.net/lists/listinfo/phpesp-devel
>



--=20
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