Re: reply option in elog client not working, posted by Gerald Ebberink on Thu Sep 7 08:01:37 2006 
|
I have made patch witch solves the problem partialy.
If there are not no attachments this patch works.... (But since I have attachments I'll have to dig in deeper in the code.
Attached you will find the diff. |
|
Re: reply option in elog client not working, posted by Gerald Ebberink on Thu Sep 7 17:17:17 2006
|
| Gerald Ebberink wrote: | I have made patch witch solves the problem partialy.
If there are not no attachments this patch works.... (But since I have attachments I'll have to dig in deeper in the code.
Attached you will find the diff. |
Now I am digging deeper, and I have a question:
In the function retrive_elog near line 427 a start is made with putting the attributes in an array.
As far as I can see there is no exception for the Attachment attribute. Where this attribute can be very large (e.g. many files attached) and overrun to the boundary variable (in the function submit_elog function). At least that is where I find end of my attachment string.
Could Mr. Ritt please shine some light on this, becouse I |
|
Re: Auto-refresh ELog display, posted by Stefan Ritt on Mon Sep 11 16:32:52 2006
|
| Alan Stone wrote: | We have multiple LCDs at a console, and usually one is dedicated to displaying a browser
with the local ELog. Meanwhile, others are making entries from another machine. If
no one clicks on refresh, the ELog display becomes stale. Is there a method to have
the ELog reload every X minutes?
Thanks, Alan |
The JavaScript is one possibility as Steve mentioned correctly. Another possibility is to use the RSS feed capability of ELOG. Use any RSS reader, and it will notify you immediately if there is a new entry in ELOG. Have a look at http://midas.psi.ch/elog/config.html and search for RSS on how to configure this. |
|
Re: Unsubscribe from logbooks, posted by Stefan Ritt on Mon Sep 11 17:25:54 2006
|
| Chris Warner wrote: | | Is there a way for user to unsubscribe from a logbook? Can a user delete their own account? |
Yes. Yes.
Just click on "Config", and you will see a page where you can unsubscribe from each logbook and a button to remove your account. |
|
Re: Why are Preset fields blanked out?, posted by Stefan Ritt on Mon Sep 18 15:21:56 2006
|
| Steve Jones wrote: | The snippet of code below sets an attribute to a date depending on the selection. Problem is, if attribute ApprovedDate was previously set, selecting any other value for CRStatus will blank out ApprovedDate (the same occurs for CompletedDate). Why would this be occurring when the conditionals are mutually exclusive?
##################################################
# Define CRState
#
Options CRState = PENDING{a}, APPROVED{b}, HOLD{a}, REJECTED{a}, COMPLETED{c}
{a}
{b} Preset ApprovedDate = $date
{c} Preset CompletedDate = $date
|
I don't understand your problem. If I use following config file:
[demo]
Theme = default
Attributes = Author, CRState, ApprovedDate, CompletedDate
Options CRState = PENDING{a}, APPROVED{b}, HOLD{a}, REJECTED{a}, COMPLETED{c}
{a}
{b} Preset ApprovedDate = $date
{c} Preset CompletedDate = $date
and make an entry, then edit it, selecting approved, then submit, then edit again, then select completed, then I get following:
which looks ok to me (the previous ApprovedDate does not get blanked out). Can you reproduce that behaviour? |
|
Re: Re: Why are Preset fields blanked out?, posted by Steve Jones on Mon Sep 18 18:19:44 2006
|
| Stefan Ritt wrote: |
| Steve Jones wrote: | The snippet of code below sets an attribute to a date depending on the selection. Problem is, if attribute ApprovedDate was previously set, selecting any other value for CRStatus will blank out ApprovedDate (the same occurs for CompletedDate). Why would this be occurring when the conditionals are mutually exclusive?
##################################################
# Define CRState
#
Options CRState = PENDING{a}, APPROVED{b}, HOLD{a}, REJECTED{a}, COMPLETED{c}
{a}
{b} Preset ApprovedDate = $date
{c} Preset CompletedDate = $date
|
I don't understand your problem. If I use following config file:
[demo]
Theme = default
Attributes = Author, CRState, ApprovedDate, CompletedDate
Options CRState = PENDING{a}, APPROVED{b}, HOLD{a}, REJECTED{a}, COMPLETED{c}
{a}
{b} Preset ApprovedDate = $date
{c} Preset CompletedDate = $date
and make an entry, then edit it, selecting approved, then submit, then edit again, then select completed, then I get following:
which looks ok to me (the previous ApprovedDate does not get blanked out). Can you reproduce that behaviour? |
| Quote: |
I think I found it. Try this:
Locked Attributes = ApprovedDate, CompletedDate
##################################################
# Define CRState
#
Options CRState = PENDING{a}, APPROVED{b}, HOLD{a}, REJECTED{a}, COMPLETED{c}
{a}
{b} Preset ApprovedDate = $date
{c} Preset CompletedDate = $date
In my config when I remove the two attributes from "LOCKED ATTRIBUTES" the fields do not get blanked out.
|
|
|
Re: "Supress Email Notification" checkbox, posted by Steve Jones on Mon Sep 18 18:56:19 2006
|
| Steve Jones wrote: | | Is there a way to allow email notification but have the "Suppress Email Notification" checked by default? We had complaints about the enormous amount of email so I turned off email notification for edits/replys, but there are times that I would like to allow email to be sent out -- this would imply allowing email by unchecking the "Suppress" box. |
What I think would be needed is:
Suppress Email on edit = 0|1|2
^
Where a '2' denotes that the "Suppress Email Notification" shows up but *checked* |
|
Re: SVN1714 will not run in 'daemon" mode on Solaris8, posted by Steve Jones on Mon Sep 18 22:09:23 2006
|
| Steve Jones wrote: | | On Solaris, SVN1714 will not go into daemon mode. Running the compiled version under TRUSS (which provides a dump of every system call) and shows precisely where elog is failing. I have attached two TRUSS outputs: one where it errors out and the other where it runs but "interactively". Both runs are as root, simply one with and one without the "-D" |
| Quote: |
As a followon, when I do run SVN1714 as a detached process but started as ROOT I get the following console messages:
Cannot restore original GID/UID.
Cannot restore original GID/UID.
Cannot restore original GID/UID.
Cannot restore original GID/UID.
Cannot restore original GID/UID.
Cannot restore original GID/UID.
Cannot restore original GID/UID.
I do not get these when I run the app as me - which is a non-UID 0 account. Perhaps this is an artifact of the "-x" option?
|
|
|