Demo Discussion
Forum Config Examples Contributions Vulnerabilities
  Discussion forum about ELOG, Page 226 of 796  Not logged in ELOG logo
ID Date Icon Author Author Emailup Category OS ELOG Version Subject
  65947   Fri Aug 8 14:50:56 2008 Reply T. Ribbrockemgaron+elog@ribbrock.orgQuestionLinux2.7.4-2111Re: Using the command line tool to edit

Yoshio Imai wrote:

T. Ribbrock wrote:
NOTE: I found that this does not work if LOGBOOK has any spaces in it - I would get error messages where the logbook was not found.


You might try to escape the space in the form
elog -a 'Attribute1=value' -x -h localhost -l 'LOG\ BOOK' -p 8080 -u USER PASSWD


I forgot to mention that I tried both 'LOG\ BOOK' and 'LOG%20BOOK' - neither worked. Running elog with -v seemed to indicate in both cases that the correct logbook could not be found.



Yoshio Imai wrote:

T. Ribbrock wrote:
What is the easiest way to retrieve an ID from the command line

I don't know if this helps you (depends on how much the application that edits the entry communicates with the application the generates the entry), but the elog client should output something like
Message successfully transmitted, ID=12345
which you could e.g. redirect into a file that the editing application then reads to determine the ID.


Good point, thanks - I'll have to generate some kind of mapping table (ID<->Attribute) when the logbook gets populated, but that should be possible. It would be very cool, though, if elog was able to identify an entry by attribute value - maybe something for a day when Stefan gets bored... Wink

However, none of this will have any relevance unless I can solve the non-working "edit" function... Frown
  65950   Mon Aug 11 15:14:40 2008 Reply T. Ribbrockemgaron+elog@ribbrock.orgQuestionLinux2.7.4-2111Re: Using the command line tool to edit
Stefan Ritt wrote:

I fixed two things:

  • The logbook can now contain a space. Enclose it in double quotes such as elog -l "LOG BOOK" ...
  • The error you report comes from the fact that you are the first person using elog submissions together with "use lock=1" in the configuration file. This has never been tested and therefore does not work . So I fixed this by adding a new hidden parameter. If you update to SVN revision 2122, things should work

Tehe, leave it to us "stupid users" to break your nice little program in new and exiting ways... ;-) But: THANK YOU! Both things are indeed working now - that brings me one step closes to my automated logbook, which is great!

 

Stefan Ritt wrote:

Concerning your request of editing existing entries by their idea, I agree with Yoshi that you could grab the ID upon the first submission. An alternative is to make a direct search on a logbook. Since this is not implemented in the elog command line tool, you have to use wget for it:

wget "http://localhost:8080/LOGBOOK/?mode=raw&Attribute1=something" -O elog.txt

A problem here is that the username and password are normally transmitted in an encrypted form as cookies by your browser after you logged in. Now you have to convince wget first to log in like

wget "http://localhost:8080/LOGBOOK/?unamee=USER&upassword=PASSWD"--save-cookies cookies.txt

followed by a second call to wget with --load-cookies cookies.txt. I tried that but was not successful since the login procedure above redirects to the elog listing page, and only the cookies set after the redirection were saved in cookies.txt. Maybe you can figure out how to do that. The only way I could get it to work is to supply the encoded password, which I manually obtained from the password file. The URL was then

wget "http://localhost:8080/LOGBOOK/?mode=raw&Attribute1=something&unm=USER&upwd=ENC_PWD" -O elog.txt

I thought about grabbing the ID on first creation. The problem with that is that I really would have to run parallel "databases" - one in elog to keep the information I want plus a second one which maps the elog-IDs to the "real" IDs - and the second one would also have to deal with things like "ID exists", "ID doesn't exist", "ID gets deleted" and so on - just the kind of hassle I want to avoid. But what you suggest with wget will most likely be sufficient. The logbook in question is readable for everyone (only editing/writing requires authentication), so I can search without password hassle. In fact, this will work:

 

wget -q "http://localhost:8080/LOGBOOK/?mode=raw&Attribute1=something" -O -| grep '\$@MID'|awk '{print $2}'

Et voila, I have an ID. This will generate a bit more traffic than a parallel "DB", but I think it will be less susceptible to errors, as all information is kept within the elog logbook at all times. Thanks again for your help - time to do some scripting! :-)

  66000   Mon Oct 13 15:24:29 2008 Warning T. Ribbrockemgaron+elog@ribbrock.orgBug reportLinux2.7.5-2130Options selections wipes locked date entry

I have two logbooks running, one for current accounts and one for non-active ones. The idea is to move an entry from one logbook to the other once an account becomes non-active. Both logbooks share some attributes (e.g. the name of the account, its creation date, ...), but both also have some uniqe attributes.

While I was playing with this set-up, I ran into a problem:

  1. Move an existing entry from current to non-active.
    • "Type" and "Status" have options. "Created" and "Archived" are in date format.
    • "Created" and "Type" are supposed to be locked in non-active. This works.
    • "Archived" and "Status" are empty, as they do not exist in current. This also works.
    • Depending on the "Type", only certain of the additional attributes are shown on edit. This works as well.
    • I would also like "Status" to have some influence on how certain other attributes are preset and/or shown. This is where the problem starts...
  2. Edit the entry in current.
    • As expected, "Created" and "Type" are shown as locked.
    • As soon as I change the selector for "State", the whole edit mask is redrawn - and the date shown in "Created" is deleted.

I've been experimenting with this quite a while and as far as can see the following applies:

  • Only date format attributes are affected
  • Only locked attributes seem to be deleted completely
  • If I have a date attribute that is not locked and I set it partially in the edit mask (e.g. only select the month or enter a year), it is also deleted
  • If I have a date attribute that is not locked and I set it completely in the edit mask (i.e. day, month and year), it is not deleted

During the experiments I came up with a stripped down version of the non-active logbook configuration, which does show the bug. It only contains Type, Created, Status, Archived. To make an entry to experiment, you'll have to comment out the "Locked attributes" line, make a new entry (with "Created" date), the uncomment that line.

I hope my description isn't too confusing - please don't hesitate to ask if anything is unclear. I'd be much obliged if you saw a chance to fix this at some point...

Best regards,

Thomas

Attachment 1: elog-bug-test-config-20081013.txt
; General settings
Menu commands = List, New, Edit, Duplicate, Delete, Reply, Select, Move to, Download, Find, Logout, Help, Config
List Menu commands = New, Select, Find, Logout, Help, Config
Date Format = %d/%m/%Y

; Attributes
Attributes = Type, Created, Status, Archived
Locked attributes = Type, Created
List Display = Edit, Type, Created, Status, Archived

; Attribute Types
Type Created = date
Type Archived = date

; Options & Tooltips
Options Type = Type1{10}, Type2{11}
Options Status = Status1{a}, Status2{b}

; Conditionals
{10}Show Attributes Edit = Type, Created, Status, Archived
{11}Show Attributes Edit = Type, Created, Status
  66002   Tue Oct 14 10:29:34 2008 Question T. Ribbrockemgaron+elog@ribbrock.orgQuestionLinux2.7.5-2130"Style" based on two MOptions - possible?

We have a logbook in which we use two "Status" attributes, both of which are MOptions. What we want to do is have the corresponding line of the list change its colour depending on the combination of those attributes. I have done so successfully using "Style" for a single Options or MOptions or even two Options (using conditionals and a third attribute), but up until now I have no luck with two MOptions. Conditionals do not seem to work with MOptions (the manual only mentions Options and when I tried anyway, it did not work... ) and multiple "Style" statements also do not seem to work. I've tried the following:

MOptions StatusA = Status-A-red, Status-A-orange, Status-A
MOptions StatusB = Status-B-red, Status-B-orange, Status-B

Style StatusA Status-A-red = background-color:red
Style StatusA Status-A-red | Status-A-orange = background-color:red
Style StatusA Status-A-red | Status-A = background-color:red
Style StatusA Status-A-red | Status-A-orange | Status-A = background-color:red
Style StatusA Status-A-orange = background-color:orange
Style StatusA Status-A-orange | Status-A = background-color:orange
Style StatusB Status-B-red = background-color:red
Style StatusB Status-B-red | Status-B-orange = background-color:red
Style StatusB Status-B-red | Status-B = background-color:red
Style StatusB Status-B-red | Status-B-orange | Status-B = background-color:red
Style StatusB Status-B-orange = background-color:orange
Style StatusB Status-B-orange | Status-B = background-color:orange

As far as I can see, the "Style" statement for StatusB only gets evaluated if none of the statements for StatusA matches (i.e. StatusA = Status-A). What I would want to achieve is that any "red" condition in either StatusA or StatusB takes precedence over "orange" and "none" and that "orange" takes precedence over "none".

Is there any solution for this problem short of merging both status attributes into one (which would be very unwieldy, especially, as StatusB is not used at all in some cases)? Any suggestions are most welcome!

Thanks in advance,

Thomas

  66008   Mon Oct 20 15:32:19 2008 Question T. Ribbrockemgaron+elog@ribbrock.orgQuestionAll2.7.5-2130(How) can I hide columns in List view?

Originally, all information about our machines was stored in a spreadsheet with one sheet for the hardware of the machines and one for the software. By now, I've sucessfully moved the software part to an elog logbook and am now looking at transferring the hardware part as well.

As both lists are machine-name based, one of the options would be to merge both lists, as this would place all machine-related info into one logbook. The downside of this is that I get so many columns in list view that the result is quite unwieldy. Hence, I would like to hide some columns - ideally creating a "hardware view" and a "software view".

From the documentation, the only option I could find that seemed suitable was "List conditions". Unfortunately, I do not quite understand from the manual how this is supposed to work, so I'm quite possibly doing something wrong. I've tried this:

; General settings
List conditions = 1

; Attributes
Attributes = Type, Created, StatusA, StatusB, Archived

; Options & Tooltips
Options Type = Type1{10}, Type2{11}

; Conditionals
{10}List display = Edit, Type, Created, Status
{11}List display = Edit, Type, Created, StatusA, StatusB, Archived

but no matter how I set "Type", it does not seem to have any effect on the List display. One thing I don't understand for example is how does elog decide in List view which entry sets the condition? If all entries are set to the same value (in this example e.g. "Type1")? The first entry? Or am I missing something altogether?

Also, if there are alternative ways how I could accomplish my goal, I'd also be most grateful for suggestions.

Thanks in advance,

Thomas

  66013   Thu Oct 23 11:45:51 2008 Disagree T. Ribbrockemgaron+elog@ribbrock.orgQuestionAll2.7.5-2130Re: (How) can I hide columns in List view?

T. Ribbrock wrote:
[...]

One thing I don't understand for example is how does elog decide in List view which entry sets the condition? If all entries are set to the same value (in this example e.g. "Type1")? The first entry? Or am I missing something altogether?

[...]

 By now, I'm one step further. List conditions = 1 does have some effect in some cases - the following works:

Options Type = Type1{10}, Type2{11}
Options StatusA = Status-A-red, Status-A-orange, Status-A
{10}Style StatusA Status-A-red = background-color:red
{11}Style StatusA Status-A-red = background-color:green

This seems to get evaluated "top-down", i.e. the value of "Type" in the first row in the list sets the handling of StatusA and the background-color, the second row for the third and so on. Unfortunately, this really only depends on the order of the rows on the screen - if I sort the list differently, I get a different result.

I am also quite certain that List conditions = 1 has no effect whatsover on List display - which is what I was hoping for.

Hence, I'd like to repeat my question: Is there any way to hide columns in List view (short of editing the conf file...) - and if so, how?

Regards,

Thomas

  66015   Mon Oct 27 12:42:47 2008 Disagree T. Ribbrockemgaron+elog@ribbrock.orgBug reportLinux2.7.5-2130Select -> Edit wipes dates

I just ran into the following bug:

I have a logbook where entries have several attributes, among which several dates. All of these are set to "Type <attr> = date". If I use the "Select" action, tag several entries and subsequently chose "Edit", the values of all date attributes are wiped. All other attributes are kept at their original values, unless changed explicitly. For the date entries, the date choosers are shown (as when editing a single entry), but all set to blank.

Editing single entries works fine.

  66028   Thu Oct 30 09:44:25 2008 Idea T. Ribbrockemgaron+elog@ribbrock.orgQuestionAll2.7.5-2130Re: (How) can I hide columns in List view?

Thanks for the response! BTW: I did get a notification - but thanks for the "personal heads-up"!

Stefan Ritt wrote:

 Indeed you got something wrong. The conditional attributes are meant for the input form, so you can turn some attributes on and off or choose different options for an attribute depending on the value of another attribute.

[...]

 I see. In that case, could you maybe please give a quick explanation what "List conditions" is supposed to do? In conjunction with your statement above I'm now thoroughly confused as to what it should/could be used for...

Stefan Ritt wrote:

[...]

The only way I see how you can achieve what you want is to define two separate logbooks, but serve them from the same directory (via the "Data dir" option). Both logbooks should share the same attribute definition, but use different "List display" options.

 Ah, that's an idea - I'll look into that. Thanks a mil for the suggestion!

Regards,

Thomas

ELOG V3.1.5-fe60aaf