Hello, I read carefully the manual, but I didn't find a way to hide the logbooks in the logbook bar and in the initial logbook selection for which the user does not have the access. So, if a user1 does not have the access to a specific logbook, user1 is not able to see that logbook in the bar and neither in the initial logbook selection. How can I do this without using the top groups?

Hi Stefano,

Kind Regards, Andreas

Hi Andreas,

many thanks for your answer. I partially agree with you, because sometimes "for privacy" of my working group I don't want that other users (external users) know the existance of the other logbooks.

Do you think that will be implemented in future?

Best regards, Stefano

Well, Stefan would need to answer that. But if you are good with C-programming, you might implement it yourself?

There is a way to implement it; but it makes your installation a lot more complicated: you can have two ELOG servers. The first has all logbooks but requires authentification to read any. The second has only the public logbooks, and they are mirrored from the first.

Hi Stefano,

that's what top groups were made for. So make a top group for yourself, and nobody will be able to see them without having the proper URL. Hiding logbooks from the logbook selection page is not possible since when people bring up that page, they are not yet logged in, so elog does not know who is accessing the page (fortunatley no face recognition yet!). So if elog doe not know who looks at that page, logobook which a certain use has no access to cannot be hidden becuase the user is not known at that point.

Best regards,

Stefan

Hello!  The CDMS collaboration is using e-Log as one of it's issue tracking systems.  In the last few months, I have noticed a problem when either creating or editing entries from my usual Safari browser (currently 11.1 on MacOSX 10.13.4):  The [Submit] button triggers a spinning beach ball, with no connection to our e-Log server, and after several minutes, Safari complains the the page had to be reloaded, discarding all of my edits, uploads, whatever.  This used to be occasional, but in the past month it has become routine, such that the only way I can edit or create entries is by launching a different browser entirely (Firefox), just for e-Log editing.

Now, I am also seeing the same problems with Firefox, but at the "occasional" level.  The difference is that Firefox produces some diagnostic information, which is why I'm posting here.  When the browser hangs, after a short while Firefox produces a "Warning: unresponsive script" drop-down box:

Warning: unresponsive script

A script on this page may be busy, or it may have stopped responding.  You can stop the script now, open the script in the debugger, or let the script continue.

Script: http://titus.stanford.edu/cdms…/SuperSim/681?cmd=Edit&steal=1:30

[] Don't ask me again

[Debug script]                       [Stop script]     [Continue]

If I use the [Debug script] button, the call stack shows "onclick 681:1" -> "chkform 681:30", and the line-by-line traceback shows the chkform function:

16   var in_asend = false;
17
18   function chkform()
19   {
20     if (last_key == 13) {
21       var ret = confirm('Really submit this entry?');
22       if (!ret) {
23         last_key = 0;
24         return false;
25       }
26     }
27
28     if (autoSaveTimer != null)
29       clearTimeout(autoSaveTimer);
30     while (in_asend);               <=== This is the stuck line
31     submitted = true;
32     return true;
33   }

I presume that in_asend is supposed to get changed from false to true asynchronously, by some other parallel communication with the server. But that doesn't seem to be happening.

Does this look like an issue with the e-Log distribution? Or is there a configuration issue with our e-Log server which we could improve?

I dont' have a solution, but I just wanted to bring more attention to your post. I too am having the same issue with the ELOG system and the Safari browser. I have noticed that ELOG is most stabel and function on the client end from the IE browser. A few weeks ago I also had to switch from using ELOG on the client end from Safari to Firefox.

I'm not 100% sure, but I believe it should work without the 

while (in_asend);

So can you please remove that line (it's in src/elogd.c) and recompile elogd and test it?

Stefan