Demo Discussion
Forum Config Examples Contributions Vulnerabilities
  Discussion forum about ELOG, Page 393 of 808  Not logged in ELOG logo
ID Date Icon Author Author Email Category OS ELOG Versiondown Subject
  66690   Mon Jan 18 02:13:19 2010 Reply Gabriele Sirrisirri@bo.infn.itRequestWindows2.7.8-2283Re: Collapse to Last and Quick Filter
Hello,
   I gave it a try using the svn version n. 2283 (12 Jan 2010).  The threaded display can be collapsed only if you don't 
apply any sorting. In the latter case, if you sort in some way ( with "Sort Attributes =" or "sort=" in the url), the 
thread cannot be collapsed anymore.

Also if I apply any filter from the quick filter bar, I cannot collapse the thread anymore (also without sorting). 

As example, these are the numbers of entries I obtain with my logbook :

  http://localhost:8080/mylogbook/?mode=threaded&expand=0     => 75 entries (OK)
  http://localhost:8080/mylogbook/?mode=threaded&expand=0&sort=EventID  =>  445 entries  (WRONG it should collapsed)
  http://localhost:8080/mylogbook/?mode=threaded&expand=0&Interaction=nuCC   => 335 entries 

However (considering the bug fixed for the collapsed thread display), breaking the thread is not a confortable solution. 
I choose to show the logbook in the threaded mode, because I'm interested in grouping the entries in threads. 
In my opinion, this feature is good (and it is my favourite) and should be preserved despite any sorting or filtering. 
This is why I suggest to ask to the user which entries (first or last) better applies for sorting and filtering. 

Ciao

   Gabriele


> You are absolutely right. When doing filtering, entries shown or not shown have not much to do with the filter. 
> Rather than messing around with first and last entries, I decided to break apart threads completely when doing 
> filtering, so the entries are treated as individual entries, just like what you do when filtering in summary mode. 
> This gives then consistent filtering results. The modification is done in revision 2282.
  66691   Mon Jan 18 02:14:01 2010 Reply Gabriele Sirrisirri@bo.infn.itQuestionWindows2.7.8-2283Re: quick filter

Stefan Ritt wrote:

deletoille wrote:

Stefan Ritt wrote:

deletoille wrote:

Hello,

We would like to use more the quick filter command on attributes.

On the other hand, when we use it, the result does not displaying entries which are in answer of another attribute. Is there a command which allow that possibility like when we select display full entries in the search mode?

Thanks in advance

Xavier

 

I don't understand your questions. Can you please give an example. 

 Sorry for my english. In fact, i found the answer by myself. But I ll explain to you.

in attachement 1, a small part of our ELOG. When I choose FBT in the quick filter "groupe incriminé". Elog respond that there is no entrie found (attachement 2)

But, with the find function, when i select display full entries and FBT in "groupe incriminé", Elog show the entrie ( attachement 3).

I found the answer. In fact, Elog respond no entrie when threaded is selected. I have to choose Full or summary for that working.

sorry

Xavier

Actually what you report is a bug. The filtering does not work in threaded display mode, only in summary and full. I fixed that bug in the current SVN version, so if you download and compile it, you can give it a try. The fix will be contained in the next official release.

Hello,

  I gave it a try. See: https://midas.psi.ch/elogs/Forum/66690

Gabriele




 

  66692   Mon Jan 18 08:18:48 2010 Reply Stefan Rittstefan.ritt@psi.chRequestWindows2.7.8-2283Re: Collapse to Last and Quick Filter
> However (considering the bug fixed for the collapsed thread display), breaking the thread is not a confortable solution. 

Well, but it's the only way which gives you a 1:1 correlation between what you filter and what you see below. If you want to 
see the full thread for an entry which gets shown after you apply a filter, just click on that entry, and you will be taken to 
the single entry display which shows the full thread on top of it. This is the only way I can keep search results consistent, 
so I would rather like to keep it like this.
  66711   Wed Feb 17 17:02:38 2010 Question soren poulsensoren.poulsen@cern.chBug reportLinux2.7.8-2282Problem using attribute type

Hi,

This little logbook has a problem:

------------------------

Attributes = Author, Category, Type, Subject, Number

Type Number = numeric

Options Category = General{1}
{1} Options Type = Routine

------------------------

(it was of course more complicated to start with).

When creating a new entry and selecting the Category option, there is a problem with the JavaScript which will populate the Type option.

To avoid the problem, I just comment out the line "Type Number ... "

 

Is this a bug ?

Thanks for your time

Soren

 

(P.S. Using a reserved name as an attribute name is maybe not optimal, but it does not seem to be the  problem).

 

 

 

 

 

  66712   Thu Feb 18 13:21:15 2010 Reply soren poulsensoren.poulsen@cern.chBug reportLinux2.7.8-2282Re: Problem using attribute type

soren poulsen wrote:

Hi,

This little logbook has a problem:

------------------------

Attributes = Author, Category, Type, Subject, Number

Type Number = numeric

Options Category = General{1}
{1} Options Type = Routine

------------------------

(it was of course more complicated to start with).

When creating a new entry and selecting the Category option, there is a problem with the JavaScript which will populate the Type option.

To avoid the problem, I just comment out the line "Type Number ... "

 

Is this a bug ?

Thanks for your time

Soren

 

(P.S. Using a reserved name as an attribute name is maybe not optimal, but it does not seem to be the  problem).

 

 

 

 

 

 To overcome this problem it is sufficient to switch language from "Language = french" to "Language = english"

It was a mistake not to include the "global" settings in this bug report.

What probably happens is that something in the French translation (accents ?) disturbs the java scripting.

Soren

 

  66713   Thu Feb 18 15:37:07 2010 Reply soren poulsensoren.poulsen@cern.chBug reportLinux2.7.8-2282Re: Problem using attribute type

soren poulsen wrote:

soren poulsen wrote:

Hi,

This little logbook has a problem:

------------------------

Attributes = Author, Category, Type, Subject, Number

Type Number = numeric

Options Category = General{1}
{1} Options Type = Routine

------------------------

(it was of course more complicated to start with).

When creating a new entry and selecting the Category option, there is a problem with the JavaScript which will populate the Type option.

To avoid the problem, I just comment out the line "Type Number ... "

 

Is this a bug ?

Thanks for your time

Soren

 

(P.S. Using a reserved name as an attribute name is maybe not optimal, but it does not seem to be the  problem).

 

 

 

 

 

 To overcome this problem it is sufficient to switch language from "Language = french" to "Language = english"

It was a mistake not to include the "global" settings in this bug report.

What probably happens is that something in the French translation (accents ?) disturbs the java scripting.

Soren

 

 To use "Language = french" it is necessary to remove or substitute the accent character ' with something else in eloglang.french and then the Javascript code works again.

Soren

  66726   Tue Mar 2 14:21:46 2010 Question soren poulsensoren.poulsen@cern.chQuestionLinux2.7.8-2282Thread view problem in searches

Hi,

When I upgrade from build 2278 to  2282 the thread view changes when performing searches: The thread children are not indented and there are no "thread icons" in the search list (e.g. like the read right arrow for replies).

On the forum site I also note that the thread view is not indented when performing searches.

Does anyone have an idea ?

Soren

 

  66733   Sat Mar 6 20:53:25 2010 Warning soren poulsensoren.poulsen@cern.chBug reportLinux2.7.8-2282Re: Thread view problem in searches

soren poulsen wrote:

Hi,

When I upgrade from build 2278 to  2282 the thread view changes when performing searches: The thread children are not indented and there are no "thread icons" in the search list (e.g. like the read right arrow for replies).

On the forum site I also note that the thread view is not indented when performing searches.

Does anyone have an idea ?

Soren

 

This seems to be a bug. I reproduced it with a different browser (Opera) with the default ELOG configuration. When I do Find and select Display Threads I have the message icons but the layout is not correct. Also, all message icons are of the "reply" type even if they are new threads.

This concerns only the latest build 2282.

Soren

 

ELOG V3.1.5-3fb85fa6