Demo Discussion
Forum Config Examples Contributions Vulnerabilities
  Discussion forum about ELOG, Page 729 of 808  Not logged in ELOG logo
New entries since:Thu Jan 1 01:00:00 1970
    icon2.gif   Re: Auto-increment attributes, posted by Steve Williamson on Fri Dec 5 16:14:19 2008 

Steve Williamson wrote:

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


 Hi

This is to let you know that the increment problem has just happened again.

Item 206 has timestamp (from the line after $@MID@$) of 11:59:45 and "created" attribute timestamp of 11:29

overlapping with this, a second item 206 has timestamp of 12:04:02 and "created" attribute of 11:53

So, both users were entering information between 11:53 and 11:59:45 and both picked up the same increment number.

There's no easy solution tho, is there? If you pick up the increment number at the start so it can be displayed on screen and ensure uniqueness then, if a user cancels a new entry you end up with "holes" in the sequence.  If you pick it up at the end then you can't display it until the user presses submit.

regards

Steve

    icon2.gif   Re: Auto-increment attributes, posted by Steve Williamson on Mon Dec 8 13:13:13 2008 

Stefan Ritt wrote:

I finally found some time to address this problem. It is indeed related to the fact that the new number gets assigned when you click on 'New'. So if two people edit the new entries at the same time, they get assigned the same number. To fix this problem, I made the tag generation work with the 'Subst' command, which is evaluated at the entry submission, and not when you click on 'New'. So to make this work, you need to upgrade to SVN revision 2152 and then put into your configuration file: 

Attributes = Author, RFC, Subject
Preset RFC = <will be assigned when you submit>
Preset on duplicate RFC = <will be assigned when you submit>
Locked attributes = RFC  Subst RFC = RFC-######

I also changed the documentation accordingly.

 Stefan

Thanks for fix - I've just tested it and it works beautifully.

regards

Steve

 

icon1.gif   Attachments, posted by Steve Williamson on Fri Feb 6 12:08:49 2009 

If I open an elog entry as read-only then attachments show as links which can be clicked to open the attachment.  However, if I open an entry using Edit then attachments show as text with a delete button - I would expect to be able to read attachments when editing an entry but there may be some good reason for not being able to.

Also, on attachments, if I click on the attachment icon (paperclip) on the list page the URL encodes "/" as "%2f", e.g.

http://xxx.xxx.xxx.xxx:8080/Change_Log/..%2FChange_Log%2F090205_123135%2FCHANGE_CONTROL_NOTICE_050209.doc and I get the following error:

"Invalid URL: Change_Log/..%2FChange_Log%2F090205_123135%2FCHANGE_CONTROL_NOTICE_050209.doc" .  If I then change all occurrences of "%2f" to "/" the link works.

We don't use attachments very often but occasionally they are just what you need - and so is elog!

great piece of software - many thanks for sharing it

Steve

 

 


    icon2.gif   Re: Attachments, posted by Steve Williamson on Tue Feb 17 12:28:19 2009 

Stefan Ritt wrote:

 

Steve Williamson wrote:

Also, on attachments, if I click on the attachment icon (paperclip) on the list page the URL encodes "/" as "%2f", e.g.

http://xxx.xxx.xxx.xxx:8080/Change_Log/..%2FChange_Log%2F090205_123135%2FCHANGE_CONTROL_NOTICE_050209.doc and I get the following error:

"Invalid URL: Change_Log/..%2FChange_Log%2F090205_123135%2FCHANGE_CONTROL_NOTICE_050209.doc" .  If I then change all occurrences of "%2f" to "/" the link works.

 

You have an old version of elog, this bug has been fixed some time ago. Have a look for example at https://midas.psi.ch/elogs/Linux+Demo/.

If you click on a peperclip there, the attachment is shown correctly. 

 Thanks - just downloaded and compiled the latest version and all is well

icon3.gif   Formatting list page data, posted by Steve Williamson on Wed Jun 10 09:16:55 2009 

Thanks for a great piece of software - it does so much and is (mostly) so simple to use.  However, I do have a suggestion that (for me, at least) would make it even better -

I use elog for a variety of logging tasks but find that, because I want to see as complete a summary as possible, the list page can get very crowded with longer fields wrapping over several lines.  I would like to have more control over the way attributes are displayed here.  Specifically, being able to truncate data (e.g. to show just the first n characters of a description), being able to select a substring (e.g. displaying characters before the '@' character to remove the domain from an email address or displaying characters after the space to remove the day from a date in ddd dd/mm/yy format) and being able to concatenate fields (e.g. to show a reference in a single cell as "Incident 1234" by joining call type and call reference attributes).

regards

Steve

    icon2.gif   Re: Formatting list page data, posted by Steve Williamson on Fri Jun 26 14:34:58 2009 

Stefan Ritt wrote:

Steve Williamson wrote:

Thanks for a great piece of software - it does so much and is (mostly) so simple to use.  However, I do have a suggestion that (for me, at least) would make it even better -

I use elog for a variety of logging tasks but find that, because I want to see as complete a summary as possible, the list page can get very crowded with longer fields wrapping over several lines.  I would like to have more control over the way attributes are displayed here.  Specifically, being able to truncate data (e.g. to show just the first n characters of a description), being able to select a substring (e.g. displaying characters before the '@' character to remove the domain from an email address or displaying characters after the space to remove the day from a date in ddd dd/mm/yy format) and being able to concatenate fields (e.g. to show a reference in a single cell as "Incident 1234" by joining call type and call reference attributes).

regards

Steve

Something along these lines is however not implemented (and hard to do). The only chance you have is to export your data into a spreadsheet and do the reformatting/report generation there. 

 Thanks for looking at the suggestion - it was only a 'nice to have', whereas elog is an essential!

regards

    icon5.gif   Re: Logbook Parser, posted by Steve Williamson on Tue Aug 11 13:02:22 2009 

Stefan Ritt wrote:

Alan Grant wrote:

We are exploring whether it's possible/feasible to import ELog logbooks into a another database for special purposes (plotting/statisical, etc). Target database is TBD (perhaps Access).

Does anyone have or know of a logbook parser program? From cut/pasting into, for example, Excel, it does appear that the data fields are already line-feed delimited so offhand it would seem possible to parse if one really wanted to pursue it.

Regards,

- Alan

You can export to CSV (comma-separated-values) if you go to "Find" and then click on "Export: CSV". These fiels you ran read right into Excel or other spreadsheet programs for further analysis. 

excuse my butting in ...  I've found the exports useful in the past - however, is is possible to run the export from a script in order to produce reports?  Utilities like wget won't work as the export process doesn't return the data as html.

regards

Steve

 

    icon2.gif   Re: Logbook Parser, posted by Steve Williamson on Wed Aug 12 14:40:52 2009 

Stefan Ritt wrote:

Steve Williamson wrote:

excuse my butting in ...  I've found the exports useful in the past - however, is is possible to run the export from a script in order to produce reports?  Utilities like wget won't work as the export process doesn't return the data as html.

That's not true. wget does work. Try that one:

wget --no-check-certificate -O export.csv https://midas.psi.ch/elogs/linux+demo/?mode=CSV1

actaully wget doesn't care if the return is HTML or a GIF image or anything else, it just saves it into the output file.

you're right, of course, on all counts!

when I was testing wget/elog to try to automate an extract I was getting a lot of stuff like:

/Change_Log/587">Software Only</a></td><td class="92^M^H<88>^\ÿ^Y"ÿ"><a href="../Change_Log/587">23416</a></td><td class="92^M^H<88>^\ÿ^Y"Ã<a href="../Change_Log/587">New</a></td><td class="92^M^H<88>^\ÿ^Y"ÿ"><a href="../Change_Log/587">Awaited</a></td>

but I must have been getting something wrong, using your command line as an example it works perfectly!  Thanks again for elog!!

ELOG V3.1.5-3fb85fa6