I am not Stefan, but maybe I can add to this issue.

Personally I think it is not a good way to dump all the information into the text field and try to let the server parse it.
This could be archived more simply by using e.g. the python elog scripts or using the elog command tool to directly submit well structured elog entires.

As you have mentioned you could use the "execute new|edit|delete" commands to do the things you want to do.
Let the called script fetch the elog entry and alter it in the way you like and resubmit the entry.
(You have to make sure to don't generate a endless loop and you have to proably have to use a forwarding script as the elog "execute" command waits for finished execution).
This way you don't touch the 1500 characters limit of passing $text to the execute command.

Also the point "filling an attribute X with free text" needs some kind of (extended) parsing, which isn't possible with the subst command.
In our elog we such an attribute X, which is in some conditions filled with a set of other attributes and on other conditions just a normal input field, so the user could type custom text in.

"fill an attribute automatically with the character length of the text" could be done with the above mentioned execute command or it could be done on the clientside (e.g. browser using javascript or if automatically generated by a script, then directly by the script)

I hope it helps to build our application.
Best wishes,
Sebastian

Sure, attributes can be shown multi-line, but they cannot be stored in the elog internal database. The database is a very old design and only allows for single line attributes. Just look at a YYMMDDa.log file and you will see that. I would have to change the database format to somethign more advanced like XML, but that would take me a couple of weeks or months.

Soooorrryy! ;-)

Hi Stefan,
no problem: if I just strip all newlines from the $text field (in HTML you use <br> anyway, the newline has no function apart from whitespace), and my multiline attribute is fine to go.
I do not intend to make the attribute editable: it is just used for display. Because that allows me to create the attribute either from free text or from combining other fields - depending on conditional attributes.

As a special feature you could strip all newlines beforehand, when providing the $text for subst statements.

Cheers, Andreas

I should tell that I found a simpler way to achieve the same:
I suppress the "text" field and use a single line text input field instead.
The single line input in "free text" modes just contains "<br>" : I would have had to use those in the text field anyway.

Ive just been alerted to a bug with email notifications in Elog.

Basically if your log book contains a space then the URL that is sent in 
emails when creating tickets or updating old entries doesnt put %20 (IEs 
space) inthe URL it leaves a space hense breaking the link.

for example

Correct Way prior to 2.3.8

http://192.168.0.1:99/Provisioning%20Request/35

Broken way with new version

http://192.168.0.1:99/Provisioning Request/35
                                 ^
Link is broken at this point

My config looks like this

Email Status Assigned = $Owner@abc.co.uk
Email Status Re-Assigned = $Owner@abc.co.uk
Email Status Completed = $Requester@abc.co.uk
Email "Send Update Email" Yes = $Requester@abc.co.uk
Use Email Subject = A Provisioning Ticket has been assigned to you or 
completed
Use Email From = NetworkTeam@abc.co.uk

> Correct Way prior to 2.3.8
> 
> http://192.168.0.1:99/Provisioning%20Request/35
> 
> Broken way with new version
> 
> http://192.168.0.1:99/Provisioning Request/35

Exactly this problem has been fixed between 2.3.7 and 2.3.8, so can it be 
that you mixed up these two versions? To be precise, the fix happend in 
Revision 1.113 from 2003/06/04 08:17:35. So are you sure that you use a 
version of elogd after that modification? I tried to reproduce your problem 
with the official 2.3.8 version, but I got the correct result.

> > Correct Way prior to 2.3.8
> > 
> > http://192.168.0.1:99/Provisioning%20Request/35
> > 
> > Broken way with new version
> > 
> > http://192.168.0.1:99/Provisioning Request/35
> 
> Exactly this problem has been fixed between 2.3.7 and 2.3.8, so can it be 
> that you mixed up these two versions? To be precise, the fix happend in 
> Revision 1.113 from 2003/06/04 08:17:35. So are you sure that you use a 
> version of elogd after that modification? I tried to reproduce your 
problem 
> with the official 2.3.8 version, but I got the correct result.

Im using the plain RPM from 2.3.8, i uninstalled the 2.3.7 RPM before this 
upgrade, the only thing I kept was my own stylesheets and the config file.

One thing I just noticed is that if you dont have the URL statement set 
under global properties, some machines quote the hostname of the machine at 
which point this breaks the link. if you define the URL to the IP address 
the problem goes away.

However even without the URL setting undefined, it works for some people 
but not for others, I tried from 2 seperate machines and got 2 lots of 
results, so I suspect it might be DNS related somewhere along the lines.

> Im using the plain RPM from 2.3.8, i uninstalled the 2.3.7 RPM before this 
> upgrade, the only thing I kept was my own stylesheets and the config file.
> 
> One thing I just noticed is that if you dont have the URL statement set 
> under global properties, some machines quote the hostname of the machine at 
> which point this breaks the link. if you define the URL to the IP address 
> the problem goes away.
> 
> However even without the URL setting undefined, it works for some people 
> but not for others, I tried from 2 seperate machines and got 2 lots of 
> results, so I suspect it might be DNS related somewhere along the lines.

The only place I can see this problem could arise from is the "Referer:" 
statement in the HTTP header. This is sent by the browser to elogd, so if the 
included URL contains a blank, this could cause the problem in case no "URL" 
statement is present in elogd.cfg. Can you please run "elogd -v" to see the 
communication betwen elogd and your browser and check this? Maybe it depends 
from the browser, or even from the history of previous accesses. If you 
confirm that the "Referer:" statement contains blanks, I can put in a fix.