Re: [Gnumed-devel] re: create user UI plugin

[J Busser]

Self-replying, it might be helpful for the widget to pre-populate 
this "sign" (or call-sign etc) with a value derived by parsing the 
staff member's names to return the initials.

Ideally, before returning them, it could check whether these already exist, and
   if they are unique, offer these as a default but
   if they are not unique, return an alert

I suppose it could be up to the local administrators to decide 
whether to adhere to a "format" for example the doctors (like Karsten 
Hilbert) could have a convention to have the short_name or call-sign 
"DrKH" but that would be purely to make the value informative and any 
presence of "Dr" in this field would not be to grant or enforce any 
privileges.

Is there any reason that once the staff member has been created, the 
value of this field has to remain frozen? I am thinking that in a 
small group I might start out as "jb" but if later the clinic or 
surgery is joined by Jack A Burak there may be value to my becoming 
"jrb" and Jack becoming "jab".

Is the value of "sign" written into clinical records, or does it 
exist only in the staff table, to be used purely in the construction 
of views?

> At 12:13 AM +0100 1/19/06, Karsten Hilbert wrote:
> >  > the extra staff not null details, such as staff role and sign ( 
> > which I asssume
> >  > you can cut and paste a rsa public key, much like savannah does ) .
> >
> > Nope, sign is intended for a short "call-sign" thingy, eg
> > "Leonard McCoy" has "LMcC". This is used where we need a short
> > signum for the provider. Please suggest a better term, anyone.
>
> Maybe consider
>
> short_name
> short_form
> user_initials
> unique_initials
>
> So far, I have not seen in the schema wiki-like spellings for field 
> names, for example shortName or uniqueInitials. So probably best to 
> not start using them mid-process, even if postgres would tolerate 
> them?