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.
<quote>
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.
<unquote>
David
2009/8/10 Wolfgang Keller <91...@gm...>
> 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
> required
> 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:91...@gm...]
> > Sent: Monday, August 10, 2009 9:57 AM
> > To: pas...@li...
> > 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
> Pas...@li...
> https://lists.sourceforge.net/lists/listinfo/passwordsafe-devel
>
|
