ELOG Forum

Is it possible to derive the time in a 'date/time' attribute from the Elog server?
We would like all our entries in GMT/UTC time and unfortunately as the time is currently derived from the client machines there are often entry descrepancies if the regional settings are not set correctly.

The '$entry time' variable can be used but seems to put a 1970 date in the field so bears no relevancy to an 'Event' time?

I'm also having issues with conditional entries in the Find page. If a conditional statement is used to hide attributes or change displayed attributes in the entry page then the attribute that is used in the conditional statement is not permanently selectable in the 'Find' page. It is available as a choice but as soon as selected the conditional action removes it? Is it possible to make conditional options/actions in the 'Find' page optional?

Hope that makes a little sense?

Many thanks

There are several methods to get the server time:

Via presets of attributes

Attributes = Author, Event time, ...

Preset Event time = $utcdate

which gives you actually the UTC time.

Via the editor

The editor toolbar contains a little clock. If you click on it, you insert the current server time (but localized, not UTC).

Hope one of the two methods work for you.

The problem with the conditional attributes in the find page is I believe fixed in the current version.

Thanks Stefan, the preset UTC date works well. RTFM on my part perhaps.

I'm running version 2.7.5.2127 and am still having the issue with conditional attributes in the find area as mentioned above though.
Is it the latest SVN **.2135 that addresses this?

Many thanks

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

66087

Thu Nov 27 11:36:53 2008

T. Ribbrock

emgaron+elog@ribbrock.org

Bug report

Linux

2.7.5-2130

Re: Select -> Edit wipes dates

Stefan Ritt wrote:

This problem has been fixed in revision 2.7.5-2143. Please upgrade.

Yup, this works now - thanks a mil!

66280

Thu Mar 26 17:09:47 2009

Re: New column on main page

Stefan Ritt wrote:

Dinkel Markus wrote:

This is Ok but in wich file can i add this tag? In the .cfg-file?

Yes, this goes into the elogd.cfg file. Just add a line like:

[logbook]

Comment = OS-Version<br><i>192.160.0.1</i>

Then you will get something like this:

Thanks, this is great.

By, Markus

66380

Fri Jun 5 12:02:45 2009

David Pilgram

David.Pilgram@epost.org.uk

Question

Linux

2.7.6-2191

Re: Moving entry (and replies) from one log book to another

Thanks Stefan,  Downloading shortly and I'll let you know ;-)
> > Hi Stefan,
> > 
> > When Moving entry (and replies) from one log book to another, is it possible to prevent elog from renumbering
> > the entries' ID number(s) ($@MID@$).  While it may not be good practice, we've referred to these numbers in
> > cross-referencing, and it all goes wrong when an entry is moved from an "Open" thread to a "Closed" thread (cf
> > your FAQ about marking of whole threads).
> > 
> > In the cases I'm thinking about, i.e. from main logbook to archive logbook(s), there would never be a clash of
> > ID number.
> > 
> > Thanks,
> > 
> > David Pilgram.
> 
> I have implemented this feature in revision 2205. You need to set the new flag "Preserve IDs = 1" in the 
> configuration. I have not tested this extensively, but I'm sure you will do it ;-)

66432

Thu Jul 2 11:33:48 2009

David Pilgram

David.Pilgram@epost.org.uk

Question

Linux

2.7.6-2226

Re: Cancelling an Roption selection in Edit.

> > Hi Stefan,
> > 
> > I don't know if anyone else would be interested or need this...
> > 
> > If you have an Roption, and it is not required (maybe...) or have a preset attribute, it is possible to make an
> > entry and have replies without any of the attributes in that Roption being selected.
> > 
> > However, once an attribute in that Roption has been selected, it is not possible to go back (editing) to the
> > condition before one was selected on that entry (so far as I can tell).  
> > 
> > Is a way of cancelling all the possible attributes in an Roption practical?  Would others want it?  It is
> > possible with options, as there is a "please select" which can be used to cancel whichever attribute in the
> > option that has been selected.
> > 
> > Regards,  David
> 
> The easiest to achieve this is to define another option. Assume you have the three options
> 
> One, Two, Three
> 
> and you want to "unselect" them. So just add a fourth option like
> 
> Unspecified, One, Two, Three
> 
> so if you do not want any of the "One, Two, Three", just click on "Unspecified" and you get what you want.

This is sort of what I do now, I just wondered if there was a way of clearing that would leave the field completely
blank in the YYMMDDa.log file.

Thanks.

66482

Wed Jul 29 13:23:41 2009

T. Ribbrock

emgaron+elog@ribbrock.org

Bug report

Linux

2.7.6r2233

Re: Odd problem (bug?) with certain attribute

T. Ribbrock wrote:

Very nice, thank you! Given that I also still have to test the fix you made for the crash problem with "shared" logbooks (I assume it's also present in 2244), I'll upgrade and report back (probably tomorrow).

2244 is now running, and indeed, the "Size" attribute works now. Thank you!

Goto page Previous 1, 2, 3 ... 787, 788, 789 ... 799, 800, 801 Next

ELOG V3.1.5-3fb85fa6