| ID |
Date |
Icon |
Author |
Author Email |
Category |
OS |
ELOG Version |
Subject |
|
66749
|
Fri Mar 12 09:27:25 2010 |
 | Stefan Ritt | stefan.ritt@psi.ch | Bug report | Linux | 2.7.8-2282 | Re: Problem using attribute type |
| soren poulsen wrote: |
|
| 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
|
Indeed it was the JavaScript line
if (document.form1.Number.value != '- garder les valeurs d'origine -') {
which caused the trouble. The "'" character closed the string '- garder les valeurs d', which caused an exception. I changed it to
if (document.form1.Number.value != "- garder les valeurs d'origine -") {
and now it should work fine. |
|
66759
|
Sun Mar 14 20:57:26 2010 |
| soren poulsen | soren.poulsen@cern.ch | Bug report | Linux | 2.7.8-2282 | Re: Problem using attribute type |
| Stefan Ritt wrote: |
|
| soren poulsen wrote: |
|
| 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
|
Indeed it was the JavaScript line
if (document.form1.Number.value != '- garder les valeurs d'origine -') {
which caused the trouble. The "'" character closed the string '- garder les valeurs d', which caused an exception. I changed it to
if (document.form1.Number.value != "- garder les valeurs d'origine -") {
and now it should work fine.
|
Thanks a lot for changing that. Now French should work as well.
Soren |
|
66760
|
Sun Mar 14 21:04:44 2010 |
| soren poulsen | soren.poulsen@cern.ch | Bug report | Linux | 2.7.8-2282 | Re: Thread view problem in searches |
| Stefan Ritt wrote: |
|
| soren poulsen wrote: |
|
|
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
|
That's not a bug, that's a feature 
But honestly, this feature was requested recently and implemented. See https://midas.psi.ch/elogs/Forum/66670. So when searching, the thread organization is broken up and messages are treated independently. If you want to see the thread for a certain entry in you search result page, click on that entry and you will see the full thread above the entry.
|
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
Soren |
| Attachment 1: elog.jpg
|
|
|
66761
|
Mon Mar 15 08:23:45 2010 |
| Stefan Ritt | stefan.ritt@psi.ch | Bug report | Linux | 2.7.8-2282 | Re: Thread view problem in searches |
| 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? |
|
66765
|
Mon Mar 15 18:35:26 2010 |
| soren poulsen | soren.poulsen@cern.ch | Bug report | Linux | 2.7.8-2282 | Re: Thread view problem in searches |
| 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 |
|
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++) {
|
|