phpesp-devel

[phpesp-dev] Bulk upload patch

[Matthew G. <gr...@mu...>]

Attached is a tar containing a patch that implements bulk uploading
of Respondent/Designer accounts and a readme that explains it's
usage/limitations

Please try it out and report any bugs or general code lameness you
find.

Thanks.


-- 
one of the friendly folks in the IT Lab.
--------------------------------------\
The IT Lab (http://www.itlab.musc.edu) \____________________
Probably the world's premier software development center.
Serving: Programming, Tools, Ice Cream, Seminars

Re: [phpesp-dev] Bulk upload patch

[Kon A. <ang...@ip...>]

Hey Matthew,

	Had a quick look at your patch and it looks really good.
	Excellent Job.
	I've just finished patching my version of phpESP and will start testing it 
asap.
	I'll get back to you soon.


Kon

On Thu, 18 Jul 2002 08:07, Matthew Gregg wrote:
> Attached is a tar containing a patch that implements bulk uploading
> of Respondent/Designer accounts and a readme that explains it's
> usage/limitations
>
> Please try it out and report any bugs or general code lameness you
> find.
>
> Thanks.

Re: [phpesp-dev] Bulk upload patch

[Kon A. <ang...@ip...>]

Matthew,

I've finished testing your patch and I've found the following bugs:
1. Bulk Importing Respondent Details:
	I tested this functionality with a correct list of respondents and it worked 
well. I then changed the realm to a non existent one and as expected, it 
displayed the table with the failed uploaded rows.
I then removed the email address from some of the respondents and it accepted 
them without a problem. (should this be the case?).
I them also removed the disabled field from some of the respondents and it 
also accepted them without reporting any errors ( i don't think that this 
should be the case).
I then changed the formatting of the exipration date from year/month/day to 
year/day/month. It accepted all these without any errors ( placing 000000000 
into the database). I don't think this should happen.

2. Bulk upload of Designers:
	I tested this with a correct list of designers and it worked well.
I then tried uploading the respondents tab delimited file in place of the 
designers tab delimited file and it accepted it without any errors. This 
meant that the fields: pdesign, pall, pgroup, puser etc were all blank in the 
database.

I guess we need to decide which fields are required and validate accordingly.

Hope this helps.
Let me know if I can be of any further assistance.

Kon


On Thu, 18 Jul 2002 09:27, Kon Angelopoulos wrote:
> Hey Matthew,
>
> 	Had a quick look at your patch and it looks really good.
> 	Excellent Job.
> 	I've just finished patching my version of phpESP and will start testing it
> asap.
> 	I'll get back to you soon.
>
>
> Kon
>
> On Thu, 18 Jul 2002 08:07, Matthew Gregg wrote:
> > Attached is a tar containing a patch that implements bulk uploading
> > of Respondent/Designer accounts and a readme that explains it's
> > usage/limitations
> >
> > Please try it out and report any bugs or general code lameness you
> > find.
> >
> > Thanks.

Re: [phpesp-dev] Bulk upload patch

[Matthew G. <gr...@mu...>]

The only fields I set as required are the fields that are currently
required in the single Respondent/Designer Add forms.
Which are:
Username, Password and Group.

Whoops...I neglected to do any validation on the Expiration field, but
it should at least validate as much as the single Add forms.  I'll fix
that.

As for the other fields, do we want to be more strict with validation
than the single Add forms?

And thanks again for taking the time to look at this stuff.  The more
eyes the better.


On Thu, Jul 18, 2002 at 10:08:07AM +1000, Kon Angelopoulos wrote:
> Matthew,
> 
> I've finished testing your patch and I've found the following bugs:
> 1. Bulk Importing Respondent Details:
> 	I tested this functionality with a correct list of respondents and it worked 
> well. I then changed the realm to a non existent one and as expected, it 
> displayed the table with the failed uploaded rows.
> I then removed the email address from some of the respondents and it accepted 
> them without a problem. (should this be the case?).
> I them also removed the disabled field from some of the respondents and it 
> also accepted them without reporting any errors ( i don't think that this 
> should be the case).
> I then changed the formatting of the exipration date from year/month/day to 
> year/day/month. It accepted all these without any errors ( placing 000000000 
> into the database). I don't think this should happen.
> 
> 2. Bulk upload of Designers:
> 	I tested this with a correct list of designers and it worked well.
> I then tried uploading the respondents tab delimited file in place of the 
> designers tab delimited file and it accepted it without any errors. This 
...snip...

-- 
one of the friendly folks in the IT Lab.
--------------------------------------\
The IT Lab (http://www.itlab.musc.edu) \____________________
Probably the world's premier software development center.
Serving: Programming, Tools, Ice Cream, Seminars

Re: [phpesp-dev] Bulk upload patch

[Kon A. <ang...@ip...>]

Hey Matthew,

If the required fields are taken care of then the basic requirements have been 
met. There is one thing that needs to be taken care of and that is with the 
single Add forms a default value is always entered into the database table 
whereas the bulk upload facility will only enter info found in the file. 
There's no capacity to prevent fields not specified in the uploadfile from 
showing up as empty fields in the database.

eg. If I use the designer add form and only enter values for the required 
fields: username, password and group then when I click the update button it 
will enter the username, password and group into the designer table and enter 
the default values for pdesign, pstatus,pdata,pall,pgroup,puser,disabled 
etc...

If I created a designer file with only a username, password and group then 
when I upload it, all other fields will be blank in the designer table.

Does this affect the functionality of phpESP? Probably Not. empty fields 
should be interpreted as 'N'. I guess I'm a little fussy when it comes to 
data stored in databases. I prefer that fields contain some default value 
rather that being empty. It provides clarity and prevents misinterpretation.

In conclusion, I guess what ever the majority decide I'd be happy with.
James' thoughts on the subject would also be greatly appreciated.

Kon

On Thu, 18 Jul 2002 23:25, Matthew Gregg wrote:
> The only fields I set as required are the fields that are currently
> required in the single Respondent/Designer Add forms.
> Which are:
> Username, Password and Group.
>
> Whoops...I neglected to do any validation on the Expiration field, but
> it should at least validate as much as the single Add forms.  I'll fix
> that.
>
> As for the other fields, do we want to be more strict with validation
> than the single Add forms?
>
> And thanks again for taking the time to look at this stuff.  The more
> eyes the better.
>
> On Thu, Jul 18, 2002 at 10:08:07AM +1000, Kon Angelopoulos wrote:
> > Matthew,
> >
> > I've finished testing your patch and I've found the following bugs:
> > 1. Bulk Importing Respondent Details:
> > 	I tested this functionality with a correct list of respondents and it
> > worked well. I then changed the realm to a non existent one and as
> > expected, it displayed the table with the failed uploaded rows.
> > I then removed the email address from some of the respondents and it
> > accepted them without a problem. (should this be the case?).
> > I them also removed the disabled field from some of the respondents and
> > it also accepted them without reporting any errors ( i don't think that
> > this should be the case).
> > I then changed the formatting of the exipration date from year/month/day
> > to year/day/month. It accepted all these without any errors ( placing
> > 000000000 into the database). I don't think this should happen.
> >
> > 2. Bulk upload of Designers:
> > 	I tested this with a correct list of designers and it worked well.
> > I then tried uploading the respondents tab delimited file in place of the
> > designers tab delimited file and it accepted it without any errors. This
>
> ...snip...

Re: [phpesp-dev] Bulk upload patch

[Matthew G. <gr...@mu...>]

I've update the patch(see attached) so that it now does validation on
email addresses and expiration dates.  It should also correctly set
the defaults for "pdesign, pstatus, pdata, pall, pgroup, puser,
disabled", if they aren't correctly specified in the uploaded data.

I'd like to push this up to CVS if you guys feel comfortable enough
with it.  James?

ON Fri, Jul 19, 2002 at 08:35:47PM +1000, Kon Angelopoulos wrote:
> Hey Matthew,
> 
> If the required fields are taken care of then the basic requirements have been 
> met. There is one thing that needs to be taken care of and that is with the 
> single Add forms a default value is always entered into the database table 
> whereas the bulk upload facility will only enter info found in the file. 
> There's no capacity to prevent fields not specified in the uploadfile from 
> showing up as empty fields in the database.
> 
> eg. If I use the designer add form and only enter values for the required 
> fields: username, password and group then when I click the update button it 
> will enter the username, password and group into the designer table and enter 
> the default values for pdesign, pstatus,pdata,pall,pgroup,puser,disabled 
> etc...
> 
> If I created a designer file with only a username, password and group then 
> when I upload it, all other fields will be blank in the designer table.
> 
> Does this affect the functionality of phpESP? Probably Not. empty fields 
> should be interpreted as 'N'. I guess I'm a little fussy when it comes to 
> data stored in databases. I prefer that fields contain some default value 
> rather that being empty. It provides clarity and prevents misinterpretation.
> 
> In conclusion, I guess what ever the majority decide I'd be happy with.
> James' thoughts on the subject would also be greatly appreciated.
> 
> Kon
> 
> On Thu, 18 Jul 2002 23:25, Matthew Gregg wrote:
> > The only fields I set as required are the fields that are currently
> > required in the single Respondent/Designer Add forms.
> > Which are:
> > Username, Password and Group.
> >
> > Whoops...I neglected to do any validation on the Expiration field, but
> > it should at least validate as much as the single Add forms.  I'll fix
> > that.
> >
> > As for the other fields, do we want to be more strict with validation
> > than the single Add forms?
> >
> > And thanks again for taking the time to look at this stuff.  The more
> > eyes the better.
> >
> > On Thu, Jul 18, 2002 at 10:08:07AM +1000, Kon Angelopoulos wrote:
> > > Matthew,
> > >
> > > I've finished testing your patch and I've found the following bugs:
> > > 1. Bulk Importing Respondent Details:
> > > 	I tested this functionality with a correct list of respondents and it
> > > worked well. I then changed the realm to a non existent one and as
> > > expected, it displayed the table with the failed uploaded rows.
> > > I then removed the email address from some of the respondents and it
> > > accepted them without a problem. (should this be the case?).
> > > I them also removed the disabled field from some of the respondents and
> > > it also accepted them without reporting any errors ( i don't think that
> > > this should be the case).
> > > I then changed the formatting of the exipration date from year/month/day
> > > to year/day/month. It accepted all these without any errors ( placing
> > > 000000000 into the database). I don't think this should happen.
> > >
> > > 2. Bulk upload of Designers:
> > > 	I tested this with a correct list of designers and it worked well.
> > > I then tried uploading the respondents tab delimited file in place of the
> > > designers tab delimited file and it accepted it without any errors. This
> >
> > ...snip...
> 
> 
> 
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> phpESP-devel mailing list
> php...@li...
> https://lists.sourceforge.net/lists/listinfo/phpesp-devel
> 

-- 
one of the friendly folks in the IT Lab.
--------------------------------------\
The IT Lab (http://www.itlab.musc.edu) \____________________
Probably the world's premier software development center.
Serving: Programming, Tools, Ice Cream, Seminars

Re: [phpesp-dev] Bulk upload patch

[Kon A. <ang...@ip...>]

Hey Matthew,

A job well done.
I've tested it again and it worked fine for me.
I'd be pushing it up to cvs.

Kon

On Sat, 20 Jul 2002 04:31, Matthew Gregg wrote:
> I've update the patch(see attached) so that it now does validation on
> email addresses and expiration dates.  It should also correctly set
> the defaults for "pdesign, pstatus, pdata, pall, pgroup, puser,
> disabled", if they aren't correctly specified in the uploaded data.
>
> I'd like to push this up to CVS if you guys feel comfortable enough
> with it.  James?
>
> ON Fri, Jul 19, 2002 at 08:35:47PM +1000, Kon Angelopoulos wrote:
> > Hey Matthew,
> >
> > If the required fields are taken care of then the basic requirements have
> > been met. There is one thing that needs to be taken care of and that is
> > with the single Add forms a default value is always entered into the
> > database table whereas the bulk upload facility will only enter info
> > found in the file. There's no capacity to prevent fields not specified in
> > the uploadfile from showing up as empty fields in the database.
> >
> > eg. If I use the designer add form and only enter values for the required
> > fields: username, password and group then when I click the update button
> > it will enter the username, password and group into the designer table
> > and enter the default values for pdesign,
> > pstatus,pdata,pall,pgroup,puser,disabled etc...
> >
> > If I created a designer file with only a username, password and group
> > then when I upload it, all other fields will be blank in the designer
> > table.
> >
> > Does this affect the functionality of phpESP? Probably Not. empty fields
> > should be interpreted as 'N'. I guess I'm a little fussy when it comes to
> > data stored in databases. I prefer that fields contain some default value
> > rather that being empty. It provides clarity and prevents
> > misinterpretation.
> >
> > In conclusion, I guess what ever the majority decide I'd be happy with.
> > James' thoughts on the subject would also be greatly appreciated.
> >
> > Kon
> >
> > On Thu, 18 Jul 2002 23:25, Matthew Gregg wrote:
> > > The only fields I set as required are the fields that are currently
> > > required in the single Respondent/Designer Add forms.
> > > Which are:
> > > Username, Password and Group.
> > >
> > > Whoops...I neglected to do any validation on the Expiration field, but
> > > it should at least validate as much as the single Add forms.  I'll fix
> > > that.
> > >
> > > As for the other fields, do we want to be more strict with validation
> > > than the single Add forms?
> > >
> > > And thanks again for taking the time to look at this stuff.  The more
> > > eyes the better.
> > >
> > > On Thu, Jul 18, 2002 at 10:08:07AM +1000, Kon Angelopoulos wrote:
> > > > Matthew,
> > > >
> > > > I've finished testing your patch and I've found the following bugs:
> > > > 1. Bulk Importing Respondent Details:
> > > > 	I tested this functionality with a correct list of respondents and
> > > > it worked well. I then changed the realm to a non existent one and as
> > > > expected, it displayed the table with the failed uploaded rows. I
> > > > then removed the email address from some of the respondents and it
> > > > accepted them without a problem. (should this be the case?). I them
> > > > also removed the disabled field from some of the respondents and it
> > > > also accepted them without reporting any errors ( i don't think that
> > > > this should be the case).
> > > > I then changed the formatting of the exipration date from
> > > > year/month/day to year/day/month. It accepted all these without any
> > > > errors ( placing 000000000 into the database). I don't think this
> > > > should happen.
> > > >
> > > > 2. Bulk upload of Designers:
> > > > 	I tested this with a correct list of designers and it worked well.
> > > > I then tried uploading the respondents tab delimited file in place of
> > > > the designers tab delimited file and it accepted it without any
> > > > errors. This
> > >
> > > ...snip...
> >
> > This sf.net email is sponsored by:ThinkGeek
> > Welcome to geek heaven.
> > http://thinkgeek.com/sf
> > _______________________________________________
> > phpESP-devel mailing list
> > php...@li...
> > https://lists.sourceforge.net/lists/listinfo/phpesp-devel

Re: [phpesp-dev] Bulk upload patch

[<fl...@gm...>]

funny! i´m just writing a similar thing!
well maybe i lost,did not read some of these mails but the code looks like
the csv must be preformated!?
why not doing a preview where you can set each array and set a global Y,N
/activ,inactiv , expir etc ...

example for a preview wher you can set: "WHAT IS WHAT"
so then you can use any kind of  exported csv or text files-database!?
// code snippet
function makeopi($x) {
       echo "<TD><select name=\"data$x\" size=\"1\">\n<option>
</option>\n<option value=\"fname\">"._FNAME."</option>"
           ."<option value=\"lname\">"._LNAME."</option>\n"
          ."<option value=\"username\">"._USERNAME."</option>\n"
           ."<option value=\"email\">"._EMAIL."</option></select></TD>\n";
        // etc.. ++
       }
// ....prev. import data
// ... now use <option> to set which array num is which variable
// ... submit ->start funstions and place the data in DB

flobee

----- Original Message -----
From: "Matthew Gregg" <gr...@mu...>
To: "Kon Angelopoulos" <ang...@ip...>
Cc: <php...@li...>
Sent: Friday, July 19, 2002 8:31 PM
Subject: Re: [phpesp-dev] Bulk upload patch


I've update the patch(see attached) so that it now does validation on
email addresses and expiration dates.  It should also correctly set
the defaults for "pdesign, pstatus, pdata, pall, pgroup, puser,
disabled", if they aren't correctly specified in the uploaded data.

I'd like to push this up to CVS if you guys feel comfortable enough
with it.  James?

ON Fri, Jul 19, 2002 at 08:35:47PM +1000, Kon Angelopoulos wrote:
> Hey Matthew,
>
> If the required fields are taken care of then the basic requirements have
been
> met. There is one thing that needs to be taken care of and that is with
the
> single Add forms a default value is always entered into the database table
> whereas the bulk upload facility will only enter info found in the file.
> There's no capacity to prevent fields not specified in the uploadfile from

> showing up as empty fields in the database.
>
> eg. If I use the designer add form and only enter values for the required
> fields: username, password and group then when I click the update button
it
> will enter the username, password and group into the designer table and
enter
> the default values for pdesign, pstatus,pdata,pall,pgroup,puser,disabled
> etc...
>
> If I created a designer file with only a username, password and group then
> when I upload it, all other fields will be blank in the designer table.
>
> Does this affect the functionality of phpESP? Probably Not. empty fields
> should be interpreted as 'N'. I guess I'm a little fussy when it comes to
> data stored in databases. I prefer that fields contain some default value
> rather that being empty. It provides clarity and prevents
misinterpretation.
>
> In conclusion, I guess what ever the majority decide I'd be happy with.
> James' thoughts on the subject would also be greatly appreciated.
>
> Kon
>
> On Thu, 18 Jul 2002 23:25, Matthew Gregg wrote:
> > The only fields I set as required are the fields that are currently
> > required in the single Respondent/Designer Add forms.
> > Which are:
> > Username, Password and Group.
> >
> > Whoops...I neglected to do any validation on the Expiration field, but
> > it should at least validate as much as the single Add forms.  I'll fix
> > that.
> >
> > As for the other fields, do we want to be more strict with validation
> > than the single Add forms?
> >
> > And thanks again for taking the time to look at this stuff.  The more
> > eyes the better.
> >
> > On Thu, Jul 18, 2002 at 10:08:07AM +1000, Kon Angelopoulos wrote:
> > > Matthew,
> > >
> > > I've finished testing your patch and I've found the following bugs:
> > > 1. Bulk Importing Respondent Details:
> > > I tested this functionality with a correct list of respondents and it
> > > worked well. I then changed the realm to a non existent one and as
> > > expected, it displayed the table with the failed uploaded rows.
> > > I then removed the email address from some of the respondents and it
> > > accepted them without a problem. (should this be the case?).
> > > I them also removed the disabled field from some of the respondents
and
> > > it also accepted them without reporting any errors ( i don't think
that
> > > this should be the case).
> > > I then changed the formatting of the exipration date from
year/month/day
> > > to year/day/month. It accepted all these without any errors ( placing
> > > 000000000 into the database). I don't think this should happen.
> > >
> > > 2. Bulk upload of Designers:
> > > I tested this with a correct list of designers and it worked well.
> > > I then tried uploading the respondents tab delimited file in place of
the
> > > designers tab delimited file and it accepted it without any errors.
This
> >
> > ...snip...
>
>
>
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> phpESP-devel mailing list
> php...@li...
> https://lists.sourceforge.net/lists/listinfo/phpesp-devel
>

--
one of the friendly folks in the IT Lab.
--------------------------------------\
The IT Lab (http://www.itlab.musc.edu) \____________________
Probably the world's premier software development center.
Serving: Programming, Tools, Ice Cream, Seminars

Re: [phpesp-dev] Bulk upload patch

[Matthew G. <gr...@mu...>]

On Fri, Jul 19, 2002 at 09:02:12PM +0200, fl...@gm... wrote:
> funny! i?m just writing a similar thing!
Check the Feature request page on Sourceforge.
http://sourceforge.net/tracker/?atid=358956&group_id=8956&func=browse

> well maybe i lost,did not read some of these mails but the code looks like
> the csv must be preformated!?
> why not doing a preview where you can set each array and set a global Y,N
> /activ,inactiv , expir etc ...
> 
> example for a preview wher you can set: "WHAT IS WHAT"

I don't quite understand what you mean here.  
Are you saying that ESP should read the upload file and show a "preview"
to allow the user to associate fields in the text file with
fields in the ESP database?

If so, we would still need to know how to parse the uploaded
format(xml, csv, tab, etc..).  I'm not sure it would be worth doing
preview/associate in ESP, when you can easily format the text file
outside of ESP using Excel, Gnumeric, etc. Much in the same way as the
ESP export function.  The data is in one format and the user can
format it themselves using whatever tool they have.

Of course if you're uploading XML, it will need to be valid against
our(or some standard) DTD/Schema, so the preview will be somewhat
useless with XML data.


> so then you can use any kind of  exported csv or text files-database!?
> // code snippet
> function makeopi($x) {
>        echo "<TD><select name=\"data$x\" size=\"1\">\n<option>
> </option>\n<option value=\"fname\">"._FNAME."</option>"
>            ."<option value=\"lname\">"._LNAME."</option>\n"
>           ."<option value=\"username\">"._USERNAME."</option>\n"
>            ."<option value=\"email\">"._EMAIL."</option></select></TD>\n";
>         // etc.. ++
>        }
> // ....prev. import data
> // ... now use <option> to set which array num is which variable
> // ... submit ->start funstions and place the data in DB
> 
> flobee
> 
> From: "Matthew Gregg" <gr...@mu...>
> To: "Kon Angelopoulos" <ang...@ip...>
> Cc: <php...@li...>
> Sent: Friday, July 19, 2002 8:31 PM
> Subject: Re: [phpesp-dev] Bulk upload patch
> 
> 
> I've update the patch(see attached) so that it now does validation on
> email addresses and expiration dates.  It should also correctly set
> the defaults for "pdesign, pstatus, pdata, pall, pgroup, puser,
> disabled", if they aren't correctly specified in the uploaded data.
> 
> I'd like to push this up to CVS if you guys feel comfortable enough
> with it.  James?
> 
> ON Fri, Jul 19, 2002 at 08:35:47PM +1000, Kon Angelopoulos wrote:
> > Hey Matthew,
> >
> > If the required fields are taken care of then the basic requirements have
> been
> > met. There is one thing that needs to be taken care of and that is with
> the
> > single Add forms a default value is always entered into the database table
> > whereas the bulk upload facility will only enter info found in the file.
> > There's no capacity to prevent fields not specified in the uploadfile from
> 
> > showing up as empty fields in the database.
> >
> > eg. If I use the designer add form and only enter values for the required
> > fields: username, password and group then when I click the update button
> it
> > will enter the username, password and group into the designer table and
> enter
> > the default values for pdesign, pstatus,pdata,pall,pgroup,puser,disabled
> > etc...
> >
> > If I created a designer file with only a username, password and group then
> > when I upload it, all other fields will be blank in the designer table.
> >
> > Does this affect the functionality of phpESP? Probably Not. empty fields
> > should be interpreted as 'N'. I guess I'm a little fussy when it comes to
> > data stored in databases. I prefer that fields contain some default value
> > rather that being empty. It provides clarity and prevents
> misinterpretation.
> >
> > In conclusion, I guess what ever the majority decide I'd be happy with.
> > James' thoughts on the subject would also be greatly appreciated.
> >
> > Kon
> >
> > On Thu, 18 Jul 2002 23:25, Matthew Gregg wrote:
> > > The only fields I set as required are the fields that are currently
> > > required in the single Respondent/Designer Add forms.
> > > Which are:
> > > Username, Password and Group.
> > >
> > > Whoops...I neglected to do any validation on the Expiration field, but
> > > it should at least validate as much as the single Add forms.  I'll fix
> > > that.
> > >
> > > As for the other fields, do we want to be more strict with validation
> > > than the single Add forms?
> > >
> > > And thanks again for taking the time to look at this stuff.  The more
> > > eyes the better.
> > >
> > > On Thu, Jul 18, 2002 at 10:08:07AM +1000, Kon Angelopoulos wrote:
> > > > Matthew,
> > > >
> > > > I've finished testing your patch and I've found the following bugs:
> > > > 1. Bulk Importing Respondent Details:
> > > > I tested this functionality with a correct list of respondents and it
> > > > worked well. I then changed the realm to a non existent one and as
> > > > expected, it displayed the table with the failed uploaded rows.
> > > > I then removed the email address from some of the respondents and it
> > > > accepted them without a problem. (should this be the case?).
> > > > I them also removed the disabled field from some of the respondents
> and
> > > > it also accepted them without reporting any errors ( i don't think
> that
> > > > this should be the case).
> > > > I then changed the formatting of the exipration date from
> year/month/day
> > > > to year/day/month. It accepted all these without any errors ( placing
> > > > 000000000 into the database). I don't think this should happen.
> > > >
> > > > 2. Bulk upload of Designers:
> > > > I tested this with a correct list of designers and it worked well.
> > > > I then tried uploading the respondents tab delimited file in place of
> the
> > > > designers tab delimited file and it accepted it without any errors.
> This
> > >
> > > ...snip...
> >
> >
> >
> > This sf.net email is sponsored by:ThinkGeek
> > Welcome to geek heaven.
> > http://thinkgeek.com/sf
> > _______________________________________________
> > phpESP-devel mailing list
> > php...@li...
> > https://lists.sourceforge.net/lists/listinfo/phpesp-devel
> >
> 

-- 
one of the friendly folks in the IT Lab.
--------------------------------------\
The IT Lab (http://www.itlab.musc.edu) \____________________
Probably the world's premier software development center.
Serving: Programming, Tools, Ice Cream, Seminars

Re: [phpesp-dev] Bulk upload patch

[Kon A. <ang...@ip...>]

I agree with Matthew on this one.

Kon

On Sat, 20 Jul 2002 06:06, Matthew Gregg wrote:
> On Fri, Jul 19, 2002 at 09:02:12PM +0200, fl...@gm... wrote:
> > funny! i?m just writing a similar thing!
>
> Check the Feature request page on Sourceforge.
> http://sourceforge.net/tracker/?atid=358956&group_id=8956&func=browse
>
> > well maybe i lost,did not read some of these mails but the code looks
> > like the csv must be preformated!?
> > why not doing a preview where you can set each array and set a global Y,N
> > /activ,inactiv , expir etc ...
> >
> > example for a preview wher you can set: "WHAT IS WHAT"
>
> I don't quite understand what you mean here.
> Are you saying that ESP should read the upload file and show a "preview"
> to allow the user to associate fields in the text file with
> fields in the ESP database?
>
> If so, we would still need to know how to parse the uploaded
> format(xml, csv, tab, etc..).  I'm not sure it would be worth doing
> preview/associate in ESP, when you can easily format the text file
> outside of ESP using Excel, Gnumeric, etc. Much in the same way as the
> ESP export function.  The data is in one format and the user can
> format it themselves using whatever tool they have.
>
> Of course if you're uploading XML, it will need to be valid against
> our(or some standard) DTD/Schema, so the preview will be somewhat
> useless with XML data.
>
> > so then you can use any kind of  exported csv or text files-database!?
> > // code snippet
> > function makeopi($x) {
> >        echo "<TD><select name=\"data$x\" size=\"1\">\n<option>
> > </option>\n<option value=\"fname\">"._FNAME."</option>"
> >            ."<option value=\"lname\">"._LNAME."</option>\n"
> >           ."<option value=\"username\">"._USERNAME."</option>\n"
> >            ."<option
> > value=\"email\">"._EMAIL."</option></select></TD>\n"; // etc.. ++
> >        }
> > // ....prev. import data
> > // ... now use <option> to set which array num is which variable
> > // ... submit ->start funstions and place the data in DB
> >
> > flobee
> >
> > From: "Matthew Gregg" <gr...@mu...>
> > To: "Kon Angelopoulos" <ang...@ip...>
> > Cc: <php...@li...>
> > Sent: Friday, July 19, 2002 8:31 PM
> > Subject: Re: [phpesp-dev] Bulk upload patch
> >
> >
> > I've update the patch(see attached) so that it now does validation on
> > email addresses and expiration dates.  It should also correctly set
> > the defaults for "pdesign, pstatus, pdata, pall, pgroup, puser,
> > disabled", if they aren't correctly specified in the uploaded data.
> >
> > I'd like to push this up to CVS if you guys feel comfortable enough
> > with it.  James?
> >
> > ON Fri, Jul 19, 2002 at 08:35:47PM +1000, Kon Angelopoulos wrote:
> > > Hey Matthew,
> > >
> > > If the required fields are taken care of then the basic requirements
> > > have
> >
> > been
> >
> > > met. There is one thing that needs to be taken care of and that is with
> >
> > the
> >
> > > single Add forms a default value is always entered into the database
> > > table whereas the bulk upload facility will only enter info found in
> > > the file. There's no capacity to prevent fields not specified in the
> > > uploadfile from
> > >
> > > showing up as empty fields in the database.
> > >
> > > eg. If I use the designer add form and only enter values for the
> > > required fields: username, password and group then when I click the
> > > update button
> >
> > it
> >
> > > will enter the username, password and group into the designer table and
> >
> > enter
> >
> > > the default values for pdesign,
> > > pstatus,pdata,pall,pgroup,puser,disabled etc...
> > >
> > > If I created a designer file with only a username, password and group
> > > then when I upload it, all other fields will be blank in the designer
> > > table.
> > >
> > > Does this affect the functionality of phpESP? Probably Not. empty
> > > fields should be interpreted as 'N'. I guess I'm a little fussy when it
> > > comes to data stored in databases. I prefer that fields contain some
> > > default value rather that being empty. It provides clarity and prevents
> >
> > misinterpretation.
> >
> > > In conclusion, I guess what ever the majority decide I'd be happy with.
> > > James' thoughts on the subject would also be greatly appreciated.
> > >
> > > Kon
> > >
> > > On Thu, 18 Jul 2002 23:25, Matthew Gregg wrote:
> > > > The only fields I set as required are the fields that are currently
> > > > required in the single Respondent/Designer Add forms.
> > > > Which are:
> > > > Username, Password and Group.
> > > >
> > > > Whoops...I neglected to do any validation on the Expiration field,
> > > > but it should at least validate as much as the single Add forms. 
> > > > I'll fix that.
> > > >
> > > > As for the other fields, do we want to be more strict with validation
> > > > than the single Add forms?
> > > >
> > > > And thanks again for taking the time to look at this stuff.  The more
> > > > eyes the better.
> > > >
> > > > On Thu, Jul 18, 2002 at 10:08:07AM +1000, Kon Angelopoulos wrote:
> > > > > Matthew,
> > > > >
> > > > > I've finished testing your patch and I've found the following bugs:
> > > > > 1. Bulk Importing Respondent Details:
> > > > > I tested this functionality with a correct list of respondents and
> > > > > it worked well. I then changed the realm to a non existent one and
> > > > > as expected, it displayed the table with the failed uploaded rows.
> > > > > I then removed the email address from some of the respondents and
> > > > > it accepted them without a problem. (should this be the case?). I
> > > > > them also removed the disabled field from some of the respondents
> >
> > and
> >
> > > > > it also accepted them without reporting any errors ( i don't think
> >
> > that
> >
> > > > > this should be the case).
> > > > > I then changed the formatting of the exipration date from
> >
> > year/month/day
> >
> > > > > to year/day/month. It accepted all these without any errors (
> > > > > placing 000000000 into the database). I don't think this should
> > > > > happen.
> > > > >
> > > > > 2. Bulk upload of Designers:
> > > > > I tested this with a correct list of designers and it worked well.
> > > > > I then tried uploading the respondents tab delimited file in place
> > > > > of
> >
> > the
> >
> > > > > designers tab delimited file and it accepted it without any errors.
> >
> > This
> >
> > > > ...snip...
> > >
> > > This sf.net email is sponsored by:ThinkGeek
> > > Welcome to geek heaven.
> > > http://thinkgeek.com/sf
> > > _______________________________________________
> > > phpESP-devel mailing list
> > > php...@li...
> > > https://lists.sourceforge.net/lists/listinfo/phpesp-devel