Demo Discussion
Forum Config Examples Contributions Vulnerabilities
  Discussion forum about ELOG, Page 352 of 807  Not logged in ELOG logo
New entries since:Thu Jan 1 01:00:00 1970
ID Date Icon Author Author Email Category OS ELOG Versiondown Subject
  67436   Wed Feb 13 16:56:40 2013 Reply Hal Proctorhproctor2@gmail.comQuestionWindows2.9.1Re: Locking a Thread

Stefan Ritt wrote:

Hal Proctor wrote:

How can I set up the admins or manager group with the ability to Lock a Thread?  I don't wish to keep two log books.

With

allow <command> = <user list>

deny <command> = <user list>

you can prevent certain users to use certain commands (like delete a message). If you only allow admins to issue the "edit" command, that would in principle do it, but then normal users cannot edit their entries any more. Unfortunately this command cannot be restricted to certain attributes, like the thread "status". So I guess what you want is not exactly possible with the current implementation. 

 Thanks for the reply.  I was looking for a way to stop replies to a runaway thread.  Was wondering why the elog system has a "Locked by" attribute, but no way to set it.

  67437   Wed Feb 13 16:59:06 2013 Reply Stefan Rittstefan.ritt@psi.chQuestionWindows2.9.1Re: Locking a Thread

Hal Proctor wrote:

Stefan Ritt wrote:

Hal Proctor wrote:

How can I set up the admins or manager group with the ability to Lock a Thread?  I don't wish to keep two log books.

With

allow <command> = <user list>

deny <command> = <user list>

you can prevent certain users to use certain commands (like delete a message). If you only allow admins to issue the "edit" command, that would in principle do it, but then normal users cannot edit their entries any more. Unfortunately this command cannot be restricted to certain attributes, like the thread "status". So I guess what you want is not exactly possible with the current implementation. 

 Thanks for the reply.  I was looking for a way to stop replies to a runaway thread.  Was wondering why the elog system has a "Locked by" attribute, but no way to set it.

That's a different meaning. The "Locked by" flag gets set when one user edits an entry. During the editing the entry gets "locked", which means that no one else can change it during that time. This should prevent one person to overwrite the edits of another if they are editing the same entry at the same time. Your "locking" means the locking of threads, which elog doe not "understand", it's just your definition of an attribute in your logbook. 

  67413   Mon Jan 7 01:45:10 2013 Question Miles Fidelmanmfidelman@meetinghouse.netQuestionLinux2.9.0-2435trouble ticket systems w/ elog?

Updating my toolbox.  Starting to use elog as, well, a logbook.  Kind of liking the short, sweet, to the point capabilities.

Which leads me to wonder if anybody has opinions on trouble ticket systems that work well with elog?

Thanks!

Miles Fidelman

 

  67419   Wed Jan 9 11:19:50 2013 Reply David PilgramDavid.Pilgram@epost.org.ukQuestionLinux2.9.0-2435Re: trouble ticket systems w/ elog?

Miles Fidelman wrote:

Updating my toolbox.  Starting to use elog as, well, a logbook.  Kind of liking the short, sweet, to the point capabilities.

Which leads me to wonder if anybody has opinions on trouble ticket systems that work well with elog?

Thanks!

Miles Fidelman

 

 I use elog's built-in ticketing system, and use the auto-generated ticket number to cross-reference with other matters/documents/files.  Much of the documentation for tickets is rather buried away under Subst <attribute> = <string>.

I've not found a way to link from an entry to a set of entries in another thread by their ticket number, particularly across more than one logbook.  [This is possible via their elog entry number, and which logbook it is in].  The former would be usefil to cross-reference an incident which you identify external to the elog system - "Oh, it's another one like [Ticket no] NOV12-001" possibily easier than "Oh it's another one like elog:archive12/67142 ".  Oh, the last bit should be highlighed as a (non-existant) link here, to show my point, nice of the ticket could be as well.

On the plus side, you can arrange the ticket number to show up in the thread display, quick search by ticket number, run different ticket colours (as it were) in different logbooks (i.e. different prefixes).  Just ensure you don't archive the latest entry, as that can lead to duplication of ticket numbers.

 

  67420   Wed Jan 9 18:20:41 2013 Reply Miles Fidelmanmfidelman@meetinghouse.netQuestionLinux2.9.0-2435Re: trouble ticket systems w/ elog?

David Pilgram wrote:

Miles Fidelman wrote:

Updating my toolbox.  Starting to use elog as, well, a logbook.  Kind of liking the short, sweet, to the point capabilities.

Which leads me to wonder if anybody has opinions on trouble ticket systems that work well with elog?

Thanks!

Miles Fidelman

 

 I use elog's built-in ticketing system, and use the auto-generated ticket number to cross-reference with other matters/documents/files.  Much of the documentation for tickets is rather buried away under Subst <attribute> = <string>.

I've not found a way to link from an entry to a set of entries in another thread by their ticket number, particularly across more than one logbook.  [This is possible via their elog entry number, and which logbook it is in].  The former would be usefil to cross-reference an incident which you identify external to the elog system - "Oh, it's another one like [Ticket no] NOV12-001" possibily easier than "Oh it's another one like elog:archive12/67142 ".  Oh, the last bit should be highlighed as a (non-existant) link here, to show my point, nice of the ticket could be as well.

On the plus side, you can arrange the ticket number to show up in the thread display, quick search by ticket number, run different ticket colours (as it were) in different logbooks (i.e. different prefixes).  Just ensure you don't archive the latest entry, as that can lead to duplication of ticket numbers.

 

 By "ticket number" are you referring to the Message ID, or is there some additional trouble ticket functionality buried away?  And... can you point me to the documentation that's "buried away under Subst <attribute> = <string>?  Thanks!

  67421   Wed Jan 9 21:07:53 2013 Reply David PilgramDavid.Pilgram@epost.org.ukQuestionLinux2.9.0-2435Re: trouble ticket systems w/ elog?

Miles Fidelman wrote:

David Pilgram wrote:

Miles Fidelman wrote:

Updating my toolbox.  Starting to use elog as, well, a logbook.  Kind of liking the short, sweet, to the point capabilities.

Which leads me to wonder if anybody has opinions on trouble ticket systems that work well with elog?

Thanks!

Miles Fidelman

 

 I use elog's built-in ticketing system, and use the auto-generated ticket number to cross-reference with other matters/documents/files.  Much of the documentation for tickets is rather buried away under Subst <attribute> = <string>.

I've not found a way to link from an entry to a set of entries in another thread by their ticket number, particularly across more than one logbook.  [This is possible via their elog entry number, and which logbook it is in].  The former would be usefil to cross-reference an incident which you identify external to the elog system - "Oh, it's another one like [Ticket no] NOV12-001" possibily easier than "Oh it's another one like elog:archive12/67142 ".  Oh, the last bit should be highlighed as a (non-existant) link here, to show my point, nice of the ticket could be as well.

On the plus side, you can arrange the ticket number to show up in the thread display, quick search by ticket number, run different ticket colours (as it were) in different logbooks (i.e. different prefixes).  Just ensure you don't archive the latest entry, as that can lead to duplication of ticket numbers.

 

 By "ticket number" are you referring to the Message ID, or is there some additional trouble ticket functionality buried away?  And... can you point me to the documentation that's "buried away under Subst <attribute> = <string>?  Thanks!

Message ID is the internal numbering of each entry.  It is the number that is used internally for generating the threads, and which you can reference with the elog:[message ID] code within an entry to cross reference the entry with that message ID.

"Ticket" is the name of an attribute.  You define the attribute "Ticket", and can preload the attribute with the format  you require(*).  In the following extract of an elog.cfg file are the relivent lines to generate tickets, show the ticket number in the thread display, search for a particular ticket, and allow it to be edited when writing an entry - there are reasons.  The attribute "Organisation" here is an example of another attribute you would enter with the initial entry, of course there will be others specific to your requirements.

Attributes = Ticket, Organisation, ...

Preset ticket = T#####

Thread display = $Ticket: $Organisation, ...

Quick filter = Ticket, ID

 

When you start an new entry, the Ticket attribute is prepopulated with a number.  The first time will be T00001, subsequently it will be one higher than the currently existing highest ticket number in the logbook.

Why might you edit the ticket number?  You may wish to go back and edit an old (complete) entry's ticket number so it has some obvious name - perhaps the solution of what proves to be a stock problem, that has become known by a pet phrase, so it can be found by searching for that phrase in the quick fillter "Ticket".  That is a more advanced use of the ticket system.

 (*) Further on the format of the ticket is in the documentation under Subst <attribute> = <string>

Sorry for multiple edits, why cannot I cross-reference an entry in this forum as I can in my local logbook?

 

  67422   Wed Jan 9 22:28:20 2013 Reply Miles Fidelmanmfidelman@meetinghouse.netQuestionLinux2.9.0-2435Re: trouble ticket systems w/ elog?

David Pilgram wrote:

Miles Fidelman wrote:

David Pilgram wrote:

Miles Fidelman wrote:

Updating my toolbox.  Starting to use elog as, well, a logbook.  Kind of liking the short, sweet, to the point capabilities.

Which leads me to wonder if anybody has opinions on trouble ticket systems that work well with elog?

Thanks!

Miles Fidelman

 

 I use elog's built-in ticketing system, and use the auto-generated ticket number to cross-reference with other matters/documents/files.  Much of the documentation for tickets is rather buried away under Subst <attribute> = <string>.

I've not found a way to link from an entry to a set of entries in another thread by their ticket number, particularly across more than one logbook.  [This is possible via their elog entry number, and which logbook it is in].  The former would be usefil to cross-reference an incident which you identify external to the elog system - "Oh, it's another one like [Ticket no] NOV12-001" possibily easier than "Oh it's another one like elog:archive12/67142 ".  Oh, the last bit should be highlighed as a (non-existant) link here, to show my point, nice of the ticket could be as well.

On the plus side, you can arrange the ticket number to show up in the thread display, quick search by ticket number, run different ticket colours (as it were) in different logbooks (i.e. different prefixes).  Just ensure you don't archive the latest entry, as that can lead to duplication of ticket numbers.

 

 By "ticket number" are you referring to the Message ID, or is there some additional trouble ticket functionality buried away?  And... can you point me to the documentation that's "buried away under Subst <attribute> = <string>?  Thanks!

Message ID is the internal numbering of each entry.  It is the number that is used internally for generating the threads, and which you can reference with the elog:[message ID] code within an entry to cross reference the entry with that message ID.

"Ticket" is the name of an attribute.  You define the attribute "Ticket", and can preload the attribute with the format  you require(*).  In the following extract of an elog.cfg file are the relivent lines to generate tickets, show the ticket number in the thread display, search for a particular ticket, and allow it to be edited when writing an entry - there are reasons.  The attribute "Organisation" here is an example of another attribute you would enter with the initial entry, of course there will be others specific to your requirements.

Attributes = Ticket, Organisation, ...

Preset ticket = T#####

Thread display = $Ticket: $Organisation, ...

Quick filter = Ticket, ID

 

When you start an new entry, the Ticket attribute is prepopulated with a number.  The first time will be T00001, subsequently it will be one higher than the currently existing highest ticket number in the logbook.

Why might you edit the ticket number?  You may wish to go back and edit an old (complete) entry's ticket number so it has some obvious name - perhaps the solution of what proves to be a stock problem, that has become known by a pet phrase, so it can be found by searching for that phrase in the quick fillter "Ticket".  That is a more advanced use of the ticket system.

 (*) Further on the format of the ticket is in the documentation under Subst <attribute> = <string>

Sorry for multiple edits, why cannot I cross-reference an entry in this forum as I can in my local logbook?

 

Thanks for the additional details!

 

  67386   Mon Nov 26 15:57:49 2012 Warning Andreas Luedekeandreas.luedeke@psi.chBug reportLinux2.9.0-2427ELOG crash related to Kerberos, SSL and Login users
I'm using Kerberos and SSL and experience problems with individual setting of "Login user =" for different logbooks.
Sometimes (not every time, but most times) the server crashes under the following condition:
When I login at one logbook and then change to a logbook, that has a restricted "Login user" list with my login
name not in it. It created the following GDB output:

Program received signal SIGSEGV, Segmentation fault.
show_elog_list (lbs=0x916b768, past_n=0, last_n=0, page_n=0, default_page=1, info=0x0) at src/elogd.c:19793
19793         message_id = msg_list[index].lbs->el_index[msg_list[index].index].message_id;

Expected behaviour would be to show me the login page with the error message:
"you don't have access to this logbook".
This message is never shown for the attached configuration file.
If I remove the "Guest" commands for logbook "TestB" then elogd behaves properly.

For the moment I've just disabled "Login user" settings.

Regards
Andreas
Attachment 1: elogd.cfg
[global]
SSL = 1
Port = 443
Authentication = Kerberos, File
Password file = passwd.txt
Login expiration = 8
Admin user = luedeke
Allow password change = 0
Self register = 0
Logfile = elog.log
Group Operation = TestA, TestB
URL = https://localhost

[TestA]
Guest Menu commands = List, New, Find, Login, Help
Guest List Menu commands =  New, Find, Login, Help
Comment = Test Log
Attributes      = Autor
Preset Autor = $long_name
Locked Attributes = Author

[TestB]
Guest Menu commands = List, Find, Login, Help
Guest List Menu commands =  Find, Login, Help
Comment = TestB
Attributes = Author
Admin user = flechsig
Login user = flechsig, spielmann
Preset Author = $long_name
Locked Attributes = Author
ELOG V3.1.5-3fb85fa6