New times submission page

[GoogleCodeExporter]

New times submission page
=========================

A page from which anyone may log a time they have set in a challenge.

I was going to build this so that the page entered times directly into 
tc_data table with the pending_yn flag set to 'Y'. At this stage the time 
would not appear in any league table pages that may be relevant, but would 
appear in a list of "currently pending" times on the submit page itself. 

On submission, email would be sent to anyone with administrator "account" 
(so this functionality and database tables where required would need to be 
built) and they would come along and review the time. If they are happy it 
was from a trustworthy source etc they could approve (or reject) it, or 
contact the submitter (who will have to leave his email then, I guess) for 
further information.

Once approved, pending_yn is reset to N, and the upd_id/upd_date of the 
admin logged.

Perhaps would be better if a seperate database table for pending times is 
used? Then approval process can copy it across. This would remove need to 
update select query for every table on every page to account for 
pending_yn status (at current this isn't even considered).

Original issue reported on code.google.com by matthew.scrivin on 22 Oct 2009 at 8:17

[GoogleCodeExporter]

> A page from which anyone may log a time they have set in a challenge.

A nice little project to start us off with! :)

> I was going to build this so that the page entered times directly into 
> tc_data table with the pending_yn flag set to 'Y'. At this stage the time 
> would not appear in any league table pages that may be relevant, but would 
> appear in a list of "currently pending" times on the submit page itself. 

Just a thought about storing yes/no values. My style is to have the data type as
boolean and store a 0 or 1 (you might not want to default the value to 0). The 
code
for determining if the flag has been set is then very simple: if($flag) { ... }.
However let's stick to your naming convention for the time being.

> On submission, email would be sent to anyone with administrator "account" 
> (so this functionality and database tables where required would need to be 
> built) and they would come along and review the time. If they are happy it 
> was from a trustworthy source etc they could approve (or reject) it, or 
> contact the submitter (who will have to leave his email then, I guess) for 
> further information.

OK we need some code to handle this and at least one table with name, role, 
email,
active y/n.

> Once approved, pending_yn is reset to N, and the upd_id/upd_date of the 
> admin logged.

> Perhaps would be better if a seperate database table for pending times is 
> used? Then approval process can copy it across. This would remove need to 
> update select query for every table on every page to account for 
> pending_yn status (at current this isn't even considered).

Having it in another table would be neater (I think this what you meant) and I 
agree
it would keep things a lot simpler if the row were copied over into the 'live'
table(s) when a given record is approved.

Original comment by t...@pberry.me.uk on 22 Oct 2009 at 8:28

[GoogleCodeExporter]

> A nice little project to start us off with! :)

Just going through the shopping list :)

For whatever reason, here at work we use _yn fields for things like this so was 
just 
following a convention I am used to. This is by no means a dictation, I suspect 
you 
guys will be stronger than I am when it comes to this so I'll follow your lead 
:)

Original comment by matthew.scrivin on 22 Oct 2009 at 8:39

[GoogleCodeExporter]

Like Paul, my preference is for boolean values. However, it might be better to 
use
_yn fields to make things more readable.

Original comment by chagani....@gmail.com on 22 Oct 2009 at 2:50

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Could we nail down a specification for this new functionality please? I've 
drawn up a
quick flow chart of what should happen.

I've assumed they need to give their forum name if they have one (most likely)
otherwise their email address (least likely).

Original comment by t...@pberry.me.uk on 2 Dec 2009 at 12:12

Attachments:

• issue01.png

[GoogleCodeExporter]

Just realised need a box between "User selects Challenge Type from dropdown" and
"User enters time (hh:mm:ss)" called "User enters date time set (dd/mm/yy)".

Comments please...

Original comment by t...@pberry.me.uk on 2 Dec 2009 at 5:24

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Amended flow chart.

Original comment by t...@pberry.me.uk on 4 Dec 2009 at 1:53

Attachments:

• issue01.png

[GoogleCodeExporter]

Looks good to me, user will need to be able to select/type multiple (forum) 
names for 
team attempts of course...

Original comment by matthew.scrivin on 4 Dec 2009 at 2:54

[GoogleCodeExporter]

> Looks good to me, user will need to be able to select/type multiple (forum) 
names
> for team attempts of course...

Yep, good point.

Original comment by t...@pberry.me.uk on 4 Dec 2009 at 3:09

[GoogleCodeExporter]

Flow chart amended to allow teams to be entered.

Original comment by t...@pberry.me.uk on 29 Dec 2009 at 10:12

Attachments:

• issue01.png

[GoogleCodeExporter]

Do we want to have a user authentication mechanism to control the site?

It's not so much that we don't trust each other but it would prevent the usual 
crap
appearing that invariably collects on public sites. And prevent the odd crazy 
claim
to a record time.

We don't have back-end access to the TC Forum so would have to ask everyone who
wanted an account for the league tables to register with their forum screen 
name.
This means they'd have to have a forum account first: I would check their 
username
exists as part of the registration process.

This is a fair bit of overhead but it's necessary anyway to make Issue 2 (and
probably others) feasible as well.

Original comment by t...@pberry.me.uk on 19 Jan 2010 at 1:07

[GoogleCodeExporter]

Might be an idea - I envisaged a system where there was no authentication to 
allow a
time to be submitted, only for a handful of admins who would have the job of
"verifying" and approving the submitted times. However, you make a good point 
about
the crap that can appear on public sites...

Original comment by matthew.scrivin on 20 Jan 2010 at 1:22