Hi,

I have an eLog logbook installed on my machine.

If I click on the INSERT TIMESTAMP botton in this post a Timestamp of the kind "Wed Jul 29 23:09:15 2015" is added.

When I do the same (with the same browser) on my logbook, nothing is added. Ideas about what might be causing this?

Regards

Luca

Dear all,

I am trying to have the elog timestamp in UTC time instead of local time using the following config file but without success. Do you know what I am doing wrong?

Thanks

Luca

Theme = default
Comment = XENON1T LogBook 
Attributes = Subject, Author, Category, Type, Status
Locked Attributes = Author
Required Attributes = Category, Type
Preset Author = $long_name
Preset Submission = $utcdate
Options Category = General, CRY - Cryogenics, PUR - Purification, RSX- ReStoX, DST - Distillation Column, MUV - Muon Veto, TPC - Detector, WTR - Water Tank, RAD - Gas Purity, CAL - Calibration, SCT - Slow Control, SOP - Shiftoperation
Options Type = Software Installation, Hardware Installation, Failure/Problem, Configuration, Authorization, Other, Leak Check, xenon operation, Shared Resources, Log, Alarm Tests, Hardware test
Options Status = Info, Open - in progress, Closed - unsolved, Closed - solved, Other
Cell Style Status Info  = background-color:lightblue
Cell Style Status Closed - solved  = background-color:lightgreen
Cell Style Status Open - in progress  = background-color:yellow
Cell Style Status Closed - unsolved  = background-color:red
Extendable Options = Type
Page Title = ELOG - $subject
Reverse sort = 1
Quick filter = Date, Type, Category

Dear Steve,

thanks a lot. Sorry but I am not expert of elog. I "inherited" from a colleague and wanted to see if I can keep it alive but to do it I would need to move to UTC. Should this command affect the "INSERT CURRENT TIME/DATE" button? It does not seem to change.

Best

Luca

Any suggestion?

Hi,

I started re-using after a month an elog on my linux machine and, without any apparent reason since I did not used the machine at all in the last month, every time I try to submit a post I get the following error

"No SMTP host defined in [global] section of configuration file".

The weird thing is that today I created a new logbook using the previous one as a template and, on the new one, I can post without problem (although the configuration is identical).

Do you know what could be causing this?

Thnaks

R

Hi there. I have been testing a set-up of elog behind an Apache reverse proxy using the Webserver auth method. Apache has been configured for LDAPS with Active Directory allowing us to restrict Elogs by AD group, something not able to be done with the LDAP module.

Testing with Elog 3.1.4 (on Windows) and also Elog 3.1.5 (compiled on Ubuntu 20.04) I experience an issue that when the user logs in for the first time using the above they get the self registration box asking for name and email, and then once they hit save they get an error that says: "Error: Command "Config" not allowed".  Once the error is dismissed it never comes back, but its confusing for users who call for help when they first see it.

Is there a way to skip the self registration with the Webserver auth method? and if not is there a reason for the error?

Attached is a copy of the error and an elog config file. Any ideas?

PS. As a side piece the logout options for Webserver needs some enhancement, maybe an option to close the web browser or tab so that it does not retain the logged in cookies.

Is there a limit on the number of conditions that can be simultaneously active in a log?  When I activate more than 10 conditions I start to see side effects with other conditions being deactivated.  I think this is due to the hard-coded array size of 10 for clist in the match_param function in elogd.c.  If so, could this limit be increased?  

Are there other limits on the number of conditions, or the length of condition names?  If I've understood the code right, the _condition string holds a comma-separated list of the active conditions, so the 256 byte length of this will also put some limit on the number of conditions that can be active.

I'll try increasing the list size(s), and will also prepare a simplified config file for you to look at.  Maybe there is a another way to implement what I am trying to achieve?  

In general terms I am trying to give an e-log a "memory" of what has been recorded previously in order to constrain what is permissible to record next.  I do this by starting a log with an initial entry, then alter the config so that users can add records only by duplicating the last record.  The log records the current state of some variables, and allows users to record changes to the state of any of these variables. Conditions are used to constrain the permitted state changes, depending on the current state; conditions are also used, with subst options, to update the current state variables when changes are made.

Specifically, we have "Mate-Demate" logs for connectors to record when connectors are mated and demated.  Previously we just had an attribute for each connector in an assembly with options "Mate", "Demate" and "-" to indicate that either a mate or demate was carried out or that the connector was not touched on this occasion (although others were).  My cunning plan was to ensure that a "Demate" (or no-op) was possible only if the connector is currently mated, and conversely that a "Mate" (or no-op) was possible only if the connector is currently demated.  For each connector (e.g. ConnectorA), there are now two attributes

• "ConnectorA state", to record the current state, and
• "ConnectorA" to record any change.

A new record can be created only by duplicating the last record, thus copying the current state of the connectors, and for each connector the relevant config file entries are like this:

Show Attributes = ConnectorA
Show Attributes Edit = ConnectorA state, ConnectorA
Locked Attributes = ConnectorA state
Preset on duplicate ConnectorA = -
Options ConnectorA state = Mate{1}, Demate{2}
{2} Options ConnectorA = -, Mate{3}
{1} Options ConnectorA = -, Demate{3}
{3} Subst ConnectorA state = $ConnectorA