Hi Stefan,

>Sure, but that works only from a hidden logbook into a public one, not the other way, but I think this is what
>David wants. Since the hidden attachment is not accessible from the public logbook, there is no way around that
>other than physically copy the message, then strip maybe the text. 

(as per my reply to Andreas)

>He is concerned about having the same attachment twice on disk, which I cannot fully understand. Even large
>attachments are maybe 10 or 20 MB, otherwise they take forever to go through your browser. With a modern 1 TB
>disk these are 50.000 attachments

I've not mentioned it, but the entire logbook directory and subdirectories have to squeeze into a memory stick,
along with other data not at issue here.   Soon be too much for an 8GB stick, so that a factor of 100 down on
the available memory space.

But I can work with the solution I gave in the reply to Andreas.

> I wondered if there had been some flag for the config file whereby the original file for attachment was
> processed by ImageMagick, but not stored, only the .png file(s) stored - or rather, some other way that achieved
> the same end. as there is no such flag at present.
> 
> For now, anyway, I can attach the documents/pics I want, then go in and delete the 'originals' as saved in the
> logbook, leaving just the .png files. But maybe something for the wishlist?

At least I now understood your problem :-)

You can have a script in your hidden logbook, that processes your attachments with "execute new", create thumbnails
of them (using ImageMagicks "convert") and submit those thumbnails as one additional entry to your public logbook.

But then you would get thumbnails of all attachments of the hidden logbook in the public one, maybe you don't want
that either? If you want them all, this method is more automated. If you just want some, do it as you suggested it.

In my opinion this is a rather exotic feature request :-)
I wonder if there is a second person in the world who could use it?

> > I wondered if there had been some flag for the config file whereby the original file for attachment was
> > processed by ImageMagick, but not stored, only the .png file(s) stored - or rather, some other way that achieved
> > the same end. as there is no such flag at present.
> > 
> > For now, anyway, I can attach the documents/pics I want, then go in and delete the 'originals' as saved in the
> > logbook, leaving just the .png files. But maybe something for the wishlist?
> 
> At least I now understood your problem :-)
> 
> You can have a script in your hidden logbook, that processes your attachments with "execute new", create thumbnails
> of them (using ImageMagicks "convert") and submit those thumbnails as one additional entry to your public logbook.
> 
> But then you would get thumbnails of all attachments of the hidden logbook in the public one, maybe you don't want
> that either? If you want them all, this method is more automated. If you just want some, do it as you suggested it.
> 
> In my opinion this is a rather exotic feature request :-)
> I wonder if there is a second person in the world who could use it?

Hi Andreas,

True, as a feature explained here, it may not be the most frequently used ;-)

And you are right, I would not want *all* attachements in the hidden directory to appear in the public.  But I've got
quite used to playing around in the logbook subdirectories now.

In my case, the ever-expanding use I make of ELOG - and the fact that I use it with the logbook directory stored on a
memory stick (to move from location to location and use local computers, and that's partly to ensure the hidden
directory stays hidden!) - does mean I sometimes run into issues that some hyper-networked system with ZB of storage
don't even notice. 

If you use an attribute "Entry" then the internal variable "entry time" will expand to the last value of
"$Entry"+" time", e.g. if you use it in "Thread display = $entry time, ..."

One side effect is, that the logbook selection page defaults to use
Last submission = $entry time by $author
Which then expands to an undesired result.

This is not really a bug, rather something you'll need to keep in the back of your mind.

Hi,

I'm currently trying to setup a logbook which will contain process descriptions. One of the attributes will be the resists that are used. This could be more than one resist, hence I try to use MOptions but users should also be able to add materials to the selection list. When I write the following, I get some problems though:

Required Attributes = Name, Author, Resists
MOptions Resists =  Nano Copolymer EL-10, S1813
Extendable options = Resists

If a user wants to add a resist, he gets a textbox to add the new resist (which will contain what was already toggled), but there is now way to select also other resists that are already available, without saving the post and than edit it again. Previously selected resists are deselected when a new resist is added (if the user had emptied the textbox) and one can not save the newly added attribute option without saving the whole entry.

Is there a nice way to implement this (am I overlooking an obvious solution), or is this not possible at all. I guess an ideal solution would be to get some sort of ok button when one adds an attribute option and after confirming the new value that one gets back to the checkboxes without exiting the edit mode.

Regards,

Michaël

PS: This is the complete config for this logbook:

Theme = default
Page Title = $logbook - $Name
Edit Page Title = $logbook
Comment = Photolithography Processes

Quick filter = Name, Resists
Preset Author = $long_name
Reverse sort = 1

Attributes = Name, Author, Resists
Sort Attributes = Resists, Name, Author
Required Attributes = Name, Author, Resists
MOptions Resists =  Nano Copolymer EL-10, S1813
Extendable options = Resists
Sort Attribute Options Resists = 1

List display = Name, Author, Resists

Andreas Luedeke wrote:

Christian Herzog wrote: [...] we're evaluating elog right now at the Physics Department of ETH Zurich and I'm trying to come up with a good config. One of the first steps of course was to enable SSL/https. With http, all tested browsers work fine, but with https at least Google Chrome 16 and IE 9 do not get past the "unknown certificate" warning and I see "TCP connection broken" errors in the log file. Firefox however works fine. Same behavior on Linux, Mac and Windows (given the browser in question is available). elog server is running on Lucid.[...]   Afrikaans Albanian Arabic Armenian Azerbaijani Basque Belarusian Bulgarian Catalan Chinese (Simplified) Chinese (Traditional) Croatian Czech Danish Detect language Dutch English Estonian Filipino Finnish French Galician Georgian German Greek Haitian Creole Hebrew Hindi Hungarian Icelandic Indonesian Irish Italian Japanese Korean Latin Latvian Lithuanian Macedonian Malay Maltese Norwegian Persian Polish Portuguese Romanian Russian Serbian Slovak Slovenian Spanish Swahili Swedish Thai Turkish Ukrainian Urdu Vietnamese Welsh Yiddish ⇄ Afrikaans Albanian Arabic Armenian Azerbaijani Basque Belarusian Bulgarian Catalan Chinese (Simplified) Chinese (Traditional) Croatian Czech Danish Dutch English Estonian Filipino Finnish French Galician Georgian German Greek Haitian Creole Hebrew Hindi Hungarian Icelandic Indonesian Irish Italian Japanese Korean Latin Latvian Lithuanian Macedonian Malay Maltese Norwegian Persian Polish Portuguese Romanian Russian Serbian Slovak Slovenian Spanish Swahili Swedish Thai Turkish Ukrainian Urdu Vietnamese Welsh Yiddish Detect language » English   If you want to use https you should know what a certificate is. Certificates are used to encript the data, but at the same time they are used to identify the host. ELOG is delivered with a self generated certificate. This can be used to encript the data, but no certification authority knows this certificate, so nobody can guaratee that you are connected to the right host. Most browsers will warn you, that nobody did and if you don't care you need to change the security settings of you browser to accept the connection anyway.   The proper way out of this is to buy a certificate from a certification authority. Or to switch off https. (See https://midas.psi.ch/elog/config.html#global SSL option)

we know about certificates, thank you 

The point is that it stops AFTER the point at which I tell the browser to accept the self-signed certificates. I now even got a CACert and the problem remains: FF works, Chrome and IE don't: https://phd-bkp-gw2.ethz.ch:8080/admin/

log says: TCP connection broken

thanks,

-Christian

Christian Herzog wrote:

Andreas Luedeke wrote: Christian Herzog wrote: [...] we're evaluating elog right now at the Physics Department of ETH Zurich and I'm trying to come up with a good config. One of the first steps of course was to enable SSL/https. With http, all tested browsers work fine, but with https at least Google Chrome 16 and IE 9 do not get past the "unknown certificate" warning and I see "TCP connection broken" errors in the log file. Firefox however works fine. Same behavior on Linux, Mac and Windows (given the browser in question is available). elog server is running on Lucid.[...]   Afrikaans Albanian Arabic Armenian Azerbaijani Basque Belarusian Bulgarian Catalan Chinese (Simplified) Chinese (Traditional) Croatian Czech Danish Detect language Dutch English Estonian Filipino Finnish French Galician Georgian German Greek Haitian Creole Hebrew Hindi Hungarian Icelandic Indonesian Irish Italian Japanese Korean Latin Latvian Lithuanian Macedonian Malay Maltese Norwegian Persian Polish Portuguese Romanian Russian Serbian Slovak Slovenian Spanish Swahili Swedish Thai Turkish Ukrainian Urdu Vietnamese Welsh Yiddish ⇄ Afrikaans Albanian Arabic Armenian Azerbaijani Basque Belarusian Bulgarian Catalan Chinese (Simplified) Chinese (Traditional) Croatian Czech Danish Dutch English Estonian Filipino Finnish French Galician Georgian German Greek Haitian Creole Hebrew Hindi Hungarian Icelandic Indonesian Irish Italian Japanese Korean Latin Latvian Lithuanian Macedonian Malay Maltese Norwegian Persian Polish Portuguese Romanian Russian Serbian Slovak Slovenian Spanish Swahili Swedish Thai Turkish Ukrainian Urdu Vietnamese Welsh Yiddish Detect language » English     [...] The proper way out of this is to buy a certificate from a certification authority. Or to switch off https. (See https://midas.psi.ch/elog/config.html#global SSL option) we know about certificates, thank you  The point is that it stops AFTER the point at which I tell the browser to accept the self-signed certificates. I now even got a CACert and the problem remains: FF works, Chrome and IE don't: https://phd-bkp-gw2.ethz.ch:8080/admin/ log says: TCP connection broken [...]

Afrikaans Albanian Arabic Armenian Azerbaijani Basque Belarusian Bulgarian Catalan Chinese (Simplified) Chinese (Traditional) Croatian Czech Danish Detect language Dutch English Estonian Filipino Finnish French Galician Georgian German Greek Haitian Creole Hebrew Hindi Hungarian Icelandic Indonesian Irish Italian Japanese Korean Latin Latvian Lithuanian Macedonian Malay Maltese Norwegian Persian Polish Portuguese Romanian Russian Serbian Slovak Slovenian Spanish Swahili Swedish Thai Turkish Ukrainian Urdu Vietnamese Welsh Yiddish ⇄ Afrikaans Albanian Arabic Armenian Azerbaijani Basque Belarusian Bulgarian Catalan Chinese (Simplified) Chinese (Traditional) Croatian Czech Danish Dutch English Estonian Filipino Finnish French Galician Georgian German Greek Haitian Creole Hebrew Hindi Hungarian Icelandic Indonesian Irish Italian Japanese Korean Latin Latvian Lithuanian Macedonian Malay Maltese Norwegian Persian Polish Portuguese Romanian Russian Serbian Slovak Slovenian Spanish Swahili Swedish Thai Turkish Ukrainian Urdu Vietnamese Welsh Yiddish

Detect language » English

 

Sorry that I was mis-interpreting your question

• first, I would try to change to the standard port 443. Just in case it is related to some firewall, etc. problem.
• second, I would try another operating system than Ubuntu Lucid. It should work of course with Ubuntu, but if it still doesn't work with the other operating system then many things are already ruled out.
• third, I would try to set-up an apache webserver in front of ELOG. We have it here just for safety reasons. ELOG runs then on some special port and apache connects to it with a reverse proxy.