Wolfgang , Rony,

I have no problem with this new field, but as I replied to a recent Feature Request "2832810 Email Address Field"  (I have copied that response below), the previous misguided IMHO, but understandable due to the previous dialog design, use of a single field for multiple purposes will cause some issues in its implementation.

Email is currently supported in the URL field by prefixing the data by the keyword 'mailto:' but really only for sending emails as opposed to opening a web page.

Whilst the recent redesign of Add/Edit would allow more space for extra fields, we then have a problem of how to migrate any existing email addresses in the URL field to a new email field. We could use the fact that the existing email address have the 'mailto:' prefix - but we would have to leave the data in the URL field in case the user opens the database using a prior version. We could leave it to the user to move/copy the data to the new field. We also have the problem that menu items that recognise that the URL field contains an email address change their nature accordingly - what would we do if the URL and the new email field both have email addresses in them? Which one would we select to use?

I am afraid this is a consequence of not wishing to make the original dialog to big and clumsy and so giving a field more than one function. As I said, going forward, the redesign will hopefully remove this need but changing existing multi-use fields present a problem.


2009/8/10 Wolfgang Keller <9103784@gmx.de>
Hi Rony

I am astounded by your experience ;) as for me the regular case when
registering into a fancy forum is that at least 3 information data are
a) user name (alias which you use as public name in the forum), b)
password to logon and c) email address. (At some more serious fora point
a) is still split up into "real name" and "forum nickname", just to be
precise.) - Now a) and b) are normally required to logon into the forum
while c) is information in the background. You still want to have c) at
hand quickly e.g. in case you take separate communication contacts with
the providers etc. and wish to keep some continuity in that communication.

So I'ld say the Email field makes much sense and I definitely couldn't
work with the username field for it.

- Wolfgang

ronys wrote:
> Hi Wolfgang,
> What I usually do in such cases is to use the 'user' field for storing the
> relevant e-mail address, since most (all?) of the time that an e-mail is
> required, this is also the required login id.
> Do you think this would work for you, or is a separate 'e-mail' field type
> still needed?
> Cheers,
>   Rony
> -----Original Message-----
> From: Wolfgang Keller [mailto:9103784@gmx.de]
> Sent: Monday, August 10, 2009 9:57 AM
> To: passwordsafe-devel@lists.sourceforge.net
> Subject: [Passwordsafe-devel] New Field "Email"
> Hello
> After long time I am sitting over a new release of JPasswords. I am
> interested in a new data field named "Email". I noticed in my own
> practice that taking note of the email address given away is regular
> habit when registering into some new internet site. (People usually have
> several different addresses.) So I think a separate field with that
> information is useful and justified. - If you follow me in this and like
> to have this extra field within the official canon of the PWS file
> format, I'ld kindly ask you to render a corresponding field value and
> update documentation. Otherwise I'll be using a "private" field.
> Cheers!
> - Wolfgang

Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
Passwordsafe-devel mailing list