Is there a way to limit access to an attribute "Reviewed by" to only supervisors?

Thank you for your help

Mike

No.

Is there a way to limit access to an attribute "Reviewed by" to only supervisors?

Thank you for your help

Mike

Hi all :)

I try to setup my first lobgook, and have some problem. 

I want that Author was preset by $long_name, and it can't change its name. That works correct. I also want, when other user click Reply, that he will be author of reply, but Author windows goes emtpy... No Author, or Reply User in that field. Is it correct?

Do you have any suggestions? 

Here is part of config I use:

; preset author and email
Preset Author = $long_name
Preset Author Email = $user_email

; these attributes cannot be changed
Locked Attributes = Author

; options for reply
Subst on reply subject = Re: $Configuration Name
Remove on reply = Author, Author Email
Preset on reply Author = $long_name

Regards

Daniel.

You have "Remove on reply" together with "Preset on reply Author". Since the first is executed later, you first preset the author name, then remove it again. Just discard the "Remove on reply" and you are fine.

Ok. Now it works :) Thank you :) I'm translating Elog into Polish. When I finish, can I send it to you?

Regards Daniel. 

Drag and drop for attachments dosn't work on either Chrome 37.0.2062.94 (64-bit) or FIrefox 31.5.3 (both on Linux). D&D works on the midas.psi.ch demo page.

On my logbooks, the "drop attachements here" area does not have a dashed line border.

I don't see anything in the elogd.conf file that pertains to this feature.

Andreas,

I am running the latest version of the elogd source RPM that I could find - ELOG V3.1.0-2411f95 on Red Hat Enterprise Linux Server release 6.6 (Santiago), with kernel level 2.6.32-504.16.2.el6.x86_64. I can try grabbing the latest source code from Git and try building that. There are a couple other fixes I'd like to apply anyway. Thanks!

Sure, I just wanted to get feedback from you regarding the draft functionality. As it looks now people are happy, so I will do a 3.1.1.

I have multiple elogs running on a server.  Is it possible to set one elog to a different timezone?  For example, I run an elog for a group in Washington state, and another elog for a collaboration group in Germany.  I would like to set each elog to their respective timezone. 

thanks,

Gary

The elog server grabs the local timezone from the underlying OS. Under Linux, you can change the timezone using the TZ environment variable. See here: http://www.cyberciti.biz/faq/howto-linux-set-time-zone-per-user-basis/

If you need different time zones on the same server, you have to create two accounts and run two instances of elogd on these accounts.

Thanks Stefan,  It looks like the group had actually contacted you directly as well (sorry for the redundant work!).  Thanks for the help, the great application and your time.

Still no luck changing the TZ for a single elog service.  I completed the following:

* I added a new user/group - central-tz-user (id 1010)
* changed user TZ to central, su as user and confirmed CDT via 'date'
* changed elogd.cfg usr and grp to central-tz-user
* changed elog directory recursively to central-tz-user ownership
* restarted the elog instance and confirmed via 'ps aux' that 1010 is running elog process
* When I go to elog and add new entry, server time (PDT) is shown. 

Am I missing a step here possibly?

Okay, I missed the obvious...

sudo -u central-tz-user (start elog)

On my linux box, every time I select a thread, or start a new entry etc, I see that one or many cookies are sent.

On a terminal, I get the message

Received unknown cookie "CalciumDisplayParams"

Now I do have a perl script called Calcium, (Calendar viewed through the browser) but it's definately not running now, not in any browser window, and in any case why should an action of ELOG trigger this?  I realise it may be due to an idiocyncratic set up of this box.  But in normal operation, I doubt the user would see these cookies being received.

Cookies are sent from your browser. ELOG has no influence on what the browser sends where. Probably you run your calender at the same machine where ELOG is running, so all the cookies your calender app stores in your browser are sent to ELOG as well. ELOG just complains about something it does not know, but otherwise this message can be simply ignored. Of course you can delete your cookies in your browser, but after the next call to your calendar app they will show up again.

Hi Stefan,

Thanks for the explanation.  I realised it was just an error message of no real import, but it can get irritating at times.

Attributes = Time Start, Time End

Type Time Start = datetime
Type Time End = datetime

Time format = %H:%M:%S

Attributes = Time Start, Time End

Type Time Start = datetime
Type Time End = datetime

Time format Time Start = %H:%M:%S
Time format Time End = %H:%M:%S

Converting from elog 2.9.something to new elog 3.1.0 elogd refuses to start, instructs running elconv in one logbook.

When I do so, elconv converts a existing mhttpd-style elog entries to the new format (the corresponding new-format entries already exist)
and deletes everything else - this is very bad.

So there are 2 bugs:
- elogd should not tell us to run elconv when both old-style and corresponding new-style elog entries exist
- elconv should not delete all existing new-style elog entries.

I confirm that elconv *does* delete all new-style elog entries - with strace, I see it issue "unlink" on every elog entry.

What a disaster!

K.O.

> - elogd should not tell us to run elconv when both old-style and corresponding new-style elog entries exist

I removed that check completely. The old format was used up to 2002, so I expect that all users have upgraded in meantime.

Stefan