ID |
Date |
Icon |
Author |
Author Email |
Category |
OS |
ELOG Version |
Subject |
66013
|
Thu Oct 23 11:45:51 2008 |
| T. Ribbrock | emgaron+elog@ribbrock.org | Question | All | 2.7.5-2130 | Re: (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 |
66024
|
Thu Oct 30 04:17:09 2008 |
| Stefan Ritt | stefan.ritt@psi.ch | Question | All | 2.7.5-2130 | Re: (How) can I hide columns in List view? |
T. Ribbrock wrote: |
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
|
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.
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. |
66028
|
Thu Oct 30 09:44:25 2008 |
| T. Ribbrock | emgaron+elog@ribbrock.org | Question | All | 2.7.5-2130 | Re: (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 |
66029
|
Thu Oct 30 11:05:11 2008 |
| T. Ribbrock | emgaron+elog@ribbrock.org | Question | All | 2.7.5-2130 | Re: (How) can I hide columns in List view? |
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.
|
I take it you mean the "Subdir" option (the manual mentions "Data dir" as obsolete)? I tried it with that and it works like a charm - gives me now two logbooks, i.e. two tabs with the same data and two different views - which is precisely what we need. Thanks!
Regards,
Thomas |
66069
|
Fri Nov 21 18:21:36 2008 |
| Dennis Seitz | dseitz@berkeley.edu | Question | All | latest | Re: Re: $entry time not readable by Subst, else not datetime type? - possible Preset bug? |
Dennis Seitz wrote: |
Stefan Ritt wrote: |
Dennis Seitz wrote: | Do you mean '$entry time', or did you create a new parameter? (I don't see $entry date in the elogd.cfg reference) |
Yes, of course I mean '$entry time', sorry for the misspelling. |
Well, we really appreciate the way you keep adding features and making improvements. I thought you might have slipped a new one in! |
FYI, I think there's a little bug in the datetime vs $date implementation.
Here's a section of my config file implementing a "Last Edit" field:
Type Last Edit = datetime
Preset Last Edit =$date
Locked Attributes = Last Edit
Subst on edit Last Edit = $date
Start page = ?rsort=Last Edit
I expected that "Preset Last Edit =$date" would set Last Edit to the current date when I create a new entry. In fact that leaves the field empty, or at least not in datetime format.
I found that using this instead works:
Preset Last Edit =$entry time
which seems contradictory since
Subst on edit Last Edit = $date
works fine. |
66079
|
Mon Nov 24 20:00:05 2008 |
| Stefan Ritt | stefan.ritt@psi.ch | Question | All | latest | Re: Re: $entry time not readable by Subst, else not datetime type? - possible Preset bug? |
Dennis Seitz wrote: | FYI, I think there's a little bug in the datetime vs $date implementation.
Here's a section of my config file implementing a "Last Edit" field:
Type Last Edit = datetime
Preset Last Edit =$date
Locked Attributes = Last Edit
Subst on edit Last Edit = $date
Start page = ?rsort=Last Edit
I expected that "Preset Last Edit =$date" would set Last Edit to the current date when I create a new entry. In fact that leaves the field empty, or at least not in datetime format.
I found that using this instead works:
Preset Last Edit =$entry time
which seems contradictory since
Subst on edit Last Edit = $date
works fine. |
Do you have an old version of elog? Using the current version with a configuration file:
Attributes = Author, Type, Last Edit
Type Last Edit = datetime
Preset Last Edit =$date
Locked Attributes = Last Edit
Start page = ?rsort=Last Edit
I get the correct behavior:
 |
66080
|
Tue Nov 25 17:01:55 2008 |
| Dennis Seitz | dseitz@berkeley.edu | Question | All | 2.7.3 | Re: Re: $entry time not readable by Subst, else not datetime type? - possible Preset bug? |
Stefan Ritt wrote: |
Dennis Seitz wrote: | FYI, I think there's a little bug in the datetime vs $date implementation.
Here's a section of my config file implementing a "Last Edit" field:
Type Last Edit = datetime
Preset Last Edit =$date
Locked Attributes = Last Edit
Subst on edit Last Edit = $date
Start page = ?rsort=Last Edit
I expected that "Preset Last Edit =$date" would set Last Edit to the current date when I create a new entry. In fact that leaves the field empty, or at least not in datetime format.
I found that using this instead works:
Preset Last Edit =$entry time
which seems contradictory since
Subst on edit Last Edit = $date
works fine. |
Do you have an old version of elog? Using the current version with a configuration file:
Attributes = Author, Type, Last Edit
Type Last Edit = datetime
Preset Last Edit =$date
Locked Attributes = Last Edit
Start page = ?rsort=Last Edit
I get the correct behavior:
 |
Yes, I'm using 2.7.3 - I'll try upgrading, sorry. I'll reply with the outcome. |
66102
|
Tue Dec 9 00:22:41 2008 |
| Dennis Seitz | dseitz@berkeley.edu | Question | All | 2.7.5 | Re: Re: $entry time not readable by Subst, else not datetime type? - possible Preset bug? |
Dennis Seitz wrote: |
Stefan Ritt wrote: |
Dennis Seitz wrote: | FYI, I think there's a little bug in the datetime vs $date implementation.
Here's a section of my config file implementing a "Last Edit" field:
Type Last Edit = datetime
Preset Last Edit =$date
Locked Attributes = Last Edit
Subst on edit Last Edit = $date
Start page = ?rsort=Last Edit
I expected that "Preset Last Edit =$date" would set Last Edit to the current date when I create a new entry. In fact that leaves the field empty, or at least not in datetime format.
I found that using this instead works:
Preset Last Edit =$entry time
which seems contradictory since
Subst on edit Last Edit = $date
works fine. |
Do you have an old version of elog? Using the current version with a configuration file:
Attributes = Author, Type, Last Edit
Type Last Edit = datetime
Preset Last Edit =$date
Locked Attributes = Last Edit
Start page = ?rsort=Last Edit
I get the correct behavior:
 |
Yes, I'm using 2.7.3 - I'll try upgrading, sorry. I'll reply with the outcome. |
Everything works fine with 2.7.5, thanks! |
|