Demo Discussion
Forum Config Examples Contributions Vulnerabilities
  Discussion forum about ELOG, Page 17 of 804  Not logged in ELOG logo
 Find |  Login |  Help 
 Full | Summary | Threaded | Hide attachments  Show only new entries    6431 Entries 
Goto page Previous  1, 2, 3 ... 16, 17, 18 ... 802, 803, 804   Next  
ID Date Icondown Author Author Email Category OS ELOG Version Subject
  1523   Mon Nov 21 11:49:52 2005 Warning Alex Halex@synergie-inf.comBug reportWindows2.6.0-betaUndesirable TAG { }
Hi, I'am using ELOG v2.6.0-beta1 on Windows 2000.
I'am using Conditional attributes and obtain in certain case undesirable {x} TAG.

Here is a part of my elog.cfg :
Options Client = ALL, Test one{2}, Test two{3}
#	 Test one
{2} Options Equipment = FWL0020, RT0015

#	 Test two
{3} Options Equipment =

So when I'am using quick filter I have in the scroll box the { } TAG of my Client Option (See screenshots).
Is there any thinks to do for mask them ?
Thanks for answer.
Attachment 1: elog_tag_pb.gif
elog_tag_pb.gif
Attachment 2: elog_tag_pb2.gif
elog_tag_pb2.gif
  1535   Thu Nov 24 20:08:00 2005 Warning Yoshio ImaiBug reportLinux2.6.0beta5"Logkook dir" in top group [global] section ineffective
Hi, it's me again!

I have found one possible bug. We have declared top groups for our logbooks; one for administration and one for the shift logbooks. In the [global]-section there is a "Logbook dir"-statement of the form
[global]
Top group Admin = <...>
Top group Shiftlogs = beamtime1,beamtime2,...

Logbook dir = /data/logbooks
Now, in the [global Shiftlogs] section there is another "Logbook dir"-statement to have all associated logbooks in one tree:
[global Shiftlogs]
Logbook dir = /data/logbooks/shift-logbooks

[beamtime1]
Subdir = beamtime1
The problem is, that the manually created subdirectories /data/logbooks/shift-logbooks/beamtimeN are ignored, and the elogd creates new "Subdir"-directories /data/logbooks/beamtimeN (as if the "Logbook dir" statement in the top group [global] section were ineffective). Is this a bug or configuration error from our side?

There are also one question/request (you see that we use the elog extensively now Wink):
When searching for a particular event in our shift log using the "Find" function, it would often be useful not to go to the single entry, but to the page where that entry resides. This way we can see the whole context of the event. When clicking onto an entry in the "Find" result page, this takes us of course to the single entry, but could you add a function to go to the page instead. Alternatively, is it possible to include a button "Go to page" in the single entry view (it need not even be exactly +/-N entries around, the usual page partition would do)?

Thanks in advance.

Yoshio
  1543   Thu Dec 8 10:32:37 2005 Warning Bertram Metzbmetz@sbs.comBug reportLinuxV2.6.0-betAttachments in duplicated entries
Hi,

the duplicate command duplicates the entry text itself, but it does not duplicate attachments.
If attachments in a duplicated entry are deleted, the original attachment files are deleted as well and cannot be accessed anymore within the original entry.

My suggestion is to copy the attached files too and to use file names of the copies in the duplicated entry.

Kind regards,
Bertram
  1582   Wed Jan 11 15:54:28 2006 Warning Yoshio ImaiBug reportLinux2.6.0r1593Page browsing links in Find mode broken
Hi!

We are having problems with the "Find" mode in the latest revision. When we used "Find" to search for specific texts, and the results span more than one page (say, 2 for example), the page links in the command bar on top point to the ELOG pages rather than the find result pages. This means that, when I click onto "Previous" from find result page 2 (which is the first page getting displayed), I get to logbook page 1 (entries 1 to 20) and not to the previous page of find results. I think this didn't happen in earlier versions. Could you check that? It also happens here in the Forum.

Thanks

Yoshio
  1585   Thu Jan 12 11:32:19 2006 Warning Yoshio ImaiBug reportLinux2.6.0r1597Side effects from debugging

Stefan Ritt wrote:
Thanks for reporting this bug, I fixed it in revision 1597.

Thanks for your quick reaction! Unfortunately, there is one side effect. As far as I understand, you fixed the bug by preserving the command attributes
http://www.logbook.domain/logbook/pageN?command
when browsing with the Goto page links, so that when a filter is applied, it is still active upon page change. However, the same is true for all other commands, including the 
?id=NNN
command which is active when clicking List from single entry view. If you click onto, e.g. Previous in this mode, the elogd has a conflict in that it is required to display one page and having to highlight an entry that resides on another. 
http://www.logbook.domain/logbook/pageN?id=NNN
The highlighting supersedes, and the page browse links are effectively disabled. Is there a way to keep the bug fix but disable the side effects, e.g. selectively not preserving the 
?id=NNN
upon page browsing? Maybe you could implement a "blacklist" of not-to-be-preserved commands, in case there are other problems like this one.


Thanks for the work (I saw the timestamp!)

Yoshio
  1607   Wed Jan 18 17:20:45 2006 Warning Chris Warnerchristopher_warner@dcd.uscourts.govBug reportLinux2.6Buffer Overflow?
Users can access root level directories by using a modified URL. I saw on some security web sites that this was a problem in previous versions. Was it not fixed in 2.6?

To recreate enter http://yourhost.yourdomain.com/../../../../etc/passwd

view your password file in the browser.


If this was previously reported, is there a fix?

Chris Warner
  1643   Mon Jan 30 16:26:08 2006 Warning T. Ribbrockemgaron@gmx.netBug reportLinux2.6.1-1637Numbered lists get closed by </ul>
I just ran into the following problem (and was able to reproduce it in the "demo" logbook on this site):

  • Create a new entry
  • Create a numbered list:
    [LIST=1]
[*] 1st entry
[*] 2nd entry
[/LIST]
  • In the resulting HTML code, the closing statement of that list translates to </ul> instead of </ol>, causing the list to remain open and all following text to be intented by the list indentation. This gets worse when several such lists are used in one document. I'll include an example below.

Numbered list follows:

  1. one
  2. two
  3. three

This text is indented, as the list was not closed properly.

  1. four
  2. five
  3. six

And now we have double indention...
  1692   Tue Feb 14 16:22:56 2006 Warning Steve Jonessteve.jones@freescale.comBug reportOther2.6.1CONCERN: Cross-platform compiling at risk
Stefan, I am concerned that there are becoming too many Linux dependencies in terms of required libraries and header files. Although we have a replacement for the 
forkpty()
routine, I am running into many other dependencies, the latest of which is pty.h. Aren't there guidelines in GCC that point out what is available cross-platform and what is not? For example, any SVR# (System Five, Release XX) based Unix will not include the forkpty() function, but BSD derivatives will.

Currently we are stuck at eLog 2.5.9 because of this issue.
Goto page Previous  1, 2, 3 ... 16, 17, 18 ... 802, 803, 804   Next  
ELOG V3.1.5-3fb85fa6