ID |
Date |
Icon |
Author |
Author Email |
Category |
OS |
ELOG Version |
Subject |
67349
|
Tue Oct 2 21:58:20 2012 |
| David Chastain | David_Chastain@sra.com | Question | Linux | 2.9.1 | Importing XML | I was wondering if anyone out there has had any success with importing XML data into ELOG. Using the XML schema which I derive from the EXPORT data from ELOG into XML format or creating the file from scratch, I either blowup the system and have to restart elogd or it doesn't work and says, XML file doesn't contain ELOG_LIST element (which I create and it still doesn't work).
Basically, I am trying to take spreadsheet data, convert it into XML and upload it as a logbook so I don't have to perform lots of data entry. I also tried .CSV but have had no luck.
Any thoughts or ideas? |
69835
|
Wed Sep 25 14:21:33 2024 |
| David Pilgram | David.pilgram@epost.org.uk | Question | Windows | 2.9.2 | Re: Looking for version update advice | I use linux elog, and if you upgrade to v3.x.x, it's difficult to go back to v2.9.x. This is because the log files get grouped in year sub directories at v3.x.x.
In 2.9.x, the logfiles are store as (made up example) /home/logfiles/yymmdda.log
In 3.x.x they are stored as /home/logfiles/2024/24mmdda.log /home/logfiles/2023/23mmdda.log etc. I think I got the labelling of the subdirectories correct, Stefan will no doubt correct if I am wrong.
I assume the same is true for the Windows version as it would be weird for a split in the program by OS for something important but trivial to impliment for all OS.
It's a bore to sort that out if you have to revert to 2.9.x - I know, I've done it - but I don't recall any change in format in the individual yymmdda.log files with an early v3.x.x version I tried. There may be additions to the log files made in much more recent v3.1.x or so versions, but I guess you are ok with whatever they may be as you've checked the change log.
Patrick Upson wrote: |
Thanks. I did eveuntaully find the change log and made the decision to upgrade the at-sea machines. So far the configuration file we update for each mission still works. I have a copy of the 2.9.2 installer that if something catostrophic happens I can remove the new version and take it back, but I don't think it'll be a problem. We archive logbooks at the end of a mission, but each mission basically starts from a fresh install like state anyway.
Stefan Ritt wrote: |
If 3.1.4 runs safely on your laptop, there should be no problem to update the 2.9.2 one. But first do it on a copy of your logbooks from the at-sea. The get converted automatically into a newer format but that should be transparent.
On the other hand you don't really need a new system if your old installation works fine and you don't need any of hte new features.
The changelog ist here: https://elog.psi.ch/elog/download/ChangeLog
Stefan
Patrick Upson wrote: |
I've inherited a position that includes deploying elog for an at-sea mission. Once at sea there's no gauntee of internet connection so I have to be sure things are going to work before hand. The machines I currently have (we have several backup machines) are running elog version 2.9.2 and I'm looking for a change log, or feature list to determine if it's safe to update the at-sea laptops to the latest version of elog.
On one hand, I could leave things as they are and I'm sure it will just work, on the other hand, I hate seeing things get out of date to the point that something just stops working some day and there's no ability to get support for old software.
I'm already running elog 3.1.4 on my personal machine I use for configuration development and testing and it seems to work well. The config file is pretty simple and seems to work with 2.9.2 on the at-sea machines, but I don't want to run into any suprises if there ends up being a compatibility issue at sea.
|
|
|
|
65767
|
Tue Mar 4 14:03:00 2008 |
| David Pilgram | David.Pilgram@epost.org.uk | Bug report | Linux | 2.7.3-2058 | Quick filter by ID | Hi,
I've just upgraded from 2.6.2 to 2.7.3.
In my config file, I have
Quick filter: Date, ID.
When starting 2.7.3, across the top I now get
"Error: Attribute "ID" for quick filter not found"
followed by an entry box.
If an ID is typed into that box, it sort of finds the right entry (+/- a few on occasion).
I cannot see any documented change that would affect how the Quick filter works. Any clues? Thanks. |
65774
|
Fri Mar 7 13:12:37 2008 |
| David Pilgram | David.Pilgram@epost.org.uk | Bug report | Linux | 2.7.3-2058 | Re: Quick filter by ID | > > Hi,
> >
> > I've just upgraded from 2.6.2 to 2.7.3.
> >
> > In my config file, I have
> >
> > Quick filter: Date, ID.
> >
> > When starting 2.7.3, across the top I now get
> >
> > "Error: Attribute "ID" for quick filter not found"
> > followed by an entry box.
> >
> > If an ID is typed into that box, it sort of finds the right entry (+/- a few on occasion).
> >
> > I cannot see any documented change that would affect how the Quick filter works. Any clues? Thanks.
>
> Actually it is nowhere written the 'ID' for a quick filter should work. After investigating, I realize that it
> worked previously "by accident". I added in meantime some test so there is a warning for quick filter attributes
> which do not exist, and that's what you got. I loosened this test for 'ID' now in the current SVN version, so it
> can be used. It does however not display the single entry you want, but a page containing that entry (which then
> is displayed in bold). If you want exactly one entry, just add it's ID to the URL, like
>
> https://midas.psi.ch/elogs/Forum/65767
>
> for your previous entry.
Thanks Stefan! |
65780
|
Fri Mar 7 21:26:18 2008 |
| David Pilgram | David.Pilgram@epost.org.uk | Info | Linux | ELOG V2.7. | Re: Message ID and trouble ticketing system | >Stefan Ritt wrote:
>
>Ok, now I got the point, also Richard had the same problem. Assume we have 10 threads, and thus
>ticket numbers 1-10. Now we get a reply to #2, which then pops up to the top of the list. A new
>message increments the top entry of all entries, and then wrongly gives a new #3, instead of #11.
>
>I fixed this in SVN revision 2073, where elogd searches *all* logbook entries for the largest
>index, then increments this one by one. The fix will be contained in the next release.
----
Great! Thanks Stefan, off to download right now!
Great program, by the way, but don't think you need to be told that yet again! |
65781
|
Fri Mar 7 21:53:28 2008 |
| David Pilgram | David.Pilgram@epost.org.uk | Info | Linux | 2.7.3-2073 | Re: Message ID and trouble ticketing system | >>Stefan Ritt wrote:
>>
>>Ok, now I got the point, also Richard had the same problem. Assume we have 10 threads, and thus
>>ticket numbers 1-10. Now we get a reply to #2, which then pops up to the top of the list. A new
>>message increments the top entry of all entries, and then wrongly gives a new #3, instead of #11.
>>
>>I fixed this in SVN revision 2073, where elogd searches *all* logbook entries for the largest
>>index, then increments this one by one. The fix will be contained in the next release.
>
>----
>
>Great! Thanks Stefan, off to download right now!
>
>Great program, by the way, but don't think you need to be told that yet again!
---
Oh ho!
I've tried this on an existing database, where most entries do not have a ticket #. The previous entry #
(previous in ID sense) is T00550, say. But when I start a new thread, the ticket # is T00001. Is it being put
out by no entry for ticket # in most of the database?
LATER UPDATE.
On a small database (12 entries, with 45 comments in total), this worked as expected if most or all entries have ticket numbers, even if the previous (by id #) had not had a ticket number. (I had to edit every entry to put in ticket numbers).
The only thing I can think of is the number of entries that don't have a ticket #, or a line in the .log file entry saying "Ticket: " but am looking further into this.
(BTW, am posting this way to get around the proxy server problem I have!) |
66219
|
Sat Feb 21 23:08:54 2009 |
| David Pilgram | David.Pilgram@epost.org.uk | Request | Linux | 2.7.5-2130 | Idea/Suggestion | Hi Stefan,
In the past I have requested the "mark whole thread" feature, not yet implimented. At present, I
edit (in my case) the icon on the first entry to indicate current status of the thread. I have
had an idea connected to this.
If you view a page, in threaded form, and collapsed, the header of the first entry of each thread is
shown. The order, however, is that of the timed order of the latest entry in that thread.
As an option, under the same circumstances (threaded, collapsed), if the header of the most recent
entry was shown, then that could also be an indicator of closed thread, or of "marking whole thread"
option (maybe would be enough for those who desire those features). It also gives an indication of
the current status of the thread without having to edit the original entry of the thread to edit
(for example) the icon.
Just a thought on how to improve a wonderful program ;-) |
66231
|
Mon Mar 2 22:00:33 2009 |
| David Pilgram | David.Pilgram@epost.org.uk | Request | Linux | 2.7.5-2130 | Re: Idea/Suggestion | Hi Stefan,
Must have missed it when the fixed/not fixed thread marking got implimented.
Anyhow, my main point would still apply for where the thread is not yet fixed, but is in one of a number of possible
states (waiting, panic, work-in-progress....). Clearly you can label the latest entry in a thread with the latest
status, and icon, but when in collapsed mode, you only see the initial entry. If the latest entry were shown
(optionally), then one can tell at a glance in the collapsed listings which entry may need direct attention.
> > In the past I have requested the "mark whole thread" feature, not yet implimented.
>
> That's not correct, it is implemented. Just add an attribute for that. Assume you have problem reports, so you
> add
>
> Attributes = ..., Fixed
> Options Fixed = boolean
> Quick filter = Fixed
>
> If you add a new entry, "Fixed" is false by default. All replies to that entry will contain then the same flag.
> Now if you want to mark the whole thread as fixed, do the following:
>
> - go into list display
> - display all entries in threaded mode
> - click on "Select"
> - select the thread you want to mark as fixed and click "Edit"
> - now keep all attributes, but check the "Fixed" check box
>
> and voila, the whole thread will contain "Fixed = 1". Using the quick filter, you can now show all fixed threads
> with one click. |
|