| ID |
Date |
Icon |
Author |
Author Email |
Category |
OS |
ELOG Version |
Subject |
|
69365
|
Thu May 20 21:01:41 2021 |
 | Gabriel Lopez | gabelopez@bnl.gov | Question | Linux | 3.1.4-3 | New user not working | Running elog-3.1.4-3 Can't add users through the web interface. Clicking add user and writing all the fields in with something doesn't add a user into the PWD file of that logbook. Running a tail -f on the password file shows elog writes the user info with the hashed password 3 times and then deletes the information about 20 seconds later. Has anyone else had a similar issue? This is running on RHEL8.3 |
|
66317
|
Wed Apr 15 11:43:14 2009 |
| Gabriele Sirri | sirri@bo.infn.it | Question | Windows | 2.7.6-2191 | ROptions value changed in the edit page | When ROptions items contain the same substring and this substring is also an ROptions item (ex: notdone,
done), the value of the entry could change in the edit page.
It depends on the item order in the config file.
If Options is used (instead of ROptions), it works as expected.
Is it a bug?
Examples :
#Insert "notdone" as new entry. When you try to edit the entry, the displayed value is "done".
[test_bad]
Attributes = Author, Category
ROptions Category = notdone, done
#No problem if you change the item order
[test_good]
Attributes = Author, Category
ROptions Category = done, notdone |
|
66563
|
Sat Oct 24 01:10:24 2009 |
| Gabriele Sirri | sirri@bo.infn.it | Bug report | All | 2.7.7-2254 | "Collapse to last = 1" problem when reply twice to the same entry | Hello.
Please look at the entry 66525 of this forum (just 5 thread before this one):
-> chain.crt, posted by Gerhard Schneider on Thu Sep 3 21:55:52 2009 (66525)
|-> Re: chain.crt, posted by Stefan Ritt on Fri Sep 4 08:33:16 2009 (66526)
|-> Re: chain.crt, posted by Gerhard Schneider on Wed Oct 7 07:56:52 2009 (66556)
When you collapse the thread, it is collapsed to the 66526 instead of the 66556 (more recent)
+ Re: chain.crt, posted by Stefan Ritt on Fri Sep 4 08:33:16 2009
I guess it is because both 66526 and 66556 replies to the first entry.
I have the same problem with Elog v2.7.7-2246 and Windows.
In general, it seems to work well only if you always reply to the last entry of a thread.
Thank you.
b.t.w. : is there any tip to always force reply to the last entry of a thread? |
|
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++) {
|
|
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. |
|
66691
|
Mon Jan 18 02:14:01 2010 |
| Gabriele Sirri | sirri@bo.infn.it | Question | Windows | 2.7.8-2283 | Re: 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
|
|
67331
|
Fri Sep 7 18:19:38 2012 |
| Garret Delaronde | garret.delaronde@gmail.com | Bug report | Windows | 2.9 | Type <attribute> = Date - Issue | I haven't found anything in the forums about this. Apologies if its a duplicate.
I am fairly familiar with ELog, use it for multiple purposes on 5 different Virtual Servers at work.
Currently looking to do some updates to one of the instances with the Date Type setting.
We have 17,000 entries all which have had manual entries for a Date Attribute for the last year and 8 months.
Due to regular entry errors on part of our contractors using it, (Eg: using "Aug" instead of "08", or using "-" instead of "/"), I want to change over to using the date type attribute (Type <attribute> = Date).
However the problem i found, the moment i save this in the config, and go to the list of entries, the date has changed on all of the entries to 12/31/1969. Which is BAD for our operation. So after removing the Type Date Setting the dates go back to normal.
Is there anyway to retain those dates so they display as they are and then only new entries would fall under the new date type setting?
Syntax manual didn't help much for this issue. |
|
67333
|
Mon Sep 10 17:18:03 2012 |
| Garret Delaronde | garret.delaronde@gmail.com | Bug report | Windows | 2.9 | Re: Type <attribute> = Date - Issue |
| David Pilgram wrote: |
|
| Garret Delaronde wrote: |
|
I haven't found anything in the forums about this. Apologies if its a duplicate.
I am fairly familiar with ELog, use it for multiple purposes on 5 different Virtual Servers at work.
Currently looking to do some updates to one of the instances with the Date Type setting.
We have 17,000 entries all which have had manual entries for a Date Attribute for the last year and 8 months.
Due to regular entry errors on part of our contractors using it, (Eg: using "Aug" instead of "08", or using "-" instead of "/"), I want to change over to using the date type attribute (Type <attribute> = Date).
However the problem i found, the moment i save this in the config, and go to the list of entries, the date has changed on all of the entries to 12/31/1969. Which is BAD for our operation. So after removing the Type Date Setting the dates go back to normal.
Is there anyway to retain those dates so they display as they are and then only new entries would fall under the new date type setting?
Syntax manual didn't help much for this issue.
|
Hi Garret,
Why cannot you just use $entry time ? It uses the date that the entry was made which appears as the first line of every elog entry -
[Sorry for mis-post, just discovered cannot put the 'dollar at' control set in an entry]
MID: 12458
Date: Fri, 07 Sep 2012 17:22:06 +0100
In reply to: 12453
You can use 'Time format = ' to get the date to display in the format you like. You will see I have posted an issue about 'Date format = '. I mention this because in trying to understand what was happening, I too had a case where all the dates were showing as the same in a thread. I suspect your 12/31/1969 was due to the entries as being read were non-existant or blank.
Of course I may have mis-understood your requirements.
|
Tried using the Time format setting, however I only want the time to be selected, so when i enter the datetime type it shows the date and time.
If there was a way to just have the time to be drop down menus vs the date and time all together, I would find that helpful.
As for the "$entry time" suggestion, it only serves to log the exact time the entry was made into elog. Where as I want it to be manually set.
In this example we've created an sql script to pull information from an oracle database, which then creates an elog entry.
We have multiple fields which are populated and locked so only admin can edit them.
Our contractor then edits the entry with a date / time / location, and a few other things.
the Date and Time are separate attributes. We'd prefer to keep it like that just because of the other scripts that run on the elog entries, (pulls day by day reports and formats and calculates summaries in excel automatically).
Any other suggestions would be helpful.
Thanks for your reply. |
|