[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: 1.3.16 released

Hello everyone,

I've just installed 1.3.16 as a test and have some comments and
questions. Most of these probably apply equally to older versions in the
1.3.x series. If there's a better place to post info like this, please
let me know.

I've used setup.pl to create a fresh database.

In general the forms in the various stages of setup.pl could be a bit
more verbose. The first screen which prompts for user, password and
database could explain that the database field should be the new
database which you wish to create and not a postgresql template db or
suchlike. It would be nice also to point out that the users will
eventually use this database name as the "company" field at login which
would help in choosing a sensible name.

When selecting "yes" to create the database it took maybe 20 seconds
on my server. Since there's no user feedback during this time it would
be user-friendly to let the user know beforehand that it might take a
minute to complete.

The screen for choosing the country code does not say what it relates
to. I'm guessing it's for the initial CoA, but it could be anything
which for multi-national businesses might be confusing.

When creating the first user there is no indication that the password
only has a lifetime of 24 hours, and no option to extend it. This is a
security plus but a usability minus, so at least a warning that it's
temporary at this point would be good.

On first login to the non-admin area with the new user we have to update
the password and also set some prefs. When the password is updated the
user receives another basic auth prompt where they need to enter the new
password and, having done so, receive the message "Error! Incorrect
Password". Now, this I think is going to be really confusing. It
confused me for sure and I would go so far as to say that this is a bug.
It's not what I as a user would expect and it's not clear from the error
message whether the password change has succeeded (which apparently it
has) or not and therefore which password it thinks is incorrect.

The password has changed by this point and the user is still logged in,
which is good. But the preferences which they set (date format, number
format, language, printer, etc.) in the previous step have not been
saved. This I think is another bug. Going into the preferences menu and
saving them again works, so it sounds like there's some sort of race
condition in the password-changing step above.

It seemed sensible to write all this down while it was fresh, so I have
paused in the testing to write this message, but will continue now and
send through other comments later. The setup.pl is important as it is
supposedly a user-friendly way for people to set up their first database
and get going, but I've found some of these niggles with it to be
confusing which might be damaging in creating a first impression. So
despite the minor nature of some of my comments here they could have a
major effect. Do take it all in the constructive nature in which it is
intended, please.

JFTR, this is on a CentOS 6 machine: Perl 5.10.1, Apache 2.2.15,
postgresql 8.4.7

Openstrike - improving business through open source
http://www.openstrike.co.uk/ or call 01722 770036 / 07092 020107

Attachment: pgp3t7uXmQd6J.pgp
Description: PGP signature

Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
Ledger-smb-users mailing list