Hi, > > The use of "$allurls" is because I also added the ability to upload > > multiple files at once and send all the tickets in the one mail. I'm > > What happens if somebody uploads 2 files? 2 urls are generated?
Yes. It's really for the pick-list because normally when I want to send
someone phred I also want to send them phrap (see the attached) so I
want to make 2 tickets at once. I just put the ticket generation code
in a foreach loop, so it spits out separate tickets for each file.
> I was thinking of packing all the "fancy" options inside a div, and
> hide it by default. Maybe in 2 layers (mandatory at the top, basic
> and expert).
I'm not a fan of the "Basic" and "Expert" classifications for
configuration options because generally you use the settings you need,
not the ones you understand. I'd stick with a single div called
something like "more options" and maybe persist the hidden/not hidden
state along with the other configuration.
> Talking about ip-locking, it would definitely be nice if, when a
> domain name is inserted, all IPs that reverse to something inside
> that domain would be allowed. That would make it much more useful
> IMHO. That would allow for "local" tickets without messing with
> masks, while still permitting single IP addresses.
Possibly, but on the other hand it might make the thing even more
confusing. Right now, my patch just picks up the IP address of the
first downloader (and we ignore complications of NAT, proxies, DHCP).
If you just had a button "lock to domain" then you need to use a
heuristic to determine what the domain is when the first connection is
made:
eg: 80.68.88.20 => e.thregr.org
64.202.189.170 => pwfwd-v01.prod.mesa1.secureserver.net
You probably keep it simple and just chop off the first bit. But in the
second case you probably want to lock downloads to *.secureserver.net
rather than *.prod.mesa1.secureserver.net.
If the reverse lookup fails what do you do? Lock to single IP, lock to
64.202.189.*?
If you allow the domain to be specified on the form it's even worse. If
you want to send a ticket to me you might say "lock to *.ceh.ac.uk",
which will fail. Then you ask me what's my computer name and I say
"barsukas.nox.ac.uk" which is true but in fact the canonical name is
"ivpcp099.nerc-oxford.ac.uk". So the user needs to know a fair amount
about DNS to properly use this function.
Having said that, if I was regularly sending tickets out to a known
domain (eg., within this building) then I only have to worry about this
once and it could be very useful.
And one other unrelated thing:
I'm finding that on my browser (Firefox 3.0.x) the configuration cookies
are being set to expire "at end of session" which is the default unless
an 'expires=' value is set. I think you need to go back to your
previous behaviour and have them last for a year:
var defaultexpire = new Date();
defaultexpire.setDate(defaultexpire.getDate() + 366);
Or since you now have user accounts in DL, just do the obvious thing and
bung the settings in the database against the user name.
Cheers,
TIM
--
Tim Booth <[email protected]>
NERC Environmental Bioinformatics Centre
at CEH Oxford
+44 1865 281 975
<<attachment: dl.png>>
