Demo Discussion
Forum Config Examples Contributions Vulnerabilities
  Discussion forum about ELOG, Page 691 of 807  Not logged in ELOG logo
New entries since:Thu Jan 1 01:00:00 1970
ID Date Icon Author Author Email Category OSdown ELOG Version Subject
  66079   Mon Nov 24 20:00:05 2008 Reply Stefan Rittstefan.ritt@psi.chQuestionAlllatestRe: 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 Reply Dennis Seitzdseitz@berkeley.eduQuestionAll2.7.3Re: 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 Reply Dennis Seitzdseitz@berkeley.eduQuestionAll2.7.5Re: 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!
  66103   Tue Dec 9 00:25:52 2008 Idea Dennis Seitzdseitz@berkeley.eduRequestAll2.7.5Please add Subst on Duplicate

 I would like to be able to substitute some attribute values when an entry is duplicated. I don't see Subst on Duplicate available in the cfg file syntax. Can you add that?

 

Thanks

  66104   Tue Dec 9 08:04:00 2008 Reply Stefan Rittstefan.ritt@psi.chRequestAll2.7.5Re: Please add Subst on Duplicate

 

Dennis Seitz wrote:

 I would like to be able to substitute some attribute values when an entry is duplicated. I don't see Subst on Duplicate available in the cfg file syntax. Can you add that?

 

Subst on Duplicate does not make sense. Subst always works after you submit an entry, while Preset works before you enter the entry. When you Duplicate an entry, it looks like a new one, just with attributes and text from another entry. So when you submit that one, the system cannot distinguish if you entered a new one by yourself or if this is based on a copy of another entry. So what you probably need is Preset on duplicate.

  66105   Wed Dec 10 03:11:01 2008 Reply Dennis Seitzdseitz@berkeley.eduRequestAll2.7.5Re: Please add Subst on Duplicate

 

Stefan Ritt wrote:

 

Dennis Seitz wrote:

 I would like to be able to substitute some attribute values when an entry is duplicated. I don't see Subst on Duplicate available in the cfg file syntax. Can you add that?

 

Subst on Duplicate does not make sense. Subst always works after you submit an entry, while Preset works before you enter the entry. When you Duplicate an entry, it looks like a new one, just with attributes and text from another entry. So when you submit that one, the system cannot distinguish if you entered a new one by yourself or if this is based on a copy of another entry. So what you probably need is Preset on duplicate.

Thanks for explaining.

I thought Preset would work with Duplicate since Duplicate creates a new entry, but it didn't. Then I tried Subst because Duplicating an entry opens it in Edit mode, so you are in effect Duplicating, and then Editing the entry. It just didn't occur to me to look for Preset on Duplicate.

  66151   Wed Jan 14 19:52:04 2009 Question Yoichi Asoasoy01@gmail.comQuestionAll2.7.5Multiple keyword search
Hi,
I have a question regarding how to perform a multiple-keyword search.
For example, when I want to find entries which contain two keywords "abc" and "def" in the body text but in an unknown order,
one way I came up with was to use a regular expression like this.
(abc|def).*(abc|def)
But this will also match entries containing two "abc" or two "def".
The following one will eliminate this problem.
(abc.*def)|(def.*abc)
But when I use more than two keywords, this type of regular expressions becomes very long (because I have to list all the permutations of the keywords) and it may not fit in the search text field (there seems to be a limit on the length of the search text).

Is there any way to allow multiple-keyword search easily ?
It would be nice if I can just enter two or more keywords separated by white spaces and elog finds entries containing all the keywords.

Thanks,
Yoichi
  66213   Thu Feb 19 18:19:12 2009 Question Bill Pierbpier@clove.orgQuestionAll2.7.3Re: scrollable text section only when viewing a log entry

Bill Pier wrote:

IStefan Ritt wrote:

Bill Pier wrote:

Stefan Ritt wrote:

Bill Pier wrote:

Is there a way, option, feature to setup the text section only to be scrollable when viewing a log entry, such that the header (meta info) section stays fixed?

Unfortunately no.

Well, I tinkered a bit with a journal entry display page and found that without having to suggest the flavor-of-the-month web design mantra of "replace table layout with CSS only",  just a few CSS tweaks can enable exactly what I am desiring.

For your consideration, here are the tweaks I made to get a fixed header and footer section with a scrollable journal entry section in the middle:

  1. moved the journal entry content and footer line (elog version info) out of the layout table structure, into their own div sections;
  2. in the style sheet, added attribute "position:fixed" to the "frame table" section;
  3. in the style sheet, added attribute sections for journal entry content and footer div sections:
    1. #content: overflow:auto;position:fixed;top:230px;bottom:30px;width:100%;
    2. #footer:  text-align:center;bottom:0;position:fixed;width:100%;

Now as I'm not a web designer by trade and not intimately familiar with CSS nuances, I used the time honored method of documentation lookup with trial and error.

In any case, it worked and displays exactly the way I wanted; please do consider this for a future elog release. 

Apparently you downloaded an ELOG page and modified it manually. Can you send me the modified page, it then would be easier for me to implement it (I can shorten "my" trial and error phase..)

Yes, you are correct, I did simply take a sample page from logs and tinker with the html and css file, with the changes enumerated previously.  I have attached the tweaked sample html elog log page and css file, along with a few of the standard elog png files to complete the page with some semblance of the normal display.

 

 

Thu Feb 19 18:18:20 2009  Did this suggestion ever get considered for implementation?

 

 

ELOG V3.1.5-3fb85fa6