Re: How to make Subst run?, posted by Andreas Luedeke on Fri Sep 3 14:14:07 2010
|
| Robert Heine wrote: | Dear colleagues,
I tried to get an Subst <attrib> = $shell(<command>) to work and put this into a Preset text line, like e.g.:
Attributes = subject, ...
Options <name> = test{1}, ...
Subst myvar = $shell(dir)
{1} Preset subject = Test
{1} Preset text = $myvar
Which results in an ELOG-entry having printed "$myvar" in its body instead of the expected substitution. Changing the Subst command to: "Subst myvar = $host" or even to "Subst myvar = Test" also resulted in printing just the string "$myvar" into the submitted Elog-entry. - What am I doing wrong? |
What you want to do is done simply by:{1} Preset text = $shell(dir)You expect "Subst" to create new variables, but it cannot do this.
"Subst" can overwrite the value of an existing field in an already submitted entry, while
"Preset" allows to prefill an existing entry field and the user may overwrites it before submitting (if it is not "Locked".)
In both cases you can either call a shellscript to create the desired text, or you can use
one of the predefined variables defined in the help pages "ELOG - Syntax of elogd.cfg" for "Subst".
Cheers Andreas |
|
Re: Elog v2.7.8 does not show substituted attributes while editing or replying, posted by Andreas Luedeke on Fri Sep 3 14:25:37 2010
|
| Dennis Seitz wrote: |
|
Since we updated to 2.7.8 we've found a problem.
Previously, when we used
Subst on reply subject = Re: $subject
The new "Re: " text would appear in the "subject" field while the user was editing their reply, and they could edit or delete it.
Since 2.7.8, however, it does not appear while editing, but shows up only after the user submits their entry. We would prefer that this appears while the user is editing, because in some cases we want the users to have the option to modify this text. Was this intentional? Is there a way to restore the previous functionality?[...]
|
Sorry, that appears to be an undocumented bug fix :-)
The desired behaviour should be created by
Preset on reply subject = Re: $subject
The command "Subst" is supposed to overwrite the field after it is submitted.
From the documentation you will even find a nicer possibility:
Preset on first reply Subject = Re: $Subject
The prevent replies to build a long chain of "Re: Re: Re: ...."
Cheers Andreas |
|
Re: Synchronizing mirror causes corruption of logbook entries with multiple logbooks defined?, posted by Andreas Luedeke on Fri Sep 3 14:43:16 2010
|
| Glenn Horton-Smith wrote: |
|
We have been experiencing corruption of logbook entries by elogd mirror synchronization. Has anyone else encountered this? Is there a known cause and/or workaround for it? [...]
I made copies of both servers' files and ran two elogd servers on my Mac on different ports, compiled from a fresh checkout of 2.8.0, and the same behavior was observed as I repeatedly made test entries and synchronized. This suggests it isn't specific to Linux architecture, 64-bit or otherwise.
|
We plan to use ELOG with mirror servers in a larger scale here, so I'm interested to know more about your problem.
Could you boil down your configuration to a minimum that still allows a reproduction of the problem and post those configurations as attachments?
Then I would try to reproduce it here. Best case I'll find a bug fix, worst case I'll reconsider the use of mirror servers ;-) |
Found some spelling errors in eloglang.german, posted by Andreas Luedeke on Thu Jan 13 10:07:17 2011 
|
corrected file is attached |
|
elog command creates always UTF-8 encoded entries, posted by Andreas Luedeke on Wed Jan 19 13:30:48 2011
|
If I create an entry via the web-interface, the defined encoding of the browser is used.
If I create an entry via "elog", it is always stored in UTF-8 encoding.
For the text I can overcome that with HTML encoding, but for attribute values the encoding does not show properly.
The only solution I found was to convert the whole logbook to UTF-8 encoding:
define "charset=UTF-8" in elogd.cfg
iconv --from-code=ISO-8859-1 --to-code=UTF-8 elogd.cfg >tmp;mv tmp elogd.cfg
iconv --from-code=ISO-8859-1 --to-code=UTF-8 resources/eloglang.german >tmp;mv tmp resources/eloglang.german
Has anyone any idea why ISO8859-1 does not work for me?
Or can anyone advice me of an editor similar to NEdit that is capable to display UTF-8? :-) |
Re: Attributes for message workflow., posted by Andreas Luedeke on Wed Mar 30 13:46:01 2011
|
| Ryan wrote: |
|
[...] I am even open to losing the historical "status" and beeing able to change all entries on the thread on reply. (i.e. Reply #4 changes "Status" to "Approved", and the system changed all entries in the thread to "Approved")
|
One possibility is to use the new 2.9.0 feature "Propagate attributes = OPS Approval, ENG Approval, Director Approval"
A change in any of the three listed attributes would propage to the corresponding fields of all former entires of the same thread.
So if someone creates a reply and changes "OPS Approval" to "Approved", the field "OPS Approval" of the original entry would go as well to "Approved".
I just happen to know about this feature because Stefan implemented it for me :-) |
|
Re: Creating a form or table, posted by Andreas Luedeke on Fri Apr 1 14:15:45 2011
|
| Terry Shuck wrote: |
|
Is there a way to open a form or table when clicking on New rather than going to a text field? Thanks, TS!
|
Hi Terry,
it is not exactly clear to me what you want.
You can define many different types of attributes to an entry.
Like this logbook has "Icon", "Author", "Author Email", "Category", ...
That automatically creates a form for the input.
Or you can have some pre-filled text in the text area, like a pre-defined table.
E.g. with the following line:
Preset Text = input-form.html
Every new entry will now contain the content of the file input-form.html
which could be some table or list, ... |
|
elogd crashes when running mirror cron with SSL and KRB5, posted by Andreas Luedeke on Mon May 30 12:28:53 2011
|
When I run a mirror server and both logbooks using SSL/KRB5 then the cron job causes a segmentation fault.
I haven't tried to check it with a simple configuration yet.
My set-up: two elogd on same server, one running "german" on port 444, the other "english" on port 445.
Both are behind an apache webserver configured reverse proxy, to hide the ports for external access.
I'll try to reproduce the fault with a "minimal configuration" soon and report again.
Debug output from GDB:
run -x -c /usr/local/elog/elogd_en.cfg
Starting program: /opt/elog-2.9.0/elog/elogd -x -c /usr/local/elog/elogd_en.cfg
elogd 2.9.0 built May 30 2011, 11:14:32 revision 2414
File "/var/run/elogd.pid" exists, using "/var/run/elogd.pid.445" instead.
Falling back to default group "elog"
Falling back to default user "elog"
User "elog" not found
Falling back to default user "nobody"
FCKedit detected
Falling back to default group "elog"
Falling back to default user "elog"
User "elog" not found
Falling back to default user "nobody"
ImageMagick detected
Indexing logbooks ... done
SSLServer listening on port 445 ...
Program received signal SIGSEGV, Segmentation fault.
0x0030b7b5 in SSL_write () from /lib/libssl.so.6 |