| ID |
Date |
Icon |
Author |
Author Email |
Category |
OS |
ELOG Version |
Subject |
|
66766
|
Mon Mar 15 18:58:06 2010 |
 | soren poulsen | soren.poulsen@cern.ch | Bug report | Linux | 2.7.8-2282 | Re: Thread view problem in searches |
| soren poulsen wrote: |
|
| Stefan Ritt wrote: |
|
| soren poulsen wrote: |
|
That sounds fine but I think there is a problem with rendering under Opera. I enclose a screen shot: There is too much white space in the lines, it seems  $
The problem only appears in Find
|
I just tried myself with V10.50, and things work fine, even in the find page:
Can you try on the forum, just to check if it's specific to your configuration?
|
Thanks. The Forum is fine. The problem is - apparently - specific to my installation. The white space origins in long sequences of " " (repeated); in the lines in Find.
Let me re-install with the latest version and see if I can solve it like that.
Soren
|
I have re-installed the latest, fastest, smartest, brightest version. And it all works perfectly! Thanks a lot for your help.
Soren |
|
66767
|
Tue Mar 16 11:58:55 2010 |
 | soren poulsen | soren.poulsen@cern.ch | Bug report | Linux | 2.7.8-2282 | Re: Thread view problem in searches |
| soren poulsen wrote: |
|
| soren poulsen wrote: |
|
| Stefan Ritt wrote: |
|
| soren poulsen wrote: |
|
That sounds fine but I think there is a problem with rendering under Opera. I enclose a screen shot: There is too much white space in the lines, it seems $
The problem only appears in Find
|
I just tried myself with V10.50, and things work fine, even in the find page:
Can you try on the forum, just to check if it's specific to your configuration?
|
Thanks. The Forum is fine. The problem is - apparently - specific to my installation. The white space origins in long sequences of " " (repeated); in the lines in Find.
Let me re-install with the latest version and see if I can solve it like that.
Soren
|
I have re-installed the latest, fastest, smartest, brightest version. And it all works perfectly! Thanks a lot for your help.
Soren
|
Everything is fine. But my users do not like that the threads are broken into individual entries and not shown as full threads as before. So I am stuck with the "old" version. This is probably asking for too much but would it be difficult to have a flag to specify if you want to benefit from the new behaviour or keep pre-2282 behaviour (with its inconvenience which led to the presentation change). It could even be a compile tag flag, if it just me (well, my users) who is asking for this.
Soren |
|
66659
|
Sat Jan 2 01:34:57 2010 |
 | Gabriele Sirri | sirri@bo.infn.it | Request | Windows | 2.7.8-2280 | Collapse to Last and Quick Filter | Hello,
I feel that the filter result could be confusing and unexpected when "COLLAPSE TO LAST" is enabled: you
filter the first entry but you show the last one. What is filtered doesn't correspond with what is shown (look
the attached example).
I suggest to implement an option to let the user decide which entry (first or last) should be retrieved for
filtering (a tentative patch is attached).
Thank you
Gabriele
P.S. A similar behaviour occurs when you sort the logbook: it could appear as not sorted because you sort the
first entry but the last one is shown. |
| Attachment 1: example.txt
|
Example:
Consider the Status attribute to define the progress of a task:
Attributes = Author, Task, Status
Options Status = Start, Step1, Step2, End
Thread Display = Task, Status
and logbook with three thread arranged like this:
|-- Task0, Start
| |-- Task0, Step1
| |-- Task0, Step2
|
|-- Task1, Start
| |-- Task1, Step1
|
|-- Task2, Start
It is collapsed to:
+-- Task0, Step2
+-- Task1, Step1
|-- Task2, Start
Now, if you filter the Status using the "Start" value, you obtain again:
+-- Task0, Step2
+-- Task1, Step1
|-- Task2, Start
In my opinion, this is a bit confusing.
Using Step1 or Step2 values, nothing is selected (also confusing).
|
| Attachment 2: elogd.c.patch
|
Index: elogd.c
===================================================================
--- elogd.c (revisione 2280)
+++ elogd.c (copia locale)
@@ -19539,6 +19539,19 @@
if (status != EL_SUCCESS)
break;
+ if ( getcfg(lbs->name, "Filter last entry", str, sizeof(str)) && atoi(str) == 1 ) {
+ /* search last entry in this thread */
+ if (reply_to[0]) {
+ search_last_reply(msg_list[index].lbs, &message_id);
+ size = TEXT_SIZE;
+ status =
+ el_retrieve(msg_list[index].lbs, message_id, date, attr_list, attrib, lbs->n_attr, text,
+ &size, in_reply_to, reply_to, attachment, encoding, locked_by);
+ if (status != EL_SUCCESS)
+ break;
+ }
+ }
+
/* apply filter for attributes */
for (i = 0; i < lbs->n_attr; i++) {
|
|
66670
|
Tue Jan 12 09:12:28 2010 |
| Stefan Ritt | stefan.ritt@psi.ch | Request | Windows | 2.7.8-2280 | Re: Collapse to Last and Quick Filter | > Hello,
> I feel that the filter result could be confusing and unexpected when "COLLAPSE TO LAST" is enabled: you
> filter the first entry but you show the last one. What is filtered doesn't correspond with what is shown (look
> the attached example).
>
> I suggest to implement an option to let the user decide which entry (first or last) should be retrieved for
> filtering (a tentative patch is attached).
>
> Thank you
>
> Gabriele
>
> P.S. A similar behaviour occurs when you sort the logbook: it could appear as not sorted because you sort the
> first entry but the last one is shown.
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. |
|
66685
|
Thu Jan 14 16:43:16 2010 |
| deletoille | xavier.deletoille@synchrotron-soleil.fr | Question | Linux | Windows | 2.7.8-2280 | quick filter |
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
|
|
66686
|
Thu Jan 14 16:44:49 2010 |
| Stefan Ritt | stefan.ritt@psi.ch | Question | Linux | Windows | 2.7.8-2280 | Re: quick filter |
| 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. |
|
66687
|
Thu Jan 14 17:14:21 2010 |
| deletoille | xavier.deletoille@synchrotron-soleil.fr | Question | Linux | Windows | 2.7.8-2280 | Re: quick filter |
| 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
|
| Attachment 1: exemple_1.JPG
|
|
| Attachment 2: exemple_2.JPG
|
|
| Attachment 3: Exemple_3.JPG
|
|
|
66688
|
Thu Jan 14 18:55:12 2010 |
| Stefan Ritt | stefan.ritt@psi.ch | Question | Linux | Windows | 2.7.8-2280 | Re: quick filter |
| 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. |
|