| ID |
Date |
Icon |
Author |
Author Email |
Category |
OS |
ELOG Version |
Subject |
|
66608
|
Fri Nov 13 15:21:03 2009 |
 | David Pilgram | David.Pilgram@epost.org.uk | Request | Linux | 2.7.7-2264 | Re: List View: Attachments icon |
| Stefan Ritt wrote: |
| David Pilgram wrote: | Do you mean putting the paperclip icon to the left of the 'Thread display' (such as next to the
emoticons and other stuff we can put in this forum)? |
Ahh, now I see what you mean. Well, first you can configure the amount of things to be shown in the threaded display
already via "Thread display". So maybe you can strip down things to have not too long entries. Second, to get to the
attachment you click on the entry, then click on the attachment. So to save you one click, it would cost me a few hours
of work (literally during the weekend). So I'm not very convinced  |
In my version of firefox, the thread display usually word-wraps once I get to the emty-enty entry, so the paperclip icon being at the
end of the thread display is not a disaster. And let's be grateful that it does not pop up and say "you appear to be reporting
a bug in elog..." |
|
66617
|
Tue Nov 17 12:29:24 2009 |
| Steve Williamson | StephenWilliamson@Barnsley.gov.uk | Request | Linux | 2.7.7-2264 | Re: Re: List View: Attachments icon | Thanks for all of the contributions - all I meant in my original suggestion was that I'd like to be able to define which column(s) should hold the Attachments paperclip in the Full and Summary List Views, which I use all the time, to reduce the need to scroll horizontally on every page. This would be similar to being able to specify where the Edit control appears by specifying the Edit attribute in the "List Display" list.
... and I really didn't want to ruin another of Stefan's weekends or confuse anybody! |
|
66618
|
Tue Nov 17 13:44:04 2009 |
| Stefan Ritt | stefan.ritt@psi.ch | Request | Linux | 2.7.7-2264 | Re: Re: Re: List View: Attachments icon |
| Steve Williamson wrote: | Thanks for all of the contributions - all I meant in my original suggestion was that I'd like to be able to define which column(s) should hold the Attachments paperclip in the Full and Summary List Views, which I use all the time, to reduce the need to scroll horizontally on every page. This would be similar to being able to specify where the Edit control appears by specifying the Edit attribute in the "List Display" list.
... and I really didn't want to ruin another of Stefan's weekends or confuse anybody! |
Ok, now I got it. I will put that request on the wish list. For the moment, you can restrict the number of attributes shown in the list view with "List display = ...". This way you can maybe display less so that your table gets narrower and you save some scrolling. |
|
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. |
|
66690
|
Mon Jan 18 02:13:19 2010 |
| Gabriele Sirri | sirri@bo.infn.it | Request | Windows | 2.7.8-2283 | Re: 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. |
|
66692
|
Mon Jan 18 08:18:48 2010 |
| Stefan Ritt | stefan.ritt@psi.ch | Request | Windows | 2.7.8-2283 | Re: 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. |
|
66708
|
Wed Feb 10 15:27:43 2010 |
 | Paul O'Shaughnessy | paul_o'shaughnessy@inmarsat.com | Request | Windows | V2.7.8-228 | Last 3 days of log entries | Is it possible to create a drop down menu for the last 3 days of log entries. Currently we have the last day, month, 3 month, etc.
Reason being, after a weekend most people would like to view the log entries for the last three days. Can anyone help me out here? |
|