Hello

I was wondering if there is any possibility to let the user decide which columns to show/download in the search results? We have quite a lot of fields and it would help the usefulness of our elog a lot.
(If there is an obvious possibility that I missed I'm sorry).

Thanks a lot!

There is a general display option "List display", but that applies for all users. For the download, you can load the CSV file into a spreadsheet program and then delete some columns.

Stefan

The maximum number or attributes is 100.

Is it possible to increase this?

Thanks!

You would have to change the elogd.c code and recompile. At some point you wlll however get crash of elogd with a stack overflow. If you need more than 100 attributes, it becomes anyhow hard to manage, so I would suggest other ways, like adding iformation to the text body etc.

Best,
Stefan

Dear Stefan,

 Thansk for the super fast response! To keep the stability of the system we will look for a different solution then. 

Best,

Marta

In my case, I had a number of attributes which had a varied prefix.  For example, "progressed" , which could have no prefix, or prefix "I", "To be", "Strongly", "Seriously"... and that was true (the same prefixes, or at least many of them) for a number of attributes.  Splitting them into two groups, the prefixes and the action, allowed me to gain more actual attributes without having to recompile.  Suitable change in the elog config file will also make this easy to follow in how the entries are shown in threaded or full display modes.  In your case suffixes may be better, but I hope you get the point.

Although I have done a (linux) recompile in the past, v2.9 something, 120 attributes seemed not to affect things.

To explain the problem, we have silicon chip designs, which we log with an indentifyier, which is the attribute for easy search, as we want to follow their progress from design thorugh fabrication to testing, involving many people. They are called D_001; D_099...you get it. We have reached the 100, but maybe it is the est just to create an archive after each 100 design and make a new tab/logbook. Any other suggestions are of course welcome. 

Why don't you simply create a single attribute "identifier", which then gets a value D_001, ..., D_xxx. You can still use the D_xxx in full text search.

Stefan

Or what about the "ticket number" feature?  Every new entry  thread (sorry, confusing terminology on my part) would increment the ticket number by one, and there is no limit as far as I am aware.  This is all explained in the elogd configuration documentation.  

As for my suggestion earlier, now I'm at my computer with working elog. I think that the following four lines (three I guess already there but need alteration for this) need to appear in your elogd.conf file.  The first three should also include any other thing you need to display etc.  I've cut this down to the bear bones, and ... means anything else you want to add. 

Attributes = Die, Organisation, ...
List display = Die, Organisation. ...
Thread display = $Die: $Organisation ...
Preset Die = D_#####

Now the first time you run this, it will give D_00001.  You can edit that to D_00100 and it will increment from there.  You may wish to have two types of user, those who can start a new thread, such as yourself, and others who can contribute but not start a new thread / new Die discussion.

Now it may be that the attribute name you gave D_001 etc can be used where I have used "Die" here, which would appear to give a seemless transition. and perhaps without the need of editing the first new thread.

I have tried these as changes to an existing logbook on my system. and they appeared to work fine. but in my case as a single user, I could always change the Die number, a feature I guess you do not want.  I guess there is a way in the config file, but I'm running out of steam for today.  David.

Good morning,

I would like to ask you whether it is feasible to establish a logbook that limits access to entries, enabling each user to view only their own.
Although creating a logbook per user is an apparent solution, it does not meet my requirements.

Thank you in advance.

Leonardo

No, this is not possible with the current version of Elog, so indeed everybody needs their own logbook.

Stefan

Dear Stefan,

thanks to the answer you gave to my colleague. 

Now, attempting to follow your suggestion... If we will create several logbooks, one for each user,

1) there is a way to automatically duplicate all the entries in anoter "global" elog without loosing them and keeping them updated between the global and the individual logbooks? 

2) alternatively how I could activate a search in all these user logbooks (and only in this set of logbooks without searching in the others logbook present in the same file conf)? shall I gnereate a separated elog instance only for this set of logbooks? how to let this search to all option available only to a reduced number of "superusers" that are not "administrators?

thanks

Matteo

Keeping the global and individual logbooks in sync is not possible. So indded my proposal is a cumbersome solution in your case. We do have "restrict edit" which lets users only edit their own entries, but we do not have "restrict view". Maye some thought for a future version of elog.

Stefan

Hello, my sending of emails was working a while back but I have not checked on it in a few months and found out I am getting authentication errors sending to my MTA (mailer). I was using a base64 to encode the pw but now my mailer (gandi.net) rejects it. Has anything changed over the last couple of years with Elogs code that would be affecting this? I just upgraded (Linux) and changed my testing grounds to non-production and the same problem exists. Thing is I CAN send using other programs, but not with Elog. It is impertive I figure this out or have a work around.. but a 'work around' does not seem like a possible  task since all the work (forums and such) will be via my Elog server.

Thanx, John

ELOG has not change in the last years in that respect, but I know that mailer get more and more picky about encryption etc. So you probably have to convince your mailer to accept the pw as it comes from ELOG, or do not require a pw for that specific client.

Stefan

Hi,

I currently testing last ELOG version from git in a docker with LDAP activated (https://hub.docker.com/r/usinagaz/elog-ldap). The goal is to use it on Synology NAS server, associated with local LDAP server.

The reverse proxy is done by embedded DSM nginx, according to FDQN associated to ELOG service (elog.corp.com). In Docker, URL is set to elog.corp.com.

All is good, but when I post any enclosure in any elog post, the elogd exits and docker is automatically restarted. The browser shows an error 405 generated by nginx server.

Do you have any idea of the cause of this problem  ?

Thanks for help.

Laurent

Ok, i reply to myself as i could resolve the problem by changing the alpine Linux image to Debian light.

After debugging, the problem seems to be the compilation option used for alpine packets, which is not fully compatible when running on NAS Intel cpu.

The problem disappeared with Debian light, which should be less "aggressive" for optimization. I think the core is generated during imagemagick lib call (png, jpeg,pdf, ...).

Cheers

Hello,
I like the ELcode feature that lets you easily make an internal link to an attachment in the same post. However, I wasn't able to get this to work in the html editor, even though it's possible to use the ELcode format to link to another post in the logbook. When I type in elog :/1 in the html editor (without the space) and submit (even with an attachment present), it weirdly gets changed and shows up as 61/1 in the submitted elog, without any hyperlink. As far as I know we're using the standard elog code and only modified css parameters. Is there another syntax to link to attachments in html?
Testing it out here: 69699/1  (elog :/1 without the space turned into 69699/1)

You can always insert the full link to the attachment like this one: https://elog.psi.ch/elogs/Forum/231009_104933/SCR14.PNG

But you can also use elog:69699/1 as shown here. Unfortunately you can do that only after the entry has been submitted, so you know the ID number of that entry. Once you have it, edit the entry and put it in.

Stefan

thank you!

Hi,

is there a trick to get "Filtered browsing" working?

If i am on the first entry and i checked the checkbox of one Attribute, the next entry is still the second one and not the next with the same Attribute.

Our elog instance (elogd 3.1.4 built Jan 13 2021, 20:44:20 revision ce2a48e9) has been running for years without any problems.

We have a new user who consistently crashes the elog:

GET /Omicron-STM-XPS/?rsort=Record%20date HTTP/1.1
Host: elog.fhi-berlin.mpg.de:4821
Cache-Control: max-age=0
DNT: 1
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/117.0.0.0 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.7
sec-gpc: 1
Sec-Fetch-Site: same-origin
Sec-Fetch-Mode: navigate
Sec-Fetch-User: ?1
Sec-Fetch-Dest: document
sec-ch-ua: "Google Chrome";v="117", "Not;A=Brand";v="8", "Chromium";v="117"
sec-ch-ua-mobile: ?0
sec-ch-ua-platform: "Linux"
Referer: https://elog.fhi-berlin.mpg.de/elog/isc/Omicron-STM-XPS/
Accept-Encoding: gzip, deflate, br
Accept-Language: el-GR,el;q=0.9,en;q=0.8
Cookie: ufnm=Sotirios Tsatsos; urem=1; elmode=full; elattach=1; sid=CD2B04E2C3F02EA4; googtrans=/en/en; amp_6e403e=aWS6RQd5UjGctj5Ym_cDzA.c2Fsdm9fc290b2thaXRlbkB5YWhvby5jb20=..1hajnscc0.1hajnscc0.0.ac.ac
X-Forwarded-For: 141.14.151.26
X-Forwarded-Host: elog.fhi-berlin.mpg.de
X-Forwarded-Server: elog.fhi-berlin.mpg.de
Connection: Keep-Alive

Received unknown cookie "googtrans"
Received unknown cookie "amp_6e403e"
*** buffer overflow detected ***: terminated
Abort (core dumped)

The server is crached because the author field was accidentally filled with a long string due to an automated (remote) script:

“
Author: The ion getter pump has successfully recovered and appears to be operating steadily once more. Consequently, I proceeded with sputtering to obtain an XPS survey scan of the Au sample.  Initially, the stability of the X-ray function was compromised, leading to multiple interruptions. Subsequently, an unexplained issue arose regarding the collection of counts on the channeltron detector. Additionally, the emission current exhibited fluctuations. Fortunately, it seems that we have addressed and resolved the previous issues.  In the image below, two XPS survey spectra are presented. The spectrum highlighted with a red line corresponds to the AlKa source, which was selected using the AlKa button. Conversely, the spectrum with a black line represents the MgKa source. In both cases, the energy configuration was set to 1486.7 eV. It's worth noting that the 1050 eV peak in both spectra corresponds to the Au4f state, with an energy displacement of 961.7 eV due to X-ray ghost lines caused by O contamination (84+961.7). It has come to my attention that the Mg source appears to have oxidized, a phenomenon we've observed before.  Moreover, it's important to highlight that the difference between the peaks in the low binding energy region is approximately 100 eV, not the expected 233 eV (considering the energy difference between magnesium and aluminum). This observation holds true for both cases where the same energy setting was used. Additionally, the energy of the Au4f peakSotirios Tsatso
“

Instead of just "Sotirios Tsatso". 

So it had nothing to do with the cookies etc.. But when the item created in this way was called up, the system crashed:

[248459.853246] elogd_misc[8407]: segfault at 561725164a4e ip 00007f8210c02854 sp 00007ffdcb92b338 error 4 in libc-2.31.so[7f8210a99000+178000]
[248459.853251] Code: 7f 07 c5 fe 7f 4f 20 c5 fe 7f 54 17 e0 c5 fe 7f 5c 17 c0 c5 f8 77 c3 48 39 f7 0f 87 ab 00 00 00 0f 84 e5 fe ff ff c5 fe 6f 26 <c5> fe 6f 6c 16 e0 c5 fe 6f 74 16 c0 c5 fe 6f 7c 16 a0 c5 7e 6f 44