Very good idea! I changed that in ELOG V2.7.5-2139. The fix will be contained in the next release.

Have you tried Thumbnail size = xxx in your config file?

elog -v -h my.apache-proxy.server -d elog -l Accelerator -p 443 -s -u johndoe xxxxx -a Category=LN -a Subject=Test -a Author=IDoNotExist -n 1 -m entry.txt 
(johndoe is an existing user)

 

The entry is created with "IDoNotExist" as the Author name, instead of the correct name for the user johndoe,
and the Author Email attribute is blank.

Is there a way to enforce preset and locked attributes in the elogd server? (As a client could connect
with any arbitrary software, not just elog.)

Indeed "preset" and "locked" attributes are not obeyed if entries are submitted via the elog tool. The is because if you use a browser, the input form is created by elogd. If you use a locked attribute, the input filed for that attribute is not shown for example. If you use the elog tool, it directly submits an entry not knowing anything about the input form. To make this work, elog would first have to request the input form, then interprete all the HTML, figure out if an attribute is locked or not, then display an error if you try to submit that attribute. Since parsing of HTML is not implemented in elog, this is currently not possible. 

Originally I thought that this is not such a problem. Mostly elog is used to produce some automatic entries, where the authorship is of minor interest. But I guess you are afraid that one use could submit an entry under another user's name, right? Well, I hoped that in scientific collaborations nobody is that evil ;-)

Well, I will try to do something here in order to fix this. Will come back to you.

Actually I found a way around. The "Subst xxx" is evaluated after you submit an entry, so it also works for the elog tool. So all you need in your config file is:

Subst Author = $long_name

and it will do the job.

> I'm actually using elog on Debian and have been rolling my own ".deb" for a while now (starting with the old 
Debian
> Maybe you could add the Debian /etc/init.d/elog script to the "contrib"
> directory, with a suitable note in the README or something like that? That script has not changed in a long 
time and
> is still functional - and doing so would make it easier for people who would like to install elog on a Debian 
(or
> Debian-based, e.g. Ubuntu) system. I'll attach the script.

The problem is not putting this into the "conrib" area, but supporting it. Since I don't have a Debian system, 
may I suggest that you put it yourself into the elog:Contributions/ logbook. If people then get problems in the 
future, they can contact you directly ;-)

Ritt, Stefan

Doe, John

 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

Ritt, Stefan

Doe, John

 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?

Ritt, Stefan

Doe, John

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