ELOG Forum

# RFC

Format RFC = 0,narrowattribname,narrowattribvalue,60,60
Preset RFC = RFC-######
Preset On Duplicate RFC = RFC-######
Tooltip RFC = A unique reference will be generated for this Request For Change

We also have a "Created by/when" attribute. Looking at the values this seems to be set when the user clicks "New" whereas the time stamp that appears on the line after the $@MID@$ seems to be set when the user clicks "Submit".

# Created

Format Created = 0,attribname,attribvalue,70,100
Preset Created = $long_name ($short_name) on $date
Preset On Duplicate Created = $long_name ($short_name) on $date

Every once in a while the incrementing stops working and the number 'sticks' or misses some out. It looks as if it might be because multiple people are adding entries concurrently. Could the occasion where there is a gap in the sequence (171-174) be where people abandoned changes (clicked on "Back") after having numbers allocated? Here is a list showing the discrepancies.

Date Item Time Stamp (from the line after $@MID@$) "Created" attribute time stamp

22/09/08 124 16:15:10 11:58

22/09/08 125 16:33:54 16:24

22/09/08 125 16:35:37 16:33 Should be 126

...

10/10/08 146 10:39:09 10:30 Correct

10/10/08 146 10:46:57 10:35 Should be 147

10/10/08 147 13:04:03 13:02 Should be 148

10/10/08 148 15:11:38 15:00 Should be 149

...

17/11/08 171 10:21 10:17 Correct

17/11/08 174 14:30 13:47 Should be 172

17/11/08 175 16:14 16:04 Should be 173

17/11/08 176 16:49 16:38 Should be 174

...

25/11/08 187 15:49:58 15:47 Correct

25/11/08 187 15:52:39 15:48 Should be 188

25/11/08 188 16:49:56 16:44 Should be 189

25/11/08 188 16:52:40 16:40 Should be 190

25/11/08 188 16:55:17 16:43 Should be 191

Let me know if you need any more information.

regards

Steve

66080

Tue Nov 25 17:01:55 2008

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.

66079

Mon Nov 24 20:00:05 2008

Re: Re: $entry time not readable by Subst, else not datetime type? - possible Preset bug?

Dennis Seitz wrote:

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:

66078

Mon Nov 24 18:16:31 2008

Re: Export of entries

William De La Vega wrote:

I would like to export several entries out of a logbook I have with a specific subject.

I need to send these entries to someone who does not have elog nor can they install it.

Is there a way to do this?

Thanks,

Bill

Yes. Go to the "find" page, select your subject, check "CSV", "XML" or "RAW" and click on search.

66077

Mon Nov 24 18:15:01 2008

Re: Elogd crashes with: *** stack smashing detected ***

Niklas wrote:

Stefan,

perhaps there should be something like the bold text below in elogd.c:

int process_http_request(const char *request, int i_conn)^M
...

   /* extract cookies */^M
   if ((p = strstr(request, "Cookie:")) != NULL) {^M
      p += 6;^M
      do {^M
         p++;^M
         while (*p && *p == ' ')^M
            p++;^M
         strlcpy(str, p, sizeof(str));^M
         for (i = 0; i < (int) strlen(str); i++)^M
            if (str[i] == '=' || str[i] == ';')^M
               break;^M
         if (str[i] == '=') {^M
            str[i] = 0;^M
            p += i + 1;^M
            for (i = 0; *p && *p != ';' && *p != '\r' && *p != '\n' && i < (int) sizeof(cookie); i++)
cookie[i] = *p++;

...

Wow, where did you get that long cookie from? Certainly not from elogd. You must run elogd under Apache, and have some other service next to it on your server which distributes this long cookies, that's why other people did not experience this problem yet. I appreciate your fix. It's alwasy nice to see users not only complain about things, but try to fix them. Your fix is almost correct, you need a

i<(int) sizeof(cookie)-1

since there is the trailing zero for terminating the cookie string. I applied your fix to SVN revision #2146.

66076

Mon Nov 24 18:03:54 2008

I would like to export several entries out of a logbook I have with a specific subject.

I need to send these entries to someone who does not have elog nor can they install it.

Is there a way to do this?

Thanks,

Bill

Goto page Previous 1, 2, 3 ... 466, 467, 468 ... 806, 807, 808 Next

ELOG V3.1.5-3fb85fa6