The ELOG repository has been moved from Subversion to GIT. While the old repository will be visible for some time, all new development is done on the GIT repository. To download the repository, do a

git clone https://bitbucket.org/ritt/elog.git
git clone https://bitbucket.org/tmidas/mxml.git


or access it online at https://bitbucket.org/ritt/elog/

/Stefan 

Hi all, 

Is it just my system or do others have this odd issue.

I have a pdf file which is 'upside-down', I attached it to an elog entry, and the .png image thumbnail was
generated.  Now this too was upside-down, so I tried to use the left (or right) rotation buttons along the top
of the image in elog to do a 180 degree rotation.
The first 90 degree rotation was fine, but the second attempt just made a smaller image.  
It happens with various pdf files generated by various software (in case).
I also tried it with a jpg file, in that case the second attempt enlarged the image.

I could not find any way to actually invert the .png image using elog; but I was surprised that a second
rotation ddid something different (change magnification) rather than nothing at all if it could only cope with a
90 degree rotation.

It's not a vital fix for me, but I have found the thumbnail (png) manipulation functions have a few rough edges,
so when necessary I use xv or gimp on the .png file to get what I want.

Or is this just my system?

> Hi all, 
> 
> Is it just my system or do others have this odd issue.
> 
> I have a pdf file which is 'upside-down', I attached it to an elog entry, and the .png image thumbnail was
> generated.  Now this too was upside-down, so I tried to use the left (or right) rotation buttons along the top
> of the image in elog to do a 180 degree rotation.
> The first 90 degree rotation was fine, but the second attempt just made a smaller image.  
> It happens with various pdf files generated by various software (in case).
> I also tried it with a jpg file, in that case the second attempt enlarged the image.
> 
> I could not find any way to actually invert the .png image using elog; but I was surprised that a second
> rotation ddid something different (change magnification) rather than nothing at all if it could only cope with a
> 90 degree rotation.
> 
> It's not a vital fix for me, but I have found the thumbnail (png) manipulation functions have a few rough edges,
> so when necessary I use xv or gimp on the .png file to get what I want.
> 
> Or is this just my system?

I just tried on the demo logbook:

https://midas.psi.ch/elogs/Linux+Demo/14

and it worked fine in rotating the image twice. Can you try yourself and find out if it's related to your installation if ImageMagic, or the actual image file?

/Stefan

> > Hi all, 
> > 
> > Is it just my system or do others have this odd issue.
> > 
> > I have a pdf file which is 'upside-down', I attached it to an elog entry, and the .png image thumbnail was
> > generated.  Now this too was upside-down, so I tried to use the left (or right) rotation buttons along the top
> > of the image in elog to do a 180 degree rotation.
> > The first 90 degree rotation was fine, but the second attempt just made a smaller image.  
> > It happens with various pdf files generated by various software (in case).
> > I also tried it with a jpg file, in that case the second attempt enlarged the image.
> > 
> > I could not find any way to actually invert the .png image using elog; but I was surprised that a second
> > rotation ddid something different (change magnification) rather than nothing at all if it could only cope with a
> > 90 degree rotation.
> > 
> > It's not a vital fix for me, but I have found the thumbnail (png) manipulation functions have a few rough edges,
> > so when necessary I use xv or gimp on the .png file to get what I want.
> > 
> > Or is this just my system?
> 
> I just tried on the demo logbook:
> 
> https://midas.psi.ch/elogs/Linux+Demo/14
> 
> and it worked fine in rotating the image twice. Can you try yourself and find out if it's related to your installation if ImageMagic, or the actual image file?
> 
> /Stefan

Hi Stefan,

Well I didn't crash the server this time, and I could invert the image in the demo logbook by doing two rotations.
But, this is elog v2.9.0-2435, and I am using v2.9.2-2475.  And I remember there was a recent issue about the image manipulation at some point, so I went to the
download section to read the subversion listing to find where this occurred.  But you've changed subversion!  I couldn't find my way around it, so I not only could
I find the changefile that showed what happened for each subversion issue, but even how I could download the current (or indeed any past) subversion issue.

As far as I can recall, you made a change, I reported an issue, and you undid the change, or partially undid it.  Do you know when this was?  Could it be relivent?

> Well I didn't crash the server this time, and I could invert the image in the demo logbook by doing two rotations.
> But, this is elog v2.9.0-2435, and I am using v2.9.2-2475.  And I remember there was a recent issue about the image manipulation at some point, so I went to the
> download section to read the subversion listing to find where this occurred.  But you've changed subversion!  I couldn't find my way around it, so I not only could
> I find the changefile that showed what happened for each subversion issue, but even how I could download the current (or indeed any past) subversion issue.
> 
> As far as I can recall, you made a change, I reported an issue, and you undid the change, or partially undid it.  Do you know when this was?  Could it be relivent?

I upgraded to V2.9.2, so please try again.

/Stefan

> > Well I didn't crash the server this time, and I could invert the image in the demo logbook by doing two rotations.
> > But, this is elog v2.9.0-2435, and I am using v2.9.2-2475.  And I remember there was a recent issue about the image manipulation at some point, so I went to the
> > download section to read the subversion listing to find where this occurred.  But you've changed subversion!  I couldn't find my way around it, so I not only could
> > I find the changefile that showed what happened for each subversion issue, but even how I could download the current (or indeed any past) subversion issue.
> > 
> > As far as I can recall, you made a change, I reported an issue, and you undid the change, or partially undid it.  Do you know when this was?  Could it be relivent?
> 
> I upgraded to V2.9.2, so please try again.
> 
> /Stefan

I can confirm this bug in V2.9.2. Also after submitting the entry, the orginal image is being displayed, with no rotation, resizing etc...

> I can confirm this bug in V2.9.2. Also after submitting the entry, the orginal image is being displayed, with no rotation, resizing etc...

Have you tried on the Demo logbook on the PSI server or on your installation. I just attached an image to this entry, rotated it twice, reduced its size 
and it works fine. The point is that I have to reproduce your bug in order to fix it, but it seems I cannot.

/Stefan

I've noted that you did your test with a PNG while he was reporting about a problem with a PDF. I'll give it a try with your server

Regards

Andreas

Cool: while it worked fine when I've created the entry, it stops working when I EDIT the entry that had been rotated! Actually it sometimes works and sometimes not.

As a workaround you can always go to "1:1" and then retry to rotate. That worked here.

Andreas

PS: I've noticed that the thumbnail PNG file only updated in the List view after I did a reload. I'm using Firefox 10.0.11 ESR on SL6.0.

 Hi all

Tested browsers on my SL6.4 desktop computer are Firefox 17.07, Konqueror 4.3.4. Here the rotation and rescaling is all wonky and the changes are  not saved when submitting the entry.

On my Android mobile phone (Chrome 28.0.1500.64) the images rotate and rescale nicely, but the changes are not saved aswell. I tried to force reloading and clearing my cache with all of the browsers.

The elogs I tested are served from Ubuntu 10.04.4 LTS and Debian 3.2.46-1 x86_64 running IM 6.5.7-8 and 6.7.7-10 respectively.

Martin

 Hi, 

One question, is possible activate auto-save while write a new "ticket"?

Thanks very much.

Regards Andreas

Great that you pointed out this possibility. I saw that Lazarus Form Recovery is even available for Google Chrome and it works fine. It however works only for the "EL Code" and "plain" encodings. In the "HTML" edit box it does not work (probably some collision with the FCKEditor). If anybody has an idea about this, please post it.

/Stefan 

Hi Stefan,

that reminds me of something: you've wanted to upgrade from the obsolete FCKEditor to the successor CKEditor. That would allow to use the cool editor for math formulas: http://www.fmath.info/plugins/CKEditor/demo.jsp

Cheers, Andreas

Hi everyone

The past few days I have been editing elogd.c to link all image files to the PIXLR-API (http://pixlr.com/). I am now at a point where the edited images are uploaded fine to the elog server, but in order for the thumbnails  to refresh one needs to click edit and thus load the FCKeditor for the corresponding entry.

Any suggestions how I may be able to enforce thumbnail generation, whenever the entry is displayed.

An alternative way might be to get the original entry id associated to an attachment, but I have not been able to achieve this either.

Best regards

Martin

Hi,

We have a fire preventive team at our company doing periodic inspections of our various corporate buildings.

If they find a deviation they want to register this somewhere.

So I thought E-log would be nice to use in this case.

The way the fire preventive team inspection works is building by building.

All the buildings has numbers.

So they want to be able to select a buildingnumber in E-log and filter on open,ongoing and closed records when they do their inspections.

And they also wants the filtering to stay on that choosen buildingnumber  despite if they delete or add new entries.

I know that you can have a default startview in E-log but this view is static.

Is it possible to do this in E-log?

You can define the building number as an attribute and use it in a quick filter. The startview will however not stay on one bilding. An alternative would be to define one logbook per building. 

 OK!

Thanks for the answer.
I thought that this was the way to go. The problem is that we have several hundreds of buildings.

/UlfO

Ouch! In principle the filtering could be stored in some cookie, but I would have to develop this, and I have currently no time for that. 

 OK!
Probably we partly can solve this via some intelligent sorting, but I wanted to check this with you first.

/UlfO

What is the differences between E-log windows version 2.9.2-2455 like we run and E-log windows version 2.9.2.-2475 ?

I cant find a changelog for this.

Best regards
/UlfO

 https://savannah02.psi.ch/viewvc/meg_elog/trunk/src/elogd.c?view=log

 OK!

Thank you very much

/UlfO

By default, elog enties are sorted by their ID number.  When viewing a logbook in Full or Summary, they are
shown in strict order of ID.  In Threaded, entries are shown in strict order of ID for the latest entry of each
thread, and then previous entries (in reply to) back from the latest one.  

In collapsed mode, it is only the starting entry of each thread is shown (or the latest one if "collapse to
last" chosen, but that's a detail).

I have a couple of logbooks where I'd like the default sorting to be by another numeric attribute that I enter. 

Now this works fine in Full or Summary mode.  In threaded mode (e.g. default for this forum, where every entry
is shown but are grouped by thread), it works in as much as all the entres are there and in order, but it
doesn't quite look the same as when sorting by ID - the replies are not each offset further right beneath the
entry it is in reply to, but all just slightly offset to the first entry.  

If you try to [completely] collapse the threaded mode to just one line per threaded topic - it doesn't.  Looks
(almost) the same as threaded.

I was hoping to get the list of entries collapsed to one line per thread, in order of the numeric attribute, but
I cannot seem to get this to happen.   Have I missed something here?  Or is it possible at all?

> By default, elog enties are sorted by their ID number.  When viewing a logbook in Full or Summary, they are
> shown in strict order of ID.  In Threaded, entries are shown in strict order of ID for the latest entry of each
> thread, and then previous entries (in reply to) back from the latest one.  
> 
> In collapsed mode, it is only the starting entry of each thread is shown (or the latest one if "collapse to
> last" chosen, but that's a detail).
> 
> I have a couple of logbooks where I'd like the default sorting to be by another numeric attribute that I enter. 
> 
> Now this works fine in Full or Summary mode.  In threaded mode (e.g. default for this forum, where every entry
> is shown but are grouped by thread), it works in as much as all the entres are there and in order, but it
> doesn't quite look the same as when sorting by ID - the replies are not each offset further right beneath the
> entry it is in reply to, but all just slightly offset to the first entry.  
> 
> If you try to [completely] collapse the threaded mode to just one line per threaded topic - it doesn't.  Looks
> (almost) the same as threaded.
> 
> I was hoping to get the list of entries collapsed to one line per thread, in order of the numeric attribute, but
> I cannot seem to get this to happen.   Have I missed something here?  Or is it possible at all?

This is not possible at the moment, but I will add it to the wish list.

> > By default, elog enties are sorted by their ID number.  When viewing a logbook in Full or Summary, they are
> > shown in strict order of ID.  In Threaded, entries are shown in strict order of ID for the latest entry of each
> > thread, and then previous entries (in reply to) back from the latest one.  
> > 
> > In collapsed mode, it is only the starting entry of each thread is shown (or the latest one if "collapse to
> > last" chosen, but that's a detail).
> > 
> > I have a couple of logbooks where I'd like the default sorting to be by another numeric attribute that I enter. 
> > 
> > Now this works fine in Full or Summary mode.  In threaded mode (e.g. default for this forum, where every entry
> > is shown but are grouped by thread), it works in as much as all the entres are there and in order, but it
> > doesn't quite look the same as when sorting by ID - the replies are not each offset further right beneath the
> > entry it is in reply to, but all just slightly offset to the first entry.  
> > 
> > If you try to [completely] collapse the threaded mode to just one line per threaded topic - it doesn't.  Looks
> > (almost) the same as threaded.
> > 
> > I was hoping to get the list of entries collapsed to one line per thread, in order of the numeric attribute, but
> > I cannot seem to get this to happen.   Have I missed something here?  Or is it possible at all?
> 
> This is not possible at the moment, but I will add it to the wish list.

OK, Thanks Stefan.

Hi all

I have setup an logbook that executes a number of shell scripts to preset attributes and append standart information, which works great. Now I am trying to daemonise the whole thing. I have tried the -D option as well as daemontools. In both cases the logbook itself is functional but the bash scripts do not get executed.

Any ideas how I can resolve this problem?

Martin

Usually the problem comes from the fact that a daemon runs from the root directory ('/') by definition. I might not find your scripts if they are not in the path. Try to call them explicitly with the ful path like "/usr/local/elog/script.sh".

/Stefan 

 I didn't know that. Thanks for the quick response. I have it working now :)