> Can i check , with the new snap shot , can i disable the capability for the admin
> to delete the logbook and create new logbook
> I tried with the config -
> Allow Delete the logbook = admin
> but cannot , please advise
No, disabling the capability to delete the logbook is not implemented. Usually the
admin user is an experienced user who knows what she/he does. The admin user typically
also was write access directly to the elogd.cfg file, and no flag in the world can
then prevent them from adding/removing logbooks by changing elogd.cf directly.
> And As for the id , can i have the month and the day in the id , what is the
> corresponding field for just the month and day , if there is .
No, but it's on the wishlist. I added your vote there.
> And is there a way to prevent preset value get overwritten when user do a reply
> Example , i preset a field with
> Preset test = "9v"
> so when the user submit , it will have 9v and they may have enter some following
> value. but when a user reply , the test field get reset back to 9v
This is clearly a bug. The 'Preset test = 9v' should not be evaluated on a reply. I
fixed that and updated the CVS and snapshot.
- Stefan |
Hi Stefan
Thanks for your reply
Can i check , with the new snap shot , can i disable the capability for the admin
to delete the logbook and create new logbook
I tried with the config -
Allow Delete the logbook = admin
but cannot , please advise
And As for the id , can i have the month and the day in the id , what is the
corresponding field for just the month and day , if there is .
And is there a way to prevent preset value get overwritten when user do a reply
Example , i preset a field with
Preset test = "9v"
so when the user submit , it will have 9v and they may have enter some following
value. but when a user reply , the test field get reset back to 9v
Thanks
> > I have setup top group in my elog . I will want to restrict the different
> > admin user on the global and the global on top groups .
> > But however i am not able to use the configuration on "admin user" on the
> > global portion to strict admin of top group to access the main global
> > config .
> > Did i configure it wrongly or is there a way?
>
> There was indeed a bug which I fixed. Please obtain the newest snapshot (see
> download page). If an admin user is defined in a top group, it does not gain
> access to the global if the admin of the global is different, like
>
> [gloabl]
> password file = passwd
> admin user = joe
>
> Top group g1 = demo1, demo2
> Top group g2 = demo3, demo4
>
> [global g1]
> admin user = joe
>
> [gloabl g2]
> admin user = jack
>
> [demo1]
> ....
>
> So if user "jack" is logged in to demo3 and therefore g2, he can change the
> [global g2] section, but not the [global] section, since only user "joe" is
> allowed to so do.
>
> > And for email notification , is there a way which i can select who to email
> > it to ? like check box etc.
>
> This is not directly implemented, but one can configure this kind of "manually",
> like
>
> Attributes = ..., Send Email, ...
> ROptions Send Email = joe, jack, ...
>
> Email "Send email" joe = joe@some.domain
> Email "Send email" jack = jack@other.domain
>
> The option "Email <attribute> <value> = <email address>" gets executed when the
> attribute "Send email" has the value "joe" in the first line, so email is sent
> to joe@some.domain. It's a bit cumbersome since one cannot use the email
> addresses from the password file, but better than nothing.
>
> > And is there a way which i can setup the summary page to refresh every
> > 15mins , so that new entry can be shown ?
>
> No, this is not foreseen. One should use email notification for that, which
> tells you immediately (not after 15 mins) when a new entry has been submitted.
>
> > And can i make the message id unique , when i move the messages from one
> > log book to another log book , the messages id change accorddingly based on
> > the number or messages . Anyway for me to make it fixed even i moved to
> > another log book , i need the running number still .
>
> The message id must be unique in a logbook (like in a relational database). If I
> would keep the id when moving entries to another logbook, this could cause a
> conflict. Assume you have two logbooks both with three entries having ID's
> 1,2,3. Now you move ID 3 from the first logbook to the second, but ID 3 exists
> already in the second logbook, so you would have that ID twice, which breaks the
> database structure. What you can do however is user an "numbered" attribute like
>
> Attributes = ..., tag, ...
> Preset tag = ID%d
>
> For each new submission, the attribute "tag" gets a new number, like ID1, ID2
> etc. These attributes are not modified when moving an entry to another logbook,
> but if the target logbook has already an entry with the same tag, you get this
> tag twice. I don't know if that is what you want... |