If they have admin rights, the add user button cannot be removed as far as I know.

But even if they can add a user, they only have ability to add a user to the single logbook they are an admin on so they wouldn't be able to add users to other peoples logbooks.

Not sure it helps but that's about all I can really speak to.

When ROptions items contain the same substring and this substring is also an ROptions item (ex: notdone, 
done), the value of the entry could change in the edit page. 
It depends on the item order in the config file. 

If Options is used (instead of ROptions), it works as expected.

Is it a bug?


Examples : 

#Insert "notdone" as new entry. When you try to edit the entry, the displayed value is "done".

[test_bad]
Attributes = Author, Category
ROptions Category = notdone, done

#No problem if you change the item order 

[test_good]
Attributes = Author, Category
ROptions Category = done, notdone

Hello.

Please look at the entry 66525 of this forum (just 5 thread before this one):

 ->  chain.crt, posted by Gerhard Schneider on Thu Sep 3 21:55:52 2009         (66525)
  |->    Re: chain.crt, posted by Stefan Ritt on Fri Sep 4 08:33:16 2009       (66526)
  |->    Re: chain.crt, posted by Gerhard Schneider on Wed Oct 7 07:56:52 2009 (66556)

When you collapse the thread, it is collapsed to the 66526 instead of the 66556 (more recent)

  +      Re: chain.crt, posted by Stefan Ritt on Fri Sep 4 08:33:16 2009  

I guess it is because both 66526 and 66556 replies to the first entry. 
I have the same problem with Elog v2.7.7-2246 and Windows. 

In general, it seems to work well only if you always reply to the last entry of a thread.

  Thank you.


b.t.w. : is there any tip to always force reply to the last entry of a thread?

Hello,
   I feel that the filter result could be confusing and unexpected when "COLLAPSE TO LAST" is enabled: you 
filter the first entry but you show the last one. What is filtered doesn't correspond with what is shown (look 
the attached example). 

I suggest to implement an option to let the user decide which entry (first or last) should be retrieved for 
filtering (a tentative patch is attached).

Thank you 

    Gabriele

P.S. A similar behaviour occurs when you sort the logbook: it could appear as not sorted because you sort the 
first entry but the last one is shown.

Hello,
   I gave it a try using the svn version n. 2283 (12 Jan 2010).  The threaded display can be collapsed only if you don't 
apply any sorting. In the latter case, if you sort in some way ( with "Sort Attributes =" or "sort=" in the url), the 
thread cannot be collapsed anymore.

Also if I apply any filter from the quick filter bar, I cannot collapse the thread anymore (also without sorting). 

As example, these are the numbers of entries I obtain with my logbook :

  http://localhost:8080/mylogbook/?mode=threaded&expand=0     => 75 entries (OK)
  http://localhost:8080/mylogbook/?mode=threaded&expand=0&sort=EventID  =>  445 entries  (WRONG it should collapsed)
  http://localhost:8080/mylogbook/?mode=threaded&expand=0&Interaction=nuCC   => 335 entries 

However (considering the bug fixed for the collapsed thread display), breaking the thread is not a confortable solution. 
I choose to show the logbook in the threaded mode, because I'm interested in grouping the entries in threads. 
In my opinion, this feature is good (and it is my favourite) and should be preserved despite any sorting or filtering. 
This is why I suggest to ask to the user which entries (first or last) better applies for sorting and filtering. 

Ciao

   Gabriele


> You are absolutely right. When doing filtering, entries shown or not shown have not much to do with the filter. 
> Rather than messing around with first and last entries, I decided to break apart threads completely when doing 
> filtering, so the entries are treated as individual entries, just like what you do when filtering in summary mode. 
> This gives then consistent filtering results. The modification is done in revision 2282.

Hello,

  I gave it a try. See: https://midas.psi.ch/elogs/Forum/66690

Gabriele

Hello, This is coming up as a high vulnerability in our scans. Are there plans to update the rpm for this fix? If so is there an ETA? Any update would be much appreciated. Currently running elog-3.1.4-2 

Thank you for your work. Works like a charm!