ELOG Forum

Demo Discussion

Forum Config Examples Contributions Vulnerabilities

Discussion forum about ELOG, Page 178 of 238

Not logged in

Find | Login | Help

Full | Summary | Threaded | Collapse | Expand

1898 Entries

Goto page Previous 1, 2, 3 ... 177, 178, 179 ... 236, 237, 238 Next

Removing 'New' from "List Menu commands" prevents saving elogd.cfg, posted by Steve Jones on Thu Mar 9 04:46:42 2006

Strange as it mmay seem, when I attempt to remove the "New" menu item from "List Menu commands" in a logbook section, I am no longer able to Save the config file -- I am presented with a message saying "Error: Command "Save" not allowed". I have to manually edit the file, add that menu item back in, and then all is ok. This is on the system where I am using 'Top Groups', so the logbook is a part of one of the top groups.

OPTION <attribute> not working right in [ global <name>] Top Group, posted by Steve Jones on Wed Mar 8 22:33:56 2006

I've verified that when the following is part of the definition of a [logbook] OR is part of a regular [global] config:

Options Completed = Open{a}, Closed{b}
{a} Preset CompletedDate = 
{b} Preset CompletedDate = $date

. . . the intended function (when option "Open" is selected the attribute "CompletedDate" is cleared; when the option "Closed" is selected the attribute "CompletedDate" is filled with the current date)

When this same code is moved to a [global <name>] config the function no longer works (the attribute "CompletedDate" is not set).

This for me is a show stopper as using Top Group has allowed me to create and use logbooks in a way that I could not under the old way (single [global]. I have verified that the same thing happens under 2.5.9.

Crafted URL causes elog to coredump, posted by Steve Jones on Sat Mar 4 06:08:29 2006

While playing with TOP GROUP I managed to get elog 2.6.1 1660 on Solaris 9 to coredump. Since I didn't really understand TOP GROUP I tried a URL where I had http://elog.server.com/topgroupname/logbookname. Putting that logbookname at the end caused elog to dump.

Can this be reproduced by others?

Re: Crafted URL causes elog to coredump, posted by Stefan Ritt on Mon Mar 6 14:04:12 2006

Steve Jones wrote:

No. This forum has the "elog" as the top group, "Forum" as the logbook, so if I write

http://midas.psi.ch/elogs/elog/Forum

it does not crash.

Re: Crafted URL causes elog to coredump, posted by Steve Jones on Mon Mar 6 17:35:52 2006

Stefan Ritt wrote:

Steve Jones wrote:

No. This forum has the "elog" as the top group, "Forum" as the logbook, so if I write

http://midas.psi.ch/elogs/elog/Forum

it does not crash.

Quote:

Try a non-existent logbook - example http://midas.psi.ch/elogs/elog/NewForum. This is occurring under rev 1660.

Re: Crafted URL causes elog to coredump, posted by Stefan Ritt on Mon Mar 6 17:45:18 2006

Steve Jones wrote:

Try a non-existent logbook - example http://midas.psi.ch/elogs/elog/NewForum. This is occurring under rev 1660.

No, the above link just works fine, just click it.

Re: Crafted URL causes elog to coredump, posted by Steve Jones on Mon Mar 6 18:04:39 2006

Stefan Ritt wrote:

Steve Jones wrote:

Try a non-existent logbook - example http://midas.psi.ch/elogs/elog/NewForum. This is occurring under rev 1660.

No, the above link just works fine, just click it.

Quote:

I was afraid to try Big grin

. Ok, then the issue *might* be rev 1660 or perhaps the fact that compiled under Solaris it does this. Any suggestions on how to find out?

Re: Crafted URL causes elog to coredump, posted by Steve Jones on Mon Mar 6 18:06:32 2006

Stefan Ritt wrote:

Steve Jones wrote:

Try a non-existent logbook - example http://midas.psi.ch/elogs/elog/NewForum. This is occurring under rev 1660.

No, the above link just works fine, just click it.

Quote:

I was afraid to try Big grin

. Ok, then the issue *might* be rev 1660. On my production version running 2.5.3 I get the expected "Invalid URL: <name>" box. Any suggestions on how to find out?

[UPDATE] Re: Crafted URL causes elog to coredump, posted by Steve Jones on Mon Mar 6 18:54:32 2006

Steve Jones wrote:

Stefan Ritt wrote:

Steve Jones wrote:

Try a non-existent logbook - example http://midas.psi.ch/elogs/elog/NewForum. This is occurring under rev 1660.

No, the above link just works fine, just click it.

Quote:

I was afraid to try Big grin

. Ok, then the issue *might* be rev 1660. On my production version running 2.5.3 I get the expected "Invalid URL: <name>" box. Any suggestions on how to find out?

Steve Jones wrote:

Ok, here is what I found:

Now running rev 1671
Specifying a non-existent logbook with plain URL of elog server: OK, error is caught and reported
Specifying a non-existent logbook *under* a logbook name: Ok, error is caught.
Specifying a non-existent logbook under a "Top Group" of the form "This+Is+Top+Group+One" results in no error, elogd crash. Example URLs:
- ```
http://midas.psi.ch/This+Is+Top+Group+One/newlogbook
```
  OR
- ```
http://midas.psi.ch/This%20Is%20Top%20roup%20One/newlogbook
```
- Results in a program crash under Solaris. Top Groups were not defined under elog 2.5.3.

[UPDATE2] Re: Crafted URL causes elog to coredump, posted by Steve Jones on Wed Mar 8 18:05:54 2006

Steve Jones wrote:

Stefan Ritt wrote:

Steve Jones wrote:

Try a non-existent logbook - example http://midas.psi.ch/elogs/elog/NewForum. This is occurring under rev 1660.

No, the above link just works fine, just click it.

Quote:

I was afraid to try Big grin

. Ok, then the issue *might* be rev 1660. On my production version running 2.5.3 I get the expected "Invalid URL: <name>" box. Any suggestions on how to find out?

Steve Jones wrote:

Ok, here is what I found:

Now running rev 1671
Specifying a non-existent logbook with plain URL of elog server: OK, error is caught and reported
Specifying a non-existent logbook *under* a logbook name: Ok, error is caught.
Specifying a non-existent logbook under a "Top Group" of the form "This+Is+Top+Group+One" results in no error, elogd crash. Example URLs:
- ```
http://midas.psi.ch/This+Is+Top+Group+One/newlogbook
```
  OR
- ```
http://midas.psi.ch/This%20Is%20Top%20roup%20One/newlogbook
```
- Results in a program crash under Solaris. Top Groups were not defined under elog 2.5.3.

Steve Jones wrote:

Well, more data. When I have Top Groups defined and I go to create a new logbook via the eLog interface, the interface creates a URL of the form:

http://elog-test.company.com/EngineeringComputeChangeLogs/Test2/?cmd=Config

This causes eLog to crash -- so I am at a complete loss. I tried shortening the length of the top group name. It all seems to come back to the inclusion of the name of a logbook that doesn't exist yet?) although I confirmed that the eLog config file *is* updated and the logbook directory *is* created. So now I am trying to figure out how to debug this thing. Stefan, any clues?

[Segmentation Fault source identified] Verbose Output: Re: Crafted URL causes elog to coredump, posted by Steve Jones on Wed Mar 8 20:19:14 2006

Steve Jones wrote:

Stefan Ritt wrote:

Steve Jones wrote:

Try a non-existent logbook - example http://midas.psi.ch/elogs/elog/NewForum. This is occurring under rev 1660.

No, the above link just works fine, just click it.

Quote:

I was afraid to try Big grin

. Ok, then the issue *might* be rev 1660. On my production version running 2.5.3 I get the expected "Invalid URL: <name>" box. Any suggestions on how to find out?

Steve Jones wrote:

Ok, here is what I found:

Now running rev 1671
Specifying a non-existent logbook with plain URL of elog server: OK, error is caught and reported
Specifying a non-existent logbook *under* a logbook name: Ok, error is caught.
Specifying a non-existent logbook under a "Top Group" of the form "This+Is+Top+Group+One" results in no error, elogd crash. Example URLs:
- ```
http://midas.psi.ch/This+Is+Top+Group+One/newlogbook
```
  OR
- ```
http://midas.psi.ch/This%20Is%20Top%20roup%20One/newlogbook
```
- Results in a program crash under Solaris. Top Groups were not defined under elog 2.5.3.

Steve Jones wrote:

Well, more data. When I have Top Groups defined and I go to create a new logbook via the eLog interface, the interface creates a URL of the form:

http://elog-test.company.com/EngineeringComputeChangeLogs/Test2/?cmd=Config

Steve Jones wrote:

Ok, below is a capture of the eLog verbose output. eLog appears to do everything right up to whatever it is attempting to do at the last -- load the new logbook into config mode. The biggest difference that I see is the code is attempting to do:

1>

GET /ECCL/Test6/?cmd=Config HTTP/1.1

This also generates a segmentation fault:
2>

http://elog-test.company.com/ECCL/Test6?Cmd=Config

Whereas the interface issues the URL:

3>

GET http://elog-test.company.com/Test6/?cmd=Config

#1 and #2 cause a segmentation faults. #3 does not.

Does this help??

==== Return ================================
HTTP/1.1 200 Document follows
Server: ELOG HTTP 2.6.1-1671
Accept-Ranges: bytes
Expires: Thursday, 09-Mar-06 19:07:51 GMT
Connection: Keep-Alive
Keep-Alive: timeout=60, max=10
Content-Type: image/x-icon
Content-Length: 318






GET /TX30-CL/?cmd=Create+new+logbook&lbname=test4&template=&cmd=Create+new+logbook HTTP/1.1
Host: elog-test.company.com:1080
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.1) Gecko/20060111 Firefox/1.5.0.1
Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Referer: http://elog-test.company.com:1080/TX30-CL/
Cookie: elmode=threaded; SITESERVER=ID=6c8b8ddc89cc07688479433b364c5b40; urem=0; unm=r4aajl; upwd=TDIwYXVyZW4=


Indexing logbook "TX30-IL" ... Found empty logbook "TX30-IL"
Indexing logbook "TX11-IL" ... Found empty logbook "TX11-IL"
Indexing logbook "TX32-IL" ... 
  ID   1, 040716a.log, ofs     0, thead, MD5=6E2FDFC052D1264222AA380DDF1878C1
  ID   2, 040716a.log, ofs   899, thead, MD5=2DA14909DFCD24EC3FADF388E0C9F7C7
  ID   3, 040812a.log, ofs     0, thead, MD5=D1B98E2B5E852BF3809EE4297B3DBA3D
  ID   4, 040824a.log, ofs     0, thead, MD5=E354BD9E899D89473D90A2E6FC32185A
  ID   5, 040827a.log, ofs     0, thead, MD5=CD519304C3B5054CD224426CBF76F83A
  ID   6, 040830a.log, ofs     0, thead, MD5=E5ACB49F9505D4A4721F07D116B08577
  ID   7, 040830a.log, ofs   548, thead, MD5=46F974CE0EEED711E22FDC4135EB1012
  ID   8, 040901a.log, ofs     0, thead, MD5=CB785F67B1F3EF8A541C95895F8ED43C
  ID   9, 040901a.log, ofs  1892, reply, MD5=65FAA0CA56828B6CF588A4C352AF84B7
  ID  10, 040910a.log, ofs     0, thead, MD5=5756F9BD237463A039FC36A089904733
  ID  11, 040915a.log, ofs     0, thead, MD5=4EAB52440A45ED05F4009EDF3A94D823
  ID  12, 040916a.log, ofs     0, thead, MD5=7C8E0F6DE412F38D2E56E6350F9532BF
  ID  13, 040916a.log, ofs   560, thead, MD5=46B0C32C42FE71A020B35D228D78CB0D
  ID  14, 040916a.log, ofs  1856, thead, MD5=8FFFF190194A526E210CA04C1621198A
  ID  15, 040927a.log, ofs     0, thead, MD5=98B992B2AD8007FAFD57C316AF9F651C
  ID  16, 041015a.log, ofs     0, thead, MD5=04D1D71581501BD91CD00214C42D72A5
  ID  17, 041108a.log, ofs     0, thead, MD5=B88733FCEA5F1DF6CA97A48CDD4415D2
  ID  18, 041207a.log, ofs     0, thead, MD5=EF8251801E33241D43998F4F16A685AA
  ID  19, 041220a.log, ofs     0, thead, MD5=6D4831B3F787D3D403CEA834D5332E3E
  ID  20, 041220a.log, ofs   845, thead, MD5=44E409286630E4CF9E4C86C39E575C2E
  ID  21, 041223a.log, ofs     0, reply, MD5=E282DA199A44B44E558757B6B306EFDE
  ID  22, 050107a.log, ofs     0, thead, MD5=F096677FA81DFA73793BEA4BFF0319F6
  ID  23, 050112a.log, ofs     0, thead, MD5=711670AF4FECE13BA446DB98C7F4A457
  ID  24, 050114a.log, ofs     0, thead, MD5=4E3FD5313294CE645D71B3D80B1073EA
  ID  25, 050117a.log, ofs     0, thead, MD5=D359C34C0AD0F9F67A5B1C9EB6427C2C
  ID  26, 050119a.log, ofs     0, thead, MD5=B9B083F9BB21C675DC23CA88C0651171
  ID  27, 050125a.log, ofs     0, thead, MD5=E98CD76BB9B0276A3281A95EABEA7288
  ID  28, 050203a.log, ofs     0, thead, MD5=7664924CDF3A33C0AC6A0A944BC0667C
  ID  29, 050223a.log, ofs     0, thead, MD5=D56D3760BDADF638CE90322B48485014
  ID  30, 050224a.log, ofs     0, thead, MD5=C51EAB967557EF89767BE38C5265DEB0
  ID  31, 050302a.log, ofs     0, thead, MD5=74E39EDB807510564EF4607BFF75C637
  ID  32, 050307a.log, ofs     0, thead, MD5=030B29888BCDC72CC877C33A2CBE8D7A
  ID  33, 050309a.log, ofs     0, thead, MD5=2CE00D7C075915210A5CC76C0489B477
  ID  34, 050310a.log, ofs     0, reply, MD5=0F8156FDCA1AD4F592ABEDC4AB3D20FE
  ID  35, 050401a.log, ofs     0, thead, MD5=581E6FA67DD9A32D0A44679DB03120CF
  ID  36, 050412a.log, ofs     0, thead, MD5=20ED554D75D05D0050319B069D3D758A
  ID  37, 050412a.log, ofs   799, reply, MD5=24A7ABD8C57FD13623E0018A8945DDDA
  ID  38, 050511a.log, ofs     0, thead, MD5=B92569DB76E44D354F3BADABE24C7F12
  ID  39, 050512a.log, ofs     0, thead, MD5=883461D019D1CFD0FA59DB017B17EF51
  ID  40, 050512a.log, ofs   481, thead, MD5=0A1765D83A97EDFCDB56258ABD8D0B76
  ID  41, 050512a.log, ofs  1580, thead, MD5=770303806E53660BB4334DA068EB4B3F
  ID  42, 050512a.log, ofs  2554, thead, MD5=24DD8C0F033ACC63B13386400B8BEF68
  ID  43, 050516a.log, ofs     0, thead, MD5=14B39EEAC23A3887582160E8A0F3FA02
  ID  44, 050517a.log, ofs     0, thead, MD5=954542ADDFA15303818BBFD9DA8D024F
  ID  45, 050517a.log, ofs   753, reply, MD5=B3D6BAECCD32470F8DD62A5DC31386A0
  ID  46, 050518a.log, ofs     0, reply, MD5=A86D57D87BC921B3A93D8248E76FDAE0
  ID  47, 050519a.log, ofs     0, thead, MD5=8276962204EE9A9178F53A4394B30582
  ID  48, 050524a.log, ofs     0, reply, MD5=E91633AE3B589E71BC746B21328ED2EB
  ID  49, 050617a.log, ofs     0, thead, MD5=E88998C375BE59A2F83139508BA23F14
  ID  50, 050712a.log, ofs     0, thead, MD5=79472FBFA452415B0EE46BFF609E3E71
  ID  51, 050718a.log, ofs     0, thead, MD5=D2B1760AAA84B9EF182AC9060EB4EF8D
  ID  52, 050803a.log, ofs     0, thead, MD5=8324112BB00FF3B780BBD477374CFFAB
  ID  53, 050803a.log, ofs   518, thead, MD5=BF43D5CEC1A2807A3B7A1C299536A0B2
  ID  54, 050803a.log, ofs   910, thead, MD5=92C4C73A66DB13FD76F9C0701CB38CCC
  ID  55, 050803a.log, ofs  1313, reply, MD5=78371758834EEF581F0CE8E8E86C079C
  ID  56, 050818a.log, ofs     0, thead, MD5=640E8D209B00DD8C4C40124C0DF84967
  ID  57, 050829a.log, ofs     0, thead, MD5=877B7BE835893E7D3FA7BDA50B551DD3
  ID  58, 050916a.log, ofs     0, thead, MD5=78682559B5F8EB1E6172311E02E44087
  ID  59, 050916a.log, ofs   904, thead, MD5=CE6F9A63104C1A3D85E37CF223EFF54D
  ID  60, 051029a.log, ofs     0, thead, MD5=3CEF5E7E47D465436042F3C54AA8B07E
  ID  61, 051128a.log, ofs     0, thead, MD5=A87CD1D9177FF1AE6088C21B41C4CDD2
  ID  62, 051129a.log, ofs     0, reply, MD5=B873F83F0C38A22B924FAAED7FE96804
  ID  63, 051212a.log, ofs     0, thead, MD5=344A55E1C431368E65A0E888229B1A83
  ID  64, 060202a.log, ofs     0, thead, MD5=52C0A072C25FC151C55F59CD5267B699
After sort:
  ID   1, 040716a.log, ofs     0
  ID   2, 040716a.log, ofs   899
  ID   3, 040812a.log, ofs     0
  ID   4, 040824a.log, ofs     0
  ID   5, 040827a.log, ofs     0
  ID   6, 040830a.log, ofs     0
  ID   7, 040830a.log, ofs   548
  ID   8, 040901a.log, ofs     0
  ID   9, 040901a.log, ofs  1892
  ID  10, 040910a.log, ofs     0
  ID  11, 040915a.log, ofs     0
  ID  12, 040916a.log, ofs     0
  ID  13, 040916a.log, ofs   560
  ID  14, 040916a.log, ofs  1856
  ID  15, 040927a.log, ofs     0
  ID  16, 041015a.log, ofs     0
  ID  17, 041108a.log, ofs     0
  ID  18, 041207a.log, ofs     0
  ID  19, 041220a.log, ofs     0
  ID  20, 041220a.log, ofs   845
  ID  21, 041223a.log, ofs     0
  ID  22, 050107a.log, ofs     0
  ID  23, 050112a.log, ofs     0
  ID  24, 050114a.log, ofs     0
  ID  25, 050117a.log, ofs     0
  ID  26, 050119a.log, ofs     0
  ID  27, 050125a.log, ofs     0
  ID  28, 050203a.log, ofs     0
  ID  29, 050223a.log, ofs     0
  ID  30, 050224a.log, ofs     0
  ID  31, 050302a.log, ofs     0
  ID  32, 050307a.log, ofs     0
  ID  33, 050309a.log, ofs     0
  ID  34, 050310a.log, ofs     0
  ID  35, 050401a.log, ofs     0
  ID  36, 050412a.log, ofs     0
  ID  37, 050412a.log, ofs   799
  ID  38, 050511a.log, ofs     0
  ID  39, 050512a.log, ofs     0
  ID  40, 050512a.log, ofs   481
  ID  41, 050512a.log, ofs  1580
  ID  42, 050512a.log, ofs  2554
  ID  43, 050516a.log, ofs     0
  ID  44, 050517a.log, ofs     0
  ID  45, 050517a.log, ofs   753
  ID  46, 050518a.log, ofs     0
  ID  47, 050519a.log, ofs     0
  ID  48, 050524a.log, ofs     0
  ID  49, 050617a.log, ofs     0
  ID  50, 050712a.log, ofs     0
  ID  51, 050718a.log, ofs     0
  ID  52, 050803a.log, ofs     0
  ID  53, 050803a.log, ofs   518
  ID  54, 050803a.log, ofs   910
  ID  55, 050803a.log, ofs  1313
  ID  56, 050818a.log, ofs     0
  ID  57, 050829a.log, ofs     0
  ID  58, 050916a.log, ofs     0
  ID  59, 050916a.log, ofs   904
  ID  60, 051029a.log, ofs     0
  ID  61, 051128a.log, ofs     0
  ID  62, 051129a.log, ofs     0
  ID  63, 051212a.log, ofs     0
  ID  64, 060202a.log, ofs     0
ok
Indexing logbook "AZ34-IL" ... Found empty logbook "AZ34-IL"
Indexing logbook "AZ50-IL" ... 
  ID   1, 040701a.log, ofs     0, thead, MD5=7FCEAF2572A38C0C115F4A00F1407BFA
After sort:
  ID   1, 040701a.log, ofs     0
ok
Indexing logbook "TX30-CL" ... 
  ID   1, 040604a.log, ofs     0, thead, MD5=BAC61554477BD5390A73F2974545C0A5
  ID   2, 040722a.log, ofs     0, thead, MD5=0829BF09B2B9B5BACC42329EAB14B25E
After sort:
  ID   1, 040604a.log, ofs     0
  ID   2, 040722a.log, ofs     0
ok
Indexing logbook "TX11-CL" ... Found empty logbook "TX11-CL"
Indexing logbook "TX32-CL" ... 
  ID 201, 060303a.log, ofs     0, thead, MD5=CC9C0C4FA6BFF7EEB368BA7CCE126629
After sort:
  ID 201, 060303a.log, ofs     0
ok
Indexing logbook "AZ34-CL" ... Found empty logbook "AZ34-CL"
Indexing logbook "AZ50-CL" ... Found empty logbook "AZ50-CL"
Indexing logbook "Approvals" ... Found empty logbook "Approvals"
Indexing logbook "Test" ... Found empty logbook "Test"
Indexing logbook "Test2" ... Found empty logbook "Test2"
Indexing logbook "Test3" ... Found empty logbook "Test3"
Created directory "test4"
Indexing logbook "test4" ... Found empty logbook "test4"
==== Return ================================
HTTP/1.1 302 Found
Server: ELOG HTTP 2.6.1-1671
Connection: Keep-Alive
Keep-Alive: timeout=60, max=10
Location: http://elog-test.company.com:1080/ECCL/test4/?cmd=Config
Content-Length: 20



<html>redir</html>


GET /ECCL/Test6/?cmd=Config HTTP/1.1
Host: elog-test.am.freescale.net:1080
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.1) Gecko/20060111 Firefox/1.5.0.1
Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Referer: http://elog-test.company.com:1080/TX30-CL/
Cookie: SITESERVER=ID=6c8b8ddc89cc07688479433b364c5b40; urem=0; unm=r4aajl; upwd=TDIwYXVyZW4=


Segmentation fault

require smileys to have whitespace on either side?, posted by Glenn Horton-Smith on Sat Mar 4 05:17:14 2006

It would be nice if elog would only interpret something as a smiley if it is surrounded by whitespace. It can be particularly annoying that an 8 followed by a right paren becomes a "cool" smiley -- e.g., a parenthetical reference to event eighteen (18) becomes mangled... [That was "18" inside the parens.]

Is there already a way to solve this issue (other than always previewing your entries and adding spaces before parans)? Is the feature hard to implement?

Re: require smileys to have whitespace on either side?, posted by Stefan Ritt on Mon Mar 6 13:50:07 2006

Glenn Horton-Smith wrote:

Interpreting smileys only if they are surrounded by whitespace does not solve the problem completely. It will solve it for (1\8), but not if you have (1, \8) (1, 9) in your text. So it's not a good solution. If you have problems with simleys, I would post my text in plain mode, or surround your numbers with [code]...[/code] tags. If you write

[code](1\8)[/code]

then it will look like

(18)

which should be fine.

Provide option to require smileys to be bracketed a la ELCode?, posted by Glenn Horton-Smith on Mon Mar 6 20:51:57 2006

Stefan Ritt wrote:

Glenn Horton-Smith wrote:

Hmm, you're right. But I like EL Code, and I don't want to give it up just because of the smileys! A better solution would be to provide an option, which when set, would require smileys to be in brackets, e.g., [\8)] would become the cool smiley [8)], rendered without surrounding brackets if the option was set.

I actually just spent some time I didn't really have and modified my copy of elogd to see if it could be done and would work as intended. Eureka, it works! The modification implements an option "use bracketed smileys" which, if set to 1, causes the editor smiley bar to insert smileys with the square brackets around them and causes rsputs_elcode() to only substitute for smileys if there are square brackets around them, suppressing the square brackets.

I like this feature. Maybe others would like it too. I have a patch file (diff -cbw) w.r.t. svn version 1663 if you're interested.

eLog Version number as eLog attribute?, posted by Steve Jones on Fri Feb 24 16:40:38 2006

When a footer is used (via Bottom text = <filename>) eLog no longer displays the eLog version number at the bottom. Is it possible to somehow expose the version/revision as an eLog attribute or have the version still display even when a replacement footer is specified?

Thanks!

Re: eLog Version number as eLog attribute?, posted by Stefan Ritt on Wed Mar 1 10:31:33 2006

Steve Jones wrote:

I added that feature, but will not be able to commit it before the next weekend.

Re: eLog Version number as eLog attribute?, posted by Steve Jones on Wed Mar 1 20:22:28 2006

Stefan Ritt wrote:

Steve Jones wrote:

I added that feature, but will not be able to commit it before the next weekend.

Quote:

Not a problem! Thanks

[RESOLVED] eLog Version number as eLog attribute?, posted by Steve Jones on Mon Mar 6 18:36:34 2006

Steve Jones wrote:

Stefan Ritt wrote:

Steve Jones wrote:

I added that feature, but will not be able to commit it before the next weekend.

Quote:

Not a problem! Thanks

Steve Jones wrote:

Works as requested!!

Allow $attributes in "Comment = " option, posted by Steve Jones on Fri Mar 3 18:02:59 2006

Is it possible to allow $attribute substitutions in the "Comment =" option for logbooks?

Re: Allow $attributes in "Comment = " option, posted by Stefan Ritt on Mon Mar 6 13:40:40 2006

Steve Jones wrote:

Is it possible to allow $attribute substitutions in the "Comment =" option for logbooks?

The "Comment =" option for logbooks gives a general comment, like Discussion forum about ELOG for this forum. Since this comment is global, it does not make sense to have $attribute substitution.

Re: Allow $attributes in "Comment = " option, posted by Steve Jones on Mon Mar 6 17:43:11 2006

Stefan Ritt wrote:

Steve Jones wrote:

Is it possible to allow $attribute substitutions in the "Comment =" option for logbooks?

The "Comment =" option for logbooks gives a general comment, like Discussion forum about ELOG for this forum. Since this comment is global, it does not make sense to have $attribute substitution.

Quote:

Ok, just a thought. Thanks

Find in multiple logbooks returns wrong pages, posted by Patrick Decowski on Mon Feb 27 19:29:15 2006

hello ELOG developers,

i think that i found a problem in the find function of ELOG  version 2.6.1. i can reproduce it on the forum ELOG website on midas.psi.ch:

go to: http://midas.psi.ch/elogs/Contributions/?cmd=Find
and enter under author 'ritt' and check the 'search all logbooks' checkmark, then search

the returned list has all your postings on all three ELOG sections, but if you look at the links that are returned, they point to the 'Contributions' 
portion of the ELOG and not the 'Forum' portion as they should. this means that the wrong posting is returned when you click on the link (or in 
this case, no posting at all).

for example, the HTML of the first link is
[...]
<tr>
<td class="list2" nowrap><a href="1723">Forum</a></td>
<td class="list2">
<a href="1723">&nbsp;&nbsp;1723&nbsp;&nbsp;</a>
</td>

<td class="list2" nowrap><a href="1723">Thu Feb 23 15:50:20 2006</a></td>
<td class="list2"><a href="1723">Stefan <B style="color:black;background-color:#ffff66">Ritt</B></a></td><td class="list2"><a 
href="1723"><a href="stefan.ritt@psi.ch">stefan.ritt@psi.ch</a></a></td><td class="list2"><a href="1723">Question</a></td><td 
class="list2"><a href="1723">Re: Protect Selection page</a></td><td class="list2"><a href="1723"></a>&nbsp;</td><td class="list2"><a 
href="1723"></a>&nbsp;</td><tr>
[...]

i.e., it is missing '../Forum' in front of all the links.

regards,
patrick.

Re: Find in multiple logbooks returns wrong pages, posted by Stefan Ritt on Mon Mar 6 13:06:59 2006

This problem has been fixed in SVN revision 1671.

Top Groups and logbook directorys, posted by Steve Jones on Thu Mar 2 23:32:25 2006

I am re-working our elog setup and am seriously looking at using the "Top Group" feature. What I like best is the ability to create [global] configurations for a group (or type) of logbook when I host multiple types on the same server. I also like being able to specify a different password file, etc.

A limitation that I run into is I would really like the actual directory names used for storing the logbooks for the different types to be identical - which isn't possible when all logbooks (regardless of context) exist at the same directory level. For example, I might have:

3 physical locations: ABC, DEF, GHI

For each location I want to maintain two *groups* of logbooks - CircuitTests and BoardTests. What I would like to end up with is:
- CircuitTests
----ABC
----DEF
----GHI
- BoardTests
----ABC
----DEF
----GHI

Under current elog this is not possble as far as I know. Since each logbook is a physical directory, each logbook requires a unique name. The concept of a named [global] area fills the bill for all things but it would be nifty if one could do:
[global circuittests]
Logbook dir = circuittestlogbooks

[global boardtests]
Logbook dir = boardtestlogbooks

I suppose the poorman's way of doing this is for each logbook to do the following:
[ABC]
Subdir = boardtestlogbooks/ABC
[DEF]
Subdir = boardtestlogbooks/DEF
[GHI]
Subdir = boardtestlogbooks/GHI

or something like that, but I was hopic for something a little more integrated - like creating the hierarchical stuff via the GUI. Anyway, this probably sounds like a major overhaul, which definitely wouldn't be worth it unless I have completely missed something glaringly obvious.

Thanks!

Re: Top Groups and logbook directorys, posted by Steve Jones on Sat Mar 4 06:04:53 2006

Steve Jones wrote:

Perhaps it is best to ignore this -- I went for a workaround that I like. I am running into a few quirky things with Top Group but it is likely due to the fact that I have never used it.

Goto page Previous 1, 2, 3 ... 177, 178, 179 ... 236, 237, 238 Next

ELOG V3.1.5-3fb85fa6