Demo Discussion
Forum Config Examples Contributions Vulnerabilities
  Discussion forum about ELOG, Page 47 of 806  Not logged in ELOG logo
ID Date Icon Author Author Email Categorydown OS ELOG Version Subject
  66057   Mon Nov 17 12:20:17 2008 Reply Stefan Rittstefan.ritt@psi.chRequestLinux2.7.5Re: Sorting Museremail

 

Steve Williamson wrote:

 

Stefan Ritt wrote:

 

Steve Williamson wrote:

Hi

I've just upgraded to 2.7.5 mainly because I wanted to have Museremail sorted.  We use this to list contacts on an RFC form and it's much easier to find the ones you want when they are in a predictable sequence.  As an extension to this it would be great if they could be sorted by the last part of their real name - typical user, give him a sweetie and he wants jam on it!

cheers

Steve

 

 That's a bit hard since different groups enter their names differently. While for a human it's easy to figure out what the family name is (usually), this must not be true for a computer. So I would propose that you enter the real names in the sequence family name, given name like

Ritt, Stefan
Doe, John

then sorting will work as you like.

 

 Good point! However, the current sorting appears to be done on email address rather than name.  Having the option to sort on name, where we are in control of the format so could structure it accordingly, would be great.

regards

Steve

 

 Can you give me an example on how names an email addresses look in your case? If the email address has no fix relation to the real name, I personally find it much harder to find an email address on a Muserlist, since the real name is not shown there. I guess what you really want is a display of the email addres in the form

real name <email address>

then sort by real name. Right?

  66058   Mon Nov 17 13:03:19 2008 Reply Steve WilliamsonStephenWilliamson@Barnsley.gov.ukRequestLinux2.7.5Re: Sorting Museremail

Stefan Ritt wrote:

 

Steve Williamson wrote:

 

Stefan Ritt wrote:

 

Steve Williamson wrote:

Hi

I've just upgraded to 2.7.5 mainly because I wanted to have Museremail sorted.  We use this to list contacts on an RFC form and it's much easier to find the ones you want when they are in a predictable sequence.  As an extension to this it would be great if they could be sorted by the last part of their real name - typical user, give him a sweetie and he wants jam on it!

cheers

Steve

 

 That's a bit hard since different groups enter their names differently. While for a human it's easy to figure out what the family name is (usually), this must not be true for a computer. So I would propose that you enter the real names in the sequence family name, given name like

Ritt, Stefan
Doe, John

then sorting will work as you like.

 

 Good point! However, the current sorting appears to be done on email address rather than name.  Having the option to sort on name, where we are in control of the format so could structure it accordingly, would be great.

regards

Steve

 

 Can you give me an example on how names an email addresses look in your case? If the email address has no fix relation to the real name, I personally find it much harder to find an email address on a Muserlist, since the real name is not shown there. I guess what you really want is a display of the email addres in the form

real name <email address>

then sort by real name. Right?

We currently have 24 users set up which, using a normal font size, takes 6 lines to display Museremail.  Having realname+emailaddress would double the space - a bit much for us but may suit other users. 

You ask about how our email addresses look.  These are very simple, e.g. John Smith's email address would be "JohnSmith@mycompany.co.uk".  The are some exceptions, e.g. one or two people have a middle initial,or have a department name as a suffix and some people have abbreviated names because that is how they are known, so John's brother Joseph, known as Joe, might be JoeSoap@mycompany.co.uk and one or two users have a different domain.  So the ordering looks a bit odd sometimes, e.g.:

* StanleySmith@mycompany.co.uk * StellaEvans@mycompany.co.uk * StephenJones@mycompany.co.uk * StephenSmith@myothercompany.co.uk

* SterlingGold@mycompany.co.uk * SteuartEvans@mycompany.co.uk  * SteveSmythe@mycompany.co.uk * SylviaJones@mycompany.co.uk ...

where Steve Smythe has shifted down the ranks because of the abbreviation. 

However, the main reason for the request was that the I was so pleased with the ordering introduced in 2.7.5 but, as it is more normal for me  to look down a list of names ordered by last-name/first-name than the other way about, I thought it worth asking if there was any way to do this sensibly.  I appreciate that it isn't simple and what suits me may well not suit others - so thanks for taking time to consider the possibilities.  I guess the only real solution is to define users differently, e.g. by structuring the name data into first name(s) and last name (not a global solution but would suit most of western europe and the USA at least!) but that is bound to have lots of impacts both on the application and on existing setups - so not really feasible, and probably not worth the disruption.

regards

Steve

 

 

  66060   Tue Nov 18 09:13:26 2008 Reply Stefan Rittstefan.ritt@psi.chRequestLinux2.7.5Re: Sorting Museremail

 

Steve Williamson wrote:

 

However, the main reason for the request was that the I was so pleased with the ordering introduced in 2.7.5 but, as it is more normal for me  to look down a list of names ordered by last-name/first-name than the other way about, I thought it worth asking if there was any way to do this sensibly.  I appreciate that it isn't simple and what suits me may well not suit others - so thanks for taking time to consider the possibilities.  I guess the only real solution is to define users differently, e.g. by structuring the name data into first name(s) and last name (not a global solution but would suit most of western europe and the USA at least!) but that is bound to have lots of impacts both on the application and on existing setups - so not really feasible, and probably not worth the disruption.

 

 That's correct. Adding first name(s), last name(s) requires major modifications which are not se easy and I don't have time for that in the moment. So we'll keep it for the time being.

  66062   Thu Nov 20 10:29:39 2008 Reply Steve WilliamsonStephenWilliamson@Barnsley.gov.ukRequestLinux2.7.5Re: Sorting Museremail

Stefan Ritt wrote:

 

Steve Williamson wrote:

 

However, the main reason for the request was that the I was so pleased with the ordering introduced in 2.7.5 but, as it is more normal for me  to look down a list of names ordered by last-name/first-name than the other way about, I thought it worth asking if there was any way to do this sensibly.  I appreciate that it isn't simple and what suits me may well not suit others - so thanks for taking time to consider the possibilities.  I guess the only real solution is to define users differently, e.g. by structuring the name data into first name(s) and last name (not a global solution but would suit most of western europe and the USA at least!) but that is bound to have lots of impacts both on the application and on existing setups - so not really feasible, and probably not worth the disruption.

 

 That's correct. Adding first name(s), last name(s) requires major modifications which are not se easy and I don't have time for that in the moment. So we'll keep it for the time being.

 That's fine.  Thanks for listenening - and for keeping on with elog

regards

Steve

 

 

  66103   Tue Dec 9 00:25:52 2008 Idea Dennis Seitzdseitz@berkeley.eduRequestAll2.7.5Please add Subst on Duplicate

 I would like to be able to substitute some attribute values when an entry is duplicated. I don't see Subst on Duplicate available in the cfg file syntax. Can you add that?

 

Thanks

  66104   Tue Dec 9 08:04:00 2008 Reply Stefan Rittstefan.ritt@psi.chRequestAll2.7.5Re: Please add Subst on Duplicate

 

Dennis Seitz wrote:

 I would like to be able to substitute some attribute values when an entry is duplicated. I don't see Subst on Duplicate available in the cfg file syntax. Can you add that?

 

Subst on Duplicate does not make sense. Subst always works after you submit an entry, while Preset works before you enter the entry. When you Duplicate an entry, it looks like a new one, just with attributes and text from another entry. So when you submit that one, the system cannot distinguish if you entered a new one by yourself or if this is based on a copy of another entry. So what you probably need is Preset on duplicate.

  66105   Wed Dec 10 03:11:01 2008 Reply Dennis Seitzdseitz@berkeley.eduRequestAll2.7.5Re: Please add Subst on Duplicate

 

Stefan Ritt wrote:

 

Dennis Seitz wrote:

 I would like to be able to substitute some attribute values when an entry is duplicated. I don't see Subst on Duplicate available in the cfg file syntax. Can you add that?

 

Subst on Duplicate does not make sense. Subst always works after you submit an entry, while Preset works before you enter the entry. When you Duplicate an entry, it looks like a new one, just with attributes and text from another entry. So when you submit that one, the system cannot distinguish if you entered a new one by yourself or if this is based on a copy of another entry. So what you probably need is Preset on duplicate.

Thanks for explaining.

I thought Preset would work with Duplicate since Duplicate creates a new entry, but it didn't. Then I tried Subst because Duplicating an entry opens it in Edit mode, so you are in effect Duplicating, and then Editing the entry. It just didn't occur to me to look for Preset on Duplicate.

  66107   Thu Dec 11 17:50:35 2008 Disagree Richard Stamperr.stamper@rl.ac.ukRequestWindows2.7.5-2140Conflict between Select-Edit and attribute types

When doing a Select->Edit operation, if an attribute has a type of "numeric" and the records selected already have (some) values for that attribute, then the "- keep original values -" message that is inserted to indicate that the values should be preserved causes the type check to fail.

Would it be possible to modify the Javascript that carries out the type check to treat the "- keep original values -" message as an exception?

ELOG V3.1.5-3fb85fa6