| ID |
Date |
Icon |
Author |
Author Email |
Category |
OS |
ELOG Version |
Subject |
|
69019
|
Sat Sep 28 09:07:05 2019 |
 | Qisheng Wang | wangqisheng@zjlab.org.cn | Info | Windows | 3.1.1 | Re: Custom input forms implementation | Dear Andreas,
The same problem by using the shiftchecklist and the cfg in Stefan's mail. It report the no password file, even the absolute path wroten in cfg file. The author field also failed to be read, it is shown as "?" in the page . Did there miss some other files?
Any suggestion is welcome. Thank you very much.
Qisheng
| Andreas Luedeke wrote: |
|
You might try to specify an absolute path to the password file in the configuration.
I would need a complete minimal configuration that creates that problem.
| JD wrote: |
|
Hello Stefan,
I created a custom form with the example you provided. When I enter the Data and Submit the Form I get the error message "Datei passwordfile.xml kann nicht geöffnet werden: No such file or directory". Posting stuff works in all other logbooks. Only in the "logbook with the form" there seems to be an error. (or misconfiguration on my side)
sections from my conf. File:
[global]
Password file = passwordfile.xml
(...)
[ShiftCheck]
Comment = Shift Check List
Attributes = Hardware, Raith-Mitarbeiter, Rechnername, Rechnername-alt, Details, SN, AV-Nummer, System, Key, IT-Mitarbeiter, Erledigt_datum, Ausgemustert_datum
Quick filter = Shift, Author
Options Shift = Morning, Evening, Night
Enable attachments = 0
Show text = 0
Custom new form =forms\shiftcheck.html
Custom edit form = forms\shiftcheck.html
Custom display form = forms\shiftcheck.html
List after submit = 1
I tried copying the password file to the forms directory, the logbook directory, the ShiftCheck logbook directory and the elog root folder. I always get the same error. I tried entering the absolute path, there was no difference in the result.
When I disable the password file I am able to post without any problems. Can you help me out?
Jonathan
| Stefan Ritt wrote: |
|
Dear ELOG users,
starting with SVN revision 2328, custom input forms are implemented. This allows application specific formats for check lists etc. In our specific case we had to implement a shift check list, which was quite long. Furthermore the check list should be optimized for an iPad, which we take in the field and record various checks and readings (in our case some gas pressure gauges at the PSI particle accelerator). Since the standard ELOG interface was too inflexible, a completely hand-written form was needed. The form can be activated by the new configuration options Custom New Form, Custom Edit Form and Custom Display Form, one for a new entry, an entry to edit and and entry to display. In our case we used the same form for all three cases. This is how the shift check list looks under the Safari Browser on a PC:
And here is how it looks on the iPad:
Each section can be collapsed and expanded (blue arrows at the left), and various internal checks are made before the check list can be submitted.
Implementing such forms is however more something for the advanced user, since you have to hand-write HTML with CSS and JavaScript code. It can then however be a powerful method for check lists. Please find in the attachments the elogd.cfg configuration for that logbook and the shiftcheck.html source code file. It is a bit complicated since the page is a static page, elogd just serves it from the file. This requires all the dynamic functions to be implemented inside the HTML file with JavaScript. To display an entry for example, the JavaScript loads the raw data with the "?cmd=Download" command and the populates the form fields. The collapsing and expanding is done by using CSS properties. The integrated style sheet was optimized for the rendering on an iPad. Rather large fonts were chosen so that the items can be checked easily with your finger tips. Various parameters are sent between the browser and the elogd program via hidden fields and cookies. So only something for experts! But if you go through the effort and hand-write the form, it can be very handy. Note that you have to upgrade to SVN revision 2328 for the three new options.
|
|
|
|
|
68830
|
Tue Aug 7 10:53:45 2018 |
 | Andreas Luedeke | andreas.luedeke@psi.ch | Info | Linux | elog-3.1.3 | Problem with eloglang.german_UTF8 | I had a problem with restarting ELOG since about a year, and finally I found the culprit. I just want to share it here, to prevent anyone else to make the same mistake,
Apparently the files resources/eloglang.* are rather sensitive to the syntax. But it doesn't tell you: no warning or error message comes up.
The file eloglang.german_UTF8 contains some "missing translations" at the end - and it looks like they produce some problems.
If you don't follow the instructions to create eloglang.german_UTF8 from eloglang.german, but use the file as it is, then the language handling will be corrupted:
some (very few) language strings will point into some void and display garbage strings.
In very rare cases this will even crash "elogd", in all other cases it will confuse your users.
Sometimes ELOG commands like "?Cmd=New" were affected, which makes ELOG unusable.
What made it very hard to debug was the fact that with every restart a different string was affected.
Everything looked fine, and later you see a string in the configuration page is wrong. Restarting fixed that string, but then some other string is gone.
So if you see such a behaviour, check your language file for "unusual syntax".
I haven't checked if the problem is limited to UTF8 - I only saw the problem with the eloglang.german_UTF8 file.
Cheers, Andreas |
|
68816
|
Tue Jun 5 21:37:26 2018 |
| Stefan Ritt | stefan.ritt@psi.ch | Info | Linux | 3.1.1 | Re: text area height | The message height option only works if you select either "ELCode" or "plain" for encoding (this can also be made as default in the config file). For the HTML editor, the size is set internally and I don't have any influenc on it.
Stefan
| Giuseppe Cucinotta wrote: |
|
I tried with Message Height = 100 inside the conifguration of my logbook, but nothing changed as you can see in the first picture...
What I'm looking for is a way, if possible, to start by default with a wider message box, someting like fig2. For our purpose, using wide tables, it would be very useful to have a wider message box in order to have a full look to the message content, and also having it by default without modifying it by hand with the mouse every time we submit something to elog.
Beppe
| Stefan Ritt wrote: |
|
Have you tried
Message height = ...
unit is number of text lines.
Stefan
| Giuseppe Cucinotta wrote: |
|
Hi,
I wonder if it is possible to set a minimum default value for the height of the text box when submitting new entries. If I understood well, by default the text box height automatically resizes in order that all the elements of the page are visible. Actually for our needs having a minimum height of the text box fixed (for instance 500px) is by far more useful of viewing the attachment box (we know it is down scrolling the page :) ). We know it is possible to resize the text box using the mouse but doing this every time one creates a new entry can be annoying. Setting a default minimum size would be more confortable. Is it possible to do this?
Thank you
Beppe
|
|
|
|
|
68815
|
Tue Jun 5 15:06:18 2018 |
| Giuseppe Cucinotta | giuseppe.cucinotta@unifi.it | Info | Linux | 3.1.1 | Re: text area height | I tried with Message Height = 100 inside the conifguration of my logbook, but nothing changed as you can see in the first picture...
What I'm looking for is a way, if possible, to start by default with a wider message box, someting like fig2. For our purpose, using wide tables, it would be very useful to have a wider message box in order to have a full look to the message content, and also having it by default without modifying it by hand with the mouse every time we submit something to elog.
Beppe
| Stefan Ritt wrote: |
|
Have you tried
Message height = ...
unit is number of text lines.
Stefan
| Giuseppe Cucinotta wrote: |
|
Hi,
I wonder if it is possible to set a minimum default value for the height of the text box when submitting new entries. If I understood well, by default the text box height automatically resizes in order that all the elements of the page are visible. Actually for our needs having a minimum height of the text box fixed (for instance 500px) is by far more useful of viewing the attachment box (we know it is down scrolling the page :) ). We know it is possible to resize the text box using the mouse but doing this every time one creates a new entry can be annoying. Setting a default minimum size would be more confortable. Is it possible to do this?
Thank you
Beppe
|
|
|
| Attachment 1: fig1.png
|
|
| Attachment 2: fig2.png
|
|
|
68813
|
Tue Jun 5 10:12:06 2018 |
| Stefan Ritt | stefan.ritt@psi.ch | Info | Linux | 3.1.1 | Re: text area height | Have you tried
Message height = ...
unit is number of text lines.
Stefan
| Giuseppe Cucinotta wrote: |
|
Hi,
I wonder if it is possible to set a minimum default value for the height of the text box when submitting new entries. If I understood well, by default the text box height automatically resizes in order that all the elements of the page are visible. Actually for our needs having a minimum height of the text box fixed (for instance 500px) is by far more useful of viewing the attachment box (we know it is down scrolling the page :) ). We know it is possible to resize the text box using the mouse but doing this every time one creates a new entry can be annoying. Setting a default minimum size would be more confortable. Is it possible to do this?
Thank you
Beppe
|
|
|
68812
|
Fri Jun 1 17:08:48 2018 |
 | Giuseppe Cucinotta | giuseppe.cucinotta@unifi.it | Info | Linux | 3.1.1 | text area height | Hi,
I wonder if it is possible to set a minimum default value for the height of the text box when submitting new entries. If I understood well, by default the text box height automatically resizes in order that all the elements of the page are visible. Actually for our needs having a minimum height of the text box fixed (for instance 500px) is by far more useful of viewing the attachment box (we know it is down scrolling the page :) ). We know it is possible to resize the text box using the mouse but doing this every time one creates a new entry can be annoying. Setting a default minimum size would be more confortable. Is it possible to do this?
Thank you
Beppe |
|
68771
|
Mon Mar 26 16:32:43 2018 |
 | Stefan Ritt | stefan.ritt@psi.ch | Info | All | 3.1.2-0914a6 | New elog setting for large attachments | Most mail delivery systems have a maximum size for attachments. In the past, if an elog attachment was larger than this size, the email server refused to accept this email and no notification is sent. Now one can specify the maximum allowed email attachment size with
Max email attachment size = <n>
where <n> is the number of bytes. If an email attachment is larger than <n>, the attachment is not sent with the email notification, but rather replaced by a link to the elog server for that attachment. By clicking on the link in the email notification, a browser will then open and download the large attachment. For each each elog installation, the admin has to figure out what the maximum attachment size of their SMTP server is, and then put this number into the elogd.cfg setting above. For most installations, the default of 10 MB will just work fine.
Stefan |
|
68639
|
Fri Jul 14 16:58:48 2017 |
| Stefan Ritt | stefan.ritt@psi.ch | Info | Windows | latest | Re: Virus in latest elog? | Hi Daniel,
you're the first one reporting about this virus. We have different virus checkers here at our lab and none of them triggered. So I guess it is a false alarm.
Best,
Stefan
| Daniel Sajdyk wrote: |
|
Hello.
Today I wanted to download latest elog version, and got information from Eset Endpoint Antyvirus, that downloaded file has trojan horse "Generic.GQWFFXB".
It this false positive alarm?
Daniel
|
|
|