ID |
Date |
Icon |
Author |
Author Email |
Category |
OS |
ELOG Version |
Subject |
228
|
Wed Feb 19 09:47:32 2003 |
| Stefan Ritt | stefan.ritt@psi.ch | Question | | | Re: Postdating the Entry Date |
> Is is possible to postdate the Entry Date for an entry?
>
> The documentation lists the ability to forward date an entry, but I don't
> see any ability to backdate an entry (edit the date to a date in the past).
>
> Given that the entry date is part of the logbook entry file structure, it
> wasn't obvious how to make this change.
The date is part of the logbook entry file structure because it's considered
as a "stamp" which cannot be changed, so to document the real date when the
message was written. In some installations this is very important.
If you need to change the date more freely, I would recommend to add another
attribute which can be changed at will. Up to now this has to be a string
variable so users have to make sure to enter the date in proper format, but
you can prepopulate that with the current date like:
Attributes = Author, ..., Real date
Preset Real date = $date
This way the current date occurs in that field, but can be changed
(backdated).
Note that the entry date can be changed directly in the YYMMDDa.log files in
the data directory, if one has write access there and the elogd daemon is not
running. |
227
|
Wed Feb 19 09:37:30 2003 |
| Stefan Ritt | stefan.ritt@psi.ch | | | | Re: Participation on development of ELOG |
> We are interested in using your ELOG (which we consider to be a wonderful
> application) even more. We would like to make a few adaptations in your
> source code, above all to add some functionality that we are missing.
>
> I was wondering if there is a way we could coordinate the development
> together. For instance, would it be of your interest to receive the code
> adaptations we do and implement it in your future releases?
Sure, I'm very interested in those and ready to merge it into the main
development tree.
- Stefan |
226
|
Wed Feb 19 09:26:04 2003 |
| Tomas Rudolf | tomas@mba.be | | | | Participation on development of ELOG |
Stefan,
We are interested in using your ELOG (which we consider to be a wonderful
application) even more. We would like to make a few adaptations in your
source code, above all to add some functionality that we are missing.
I was wondering if there is a way we could coordinate the development
together. For instance, would it be of your interest to receive the code
adaptations we do and implement it in your future releases?
To be more specific, for the moment we are really interested in
implementing the SHELL script execution on the server (I noticed it is in
your wishlist).
Best regards,
Tomas Rudolf
Micro Belgium Application |
225
|
Wed Feb 19 01:46:03 2003 |
| Fred Hooper | fhooper@sushisoft.com | Question | | | Postdating the Entry Date |
Is is possible to postdate the Entry Date for an entry?
The documentation lists the ability to forward date an entry, but I don't
see any ability to backdate an entry (edit the date to a date in the past).
Given that the entry date is part of the logbook entry file structure, it
wasn't obvious how to make this change.
thanks
fred |
224
|
Tue Feb 18 09:21:34 2003 |
| Stefan Ritt | stefan.ritt@psi.ch | | | | Re: New Version |
> I noticed the site has been updated as far as the documentation for 2.3.1,
> however the latest version in the downloads section is 2.3.0, any other
> places where I can get 2.3.1
>
> Cheers
Patience, patience! 2.3.1 is currently kind of in "beta" version, but will be
released this week. Not that you can always get the latest snapshot from the
CVS tree at
http://midas.psi.ch/cgi-bin/cvsweb/elog/src/elogd.c
- Stefan |
223
|
Tue Feb 18 08:07:10 2003 |
| Nick | nikc@cnic.com | | | | New Version |
I noticed the site has been updated as far as the documentation for 2.3.1,
however the latest version in the downloads section is 2.3.0, any other
places where I can get 2.3.1
Cheers |
222
|
Wed Feb 12 19:54:21 2003 |
| Stefan Ritt | stefan.ritt@psi.ch | Question | | | Re: Lost features since upgrade to 2.3.0 |
> When will you have 2.3.1 out? I just upgraded to 2.3.0 and would like to
see
> the links in my summary view. If it is going to be out soon I will wait
> instead of compiling from source.
2.3.1 will come out next week, since this week I'm at home. But you always
can get the sources from CVS (see below).
> > The modification will come in 2.3.1, or you can get the source code from
CVS
> > under
> >
> > http://midas.psi.ch/cgi-bin/cvsweb/elog/src/elogd.c
> >
> > and
> >
> > http://midas.psi.ch/cgi-bin/cvsweb/elog/themes/default/default.css |
221
|
Wed Feb 12 19:10:26 2003 |
| Kutlay Topatan | ktopatan@worldbank.org | Question | | | Re: Lost features since upgrade to 2.3.0 |
Stefan,
When will you have 2.3.1 out? I just upgraded to 2.3.0 and would like to see
the links in my summary view. If it is going to be out soon I will wait
instead of compiling from source.
Thanks for great software,
k.
> > Would be nice if you can specify which columns data has links as a flag or
> > setting of some sorts, as opposed to either the first or all, but given a
> > choice I would want the first column to be the linkable one
>
> Well, I decided to make all entries in a table a link, to be consistent with
> the threaded display. But I changed the style such that they look like
> before, but are actually links. This way it cannot hurt (like having too
> much underlined text). The style can be changed via classes ".list1"
> and ".list2" in the style sheet.
>
> The modification will come in 2.3.1, or you can get the source code from CVS
> under
>
> http://midas.psi.ch/cgi-bin/cvsweb/elog/src/elogd.c
>
> and
>
> http://midas.psi.ch/cgi-bin/cvsweb/elog/themes/default/default.css
>
> > > > Problem 2 - no matter what i try in the config file i cannot get elogd
> to
> > > > use stylesheets ive tried specifying and even editing and removing the
> > > > default.css style sheet i downloaded but it just seems to ignore its
> > there.
> >
> > I resolved this problem, many thanks for your help
>
> What happened. If you tell your initial problems, I can maybe put something
> into the docs so that others won't have it...
>
> - Stefan |