Demo Discussion
Forum Config Examples Contributions Vulnerabilities
  Discussion forum about ELOG, Page 467 of 808  Not logged in ELOG logo
    icon2.gif   Re: Several drop down menu's for a field, posted by Stefan Ritt on Sat Nov 22 20:45:05 2008 

 

Niall Dooley wrote:

Hi,

I was wondering if it is possible to have several drop down menus associated with a particular field. My problem is as follows, currently I have a particular field where its value is a name of a person obtained from a list of names from a drop down menu. However, I would like to be able to select on certain occasions more than one name from this same drop down list of names. 

The field name in question is "Call-out" as in the name of a person called out. I guess I could add another field say "Call-out 2" and have a drop down menu of names for this new field too but I would like to avoid this if possible. So I would like possiby to have two (or more) drop down menus side by side for this Call-out field which would each populate this one field with the names selected (if any) from each drop down menu. This way if only an a selection is made from the first drop down menu then it should work as it does currently but if an entry was also selected from the second drop down menu then both names should populate the field when the log is complete.

I hope I have been clear in my question/request? Many thanks in advance for any help or suggestions received.

 

Try

Moptions = name1, name2, ...

This gives you not a drop down list, but a series of check boxes, where you can select multiple persons simultaneously.

    icon2.gif   Re: Threaded emails, posted by Niall Dooley on Sun Nov 23 15:19:50 2008 

Stefan Ritt wrote:

 

Paul O'Shaughnessy wrote:

Can you email a thread of log entries. I think this would be a very useful function, which would enable the logger in effect to send an entire history of a particular issue to the interested parties.

 

 Well, kind of. If you notify yourself with elog entries, they are grouped in a thread in your email application. From there you can forward the thread to someone. Or you forward the link to one entry in the thread, and if the link is the opened, the interested parties see the whole link. Sending the whole thread inside elog is however not possible.

 Hi Stefan,

Your suggestion of emailing a link for a log entry with which any interested parties open the link are able to see the entire thread works. However, it does not display the additional text which may be added in the text box below the standard field entries. To view this additional text would require the email recipiant to log into the elog account. The only problem with this is the interested parties may not have the priviledges to log into the elog account. Thanks for your time.

    icon2.gif   Re: Threaded emails, posted by Stefan Ritt on Mon Nov 24 09:50:16 2008 

 

Niall Dooley wrote:

 

Stefan Ritt wrote:

 

Paul O'Shaughnessy wrote:

Can you email a thread of log entries. I think this would be a very useful function, which would enable the logger in effect to send an entire history of a particular issue to the interested parties.

 

 Well, kind of. If you notify yourself with elog entries, they are grouped in a thread in your email application. From there you can forward the thread to someone. Or you forward the link to one entry in the thread, and if the link is the opened, the interested parties see the whole link. Sending the whole thread inside elog is however not possible.

 

 Hi Stefan,

Your suggestion of emailing a link for a log entry with which any interested parties open the link are able to see the entire thread works. However, it does not display the additional text which may be added in the text box below the standard field entries. To view this additional text would require the email recipiant to log into the elog account. The only problem with this is the interested parties may not have the priviledges to log into the elog account. Thanks for your time.

 

 You could implemente guest read-only access to the logbook (like for this forum).

    icon2.gif   Re: Special characters in attribute names, posted by Steve Williamson on Mon Nov 24 13:49:56 2008 elogd.cfg.txttrace.txt

Stefan Ritt wrote:

 

Steve Williamson wrote:

Hi

Thanks for elog - it's a brilliant piece of software.  I'd looked all over for open source software to log/manage change requests before discovering elog; it's so flexible that I've been able to do everything I need with it.

However, I think that I've just discovered my first undocumented 'feature'.  Attribute names containing punctuation characters (e.g. / and :) cause "Redirection limit for this URL exceeded" errors in Firefox 3.0.2 and corrupt the URL if they're used in a Quick Filter.  I often use '/' in attribute names for brevity, e.g. "Old/New Versions" but hadn't used one in a Quick Filter before.

 

Quick answer: Don't use '/' in attribute names ;-) but I guess you were kind of afraid to get this answer.

Somehow longer answer: I tried to reproduce your problem with following configuration:

[demo]
Attributes = Author, Type, Subject, Old/New
Options Old/New = Old, New
Quick filter = Type, Old/New

But I was not successful. Everything worked fine using ELOG V2.7.5-2137. Can you please check with the above configuration and tell me exactly when the redirection problem occurs? Is it during filtering on already on creating a new entry?

 

 Thanks for the advice!

I've just had time to set up a test for this using both empty and populated logbooks (which don't have Hardware/Software in every entry as the field was added recently) and newly created logbooks (which have consistent attributes) and saw the problem on . 

The control ("Hardware/Software") causing the problem has three options "Hardware Only", "Software Only" and "Both".  The problem happens every time you click on the "-- Hardware/Software --" (i.e. All) option in the Quick Filter after having previously selected one (or more) of the options as a filter.  This produces the error:

The page isn't redirecting properly
Firefox has detected that the server is redirecting the request for this address in a way that will never complete.
*   This problem can sometimes be caused by disabling or refusing to accept cookies.

I ran elog with a trace (attached) which shows lots of:

select(1024, [5], NULL, NULL, {1, 0})   = 1 (in [5], left {1, 0})
recv(5, "GET /Change_Log/?Hardware%2FSoftware=_all_ HTTP/1.1\r\nHost: localhost:8080\r\nUser-"..., 100000, 0) = 619
stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=1323, ...}) = 0
time(NULL)                              = 1227528904
send(5, "HTTP/1.1 302 Found\r\nServer: ELOG HTTP 2.7.5-2130\r\nConnection: Keep-Alive\r\nKeep-A"..., 199, 0) = 199
send(5, "<html>redir</html>\r\n", 20, 0) = 20

messages after selecting "-- Hardware/Software --"

The only difference between today's test and last week's is that today the browser is on the local machine.

I also attach my (anonymised) elogd.cfg

Hope this helps

regards

Steve

 

    icon2.gif   Re: Special characters in attribute names, posted by Stefan Ritt on Mon Nov 24 17:53:23 2008 

Thanks to your detailed description I could reproduce and fix the problem. Please download SVN revision #2144 and give it a try.

icon1.gif   Auto-increment attributes, posted by Steve Williamson on Wed Nov 26 10:00:25 2008 

We have an auto-incrementing reference attribute defined as:

# RFC

Format RFC = 0,narrowattribname,narrowattribvalue,60,60
Preset RFC = RFC-######
Preset On Duplicate RFC = RFC-######
Tooltip RFC = A unique reference will be generated for this Request For Change

We also have a "Created by/when" attribute.  Looking at the values this seems to be set when the user clicks "New" whereas the time stamp that appears on the line after the  $@MID@$ seems to be set when the user clicks "Submit".

# Created

Format Created = 0,attribname,attribvalue,70,100
Preset Created = $long_name ($short_name) on $date
Preset On Duplicate Created = $long_name ($short_name) on $date

Every once in a while the incrementing stops working and the number 'sticks' or misses some out.  It looks as if it might be because multiple people are adding entries concurrently.  Could the occasion where there is a gap in the sequence (171-174) be where people abandoned changes (clicked on "Back") after having numbers allocated?  Here is a list showing the discrepancies.

Date        Item     Time Stamp (from the line after $@MID@$)  "Created" attribute time stamp

22/09/08    124      16:15:10                                   11:58

22/09/08    125      16:33:54                                   16:24

 

22/09/08    125      16:35:37                                   16:33              Should be 126

...

10/10/08    146      10:39:09                                   10:30                    Correct

10/10/08    146      10:46:57                                   10:35              Should be 147

10/10/08    147      13:04:03                                   13:02              Should be 148

10/10/08    148      15:11:38                                   15:00              Should be 149

...

17/11/08    171      10:21                                      10:17              Correct

17/11/08    174      14:30                                      13:47              Should be 172

17/11/08    175      16:14                                      16:04              Should be 173

17/11/08    176      16:49                                      16:38              Should be 174

...

25/11/08    187      15:49:58                                   15:47              Correct

25/11/08    187      15:52:39                                   15:48              Should be 188

25/11/08    188      16:49:56                                   16:44              Should be 189

25/11/08    188      16:52:40                                   16:40              Should be 190

25/11/08    188      16:55:17                                   16:43              Should be 191

Let me know if you need any more information.

regards

Steve


    icon2.gif   Re: Special characters in attribute names, posted by Steve Williamson on Wed Nov 26 12:49:08 2008 

Stefan Ritt wrote:

Thanks to your detailed description I could reproduce and fix the problem. Please download SVN revision #2144 and give it a try.

Tested SVN v 2147 and all looks OK

thanks

Steve

    icon2.gif   Re: Installation problems, posted by T. Ribbrock on Thu Nov 27 11:47:34 2008 
> The problem is not putting this into the "conrib" area, but supporting it. Since I don't have a Debian system, 
> may I suggest that you put it yourself into the elog:Contributions/ logbook. If people then get problems in the 
> future, they can contact you directly ;-)

I finally got round to do so. I've also included the changes suggested by Yoshio Imai (reload functionality).
Hopefully, it is useful for someone...
ELOG V3.1.5-3fb85fa6