I think I know what the answer(s) will be already.. that I will need to address this in JS. I don't want each screen to run/show the same code, other than the ones I want to.  AND I do not want to have to create a custom form for each 'menu option' to achieve this (if possible).

Thanx,

John

In JS, you have access to the browser URL via window.location. So you can write conditional code depending on the actual elog command.

Stefan

Wow thanks again Stefan for your kind and prompt responses!!

John

Something is not right with the elog account activation, I get the email
for "Registration request for ELOG logbook "haicu"", but when I follow the given URL,
I get "Invalid activation code". Account activation requests go to two people,
so maybe the other one already activate this user, in which case I expect a message "user already active".
When I check the elog config, I see that the user indeed is already active. And if I rerun
this URL I still get "Invalid activation code", and this time I definitely expect "user already active".

https://daq00.triumf.ca/elog-haicu/haicu/?cmd=Activate&new_user_name=fujiwara&code=-1904103410&unm=Olchansk

K.O.

we had an elog with only one logbook and one password file,
we added a second logbook with a second password file and everything broke.

specifically, login to the original logbook stopped working,
username and password is accepted, elog.log says "user accepted", but I am presented
with the login dialog again, ad infinitum, and cannot access the elog.

solution seems to be to "delete all cookies" (which is excessive,
google chrome wants to delete all cookies for *.triumf.ca,
which will log me out from everywhere I am logged in and probably
erase/reset web site preferences everywhere).

manually deleting just the elog session cookie also seems to work, though.

this suggests that there is a bug in elog, where on successful login,
it fails to create a new authentication cookie, but reuses an old
cookie, which is no longer valid, for whatever reason (that would
be a different bug, why adding one more logbook invalidates
existing logins?).

K.O.

> Something is not right with the elog account activation...

I did a test:
- register as new user "test", web page says "request for approval sent..." (good)
- check elog config, user "test" is present, "active" set to "no" (good)
- open the "approve/activate" URL, get "Invalid activation code" (should say: "activated successfully!")
- check elog config, user "test" now has "active" set to "yes" (good, "approve/activate" URL worked)
- open the "approve/activate" URL again, again "Invalid activation code" (should say: "already activated!")

additional test:
- from the elog config, user "test", set active to "no", save.
- open the "approve/activate" URL, get "Invalid activation code" (good, this time)
- check elog config, user "test" is still inactive (good)

So it looks like the "approve/activate" URL works correctly - only the first time it is accessed - but
returns wrong message "invalid activation code" instead of "success".

K.O.
 

I'm running  Elog version V3.1.4-ba84827 on Red Hat Linux 7.9. As part of migrating from an older in-house logbook to Elog, I need to upload all the old logbook entries. However, when I attempt to do that with the "elog" command line tool, I'm getting the error "command Submit not  allowed.

I read through a similar report from 2015 (entry #68149), but none of the potential causes seem to be at play here. The logbook is using PAM authentication, and I can log in to the web interface using the same credentials I'm using from the command line. The other case mentioned a dis-allowed encoding format, but my logbook is configured to allow all formats.

This is the command line I'm using:

/usr/local/elog/bin/elog -v -h logbook.aps.anl.gov -p 8081 -l On_Call -x -n 2 -a Date='10/19/2020 01:02' Author="David Wallis" Title='Test Upload' Status='Open' System='On-Call' -u 'wallis' '*****'  "This is a test message"

Update: I tried switching the logbook to no authentication reqiured, and still get the "command Submit not allowed" response.