Re: elog allows me to create user "blahblah ", posted by Dimitrios Tsirigkas on Fri Feb 3 18:25:32 2006
|
By the way, it is also possible to create a user that doesn't have a password! Shouldn't that be forbidden?
Dimitris |
|
Re: elog allows me to create user "blahblah ", posted by Stefan Ritt on Mon Feb 6 12:54:25 2006
|
| Dimitrios Tsirigkas wrote: | | By the way, it is also possible to create a user that doesn't have a password! Shouldn't that be forbidden? |
Well, some people want that! |
|
Re: elog allows me to create user "blahblah ", posted by Stefan Ritt on Mon Feb 6 12:58:26 2006
|
| Dimitrios Tsirigkas wrote: | | I noticed that when I register a username that contains whitespaces (eg "boing "), elog allows me to create the user of that name and updates the password file accordingly. It doesn't log me in, but it gives me no error message either. I also found that if I repeat the process it adds yet another entry in the password file, by the same name "boing ". Is that a bug or is there something wrong with my configuration? |
Well, I tell you what is wrong: The form says explicitly (name may not contain blanks) and you did not listen 
I can add a simple check if the name contains blanks, but then some people will come up with other strange characters (@#$%), and I'm not sure which of those gives problems. If you test this carefully and tell me which characters to make forbidden, I will happyly add a simple check. |
|
Re: elog allows me to create user "blahblah ", posted by Dimitrios Tsirigkas on Mon Feb 6 16:27:45 2006
|
| Stefan Ritt wrote: |
| Dimitrios Tsirigkas wrote: | | By the way, it is also possible to create a user that doesn't have a password! Shouldn't that be forbidden? |
Well, some people want that! |
Ok, fair enough. But maybe there could be an optional flag in the configuration that disables blank passwords... I wouldn't want some imposter to start entering stuff under the username of another user, so it would be nice if I could have some way of forcing them to have a password, even if it's a one-letter password.
Thanks,
Dimitris |
|
Re: elog allows me to create user "blahblah ", posted by Stefan Ritt on Mon Feb 6 16:53:41 2006
|
| Dimitrios Tsirigkas wrote: | | I wouldn't want some imposter to start entering stuff under the username of another user, so it would be nice if I could have some way of forcing them to have a password, even if it's a one-letter password. |
Ok, I added an empty password check. If too many people will complain, I will make it a flag. |
Re: elog 2.8.0 as daemon crashes when editing selected threaded list, posted by Stefan Ritt on Wed Sep 22 14:21:50 2010 
|
| Mark Bergman wrote: |
|
I recently upgraded elog from 2.7.8 to 2.8.0 (and moved servers, removed unused logbooks, etc.). I'm now having a problem where elog consistently crashes when attempting to edit multiple entries. This is a very common use case, as we use a "status" field, set to "open" or "closed" to track problems. When a problem is resolved, we will go to the "list" display, set it to "threaded", "select" the thread, and then edit it, to change the status field for all posts in the thread to "closed".
Now, as soon as the "edit" button is clicked, elog crashes. This happens on every thread and logbook that I've tried. The elog logfile itself doesn't show anything useful.
However, if eLog is run with "-v" in place of "-D", it does not crash.
Environment:
CentOS 5.4
eLog 2.8.0 built Aug 5 2010, 12:24:11
|
I tried to reproduce your problem with following simple configuration file:
[Bergman]
Attributes = Author, Status
Options Status = open, closed
Preset Author = $long_name
The result was that it worked fine (see attachments). Maybe there is another setting in your configuration file which causes the problem. Can you try the simple configuration and see if it still crashes? |
Re: elog 2.8.0 as daemon crashes when editing selected threaded list, posted by Mark Bergman on Thu Apr 21 21:06:20 2011
|
| Mark Bergman wrote: |
|
I recently upgraded elog from 2.7.8 to 2.8.0 (and moved servers, removed unused logbooks, etc.). I'm now having a problem where elog consistently crashes when attempting to edit multiple entries. This is a very common use case, as we use a "status" field, set to "open" or "closed" to track problems. When a problem is resolved, we will go to the "list" display, set it to "threaded", "select" the thread, and then edit it, to change the status field for all posts in the thread to "closed".
Now, as soon as the "edit" button is clicked, elog crashes. This happens on every thread and logbook that I've tried. The elog logfile itself doesn't show anything useful.
However, if eLog is run with "-v" in place of "-D", it does not crash.
Environment:
CentOS 5.4
eLog 2.8.0 built Aug 5 2010, 12:24:11
|
I'm now running eLog 2.9.0 and seeing the same crashes. However, I've got some more information that may be helpful.
The crash seems to be directly related to the order of replies in the thread. For example, in this thread I am replying to the original entry. The original entry has 2 children (the entries are siblings) and no grandchildren.
In our installation, eLog crashes consistently under the following conditions:
go to the "list" display
set it to "threaded"
"select" a thread that has siblings at any generation of replies
choose "edit"
If the selected thread only has one entry at any generation, eLog does not crash.
Here's a horrible attempt at a display of two message threads. Note that in the first example, there are 2 replies at the same generation (siblings)--both the person who responded and the original submitter replied to the initial submission. After that, all replies were to successive generations.
-------------- Causes eLog to Crash ------------------
! Full Name (submitter) module failure
=> Full Name (submitter) Re: module failure
=> Full Name (replier) Re: module failure
=> Full Name (submitter) Re: Re: module failure
=> Full Name (submitter) Re: Re: Re: module failue
------------------------------------------------------
-------------- No eLog Problem ------------------
! Full Name (submitter) Labwide failure of mcc
=> Full Name (replier) Re: Labwide failure of mcc
=> Full Name (submitter) Re: Re: Labwide failure of mcc
=> Full Name (replier) Re: Re: Re: Labwide failure of mcc
------------------------------------------------------
|
|
Re: elog 2.8.0 as daemon crashes when editing selected threaded list, posted by Ryan on Sun May 8 22:33:15 2011
|
| Mark Bergman wrote: |
|
| Mark Bergman wrote: |
|
I recently upgraded elog from 2.7.8 to 2.8.0 (and moved servers, removed unused logbooks, etc.). I'm now having a problem where elog consistently crashes when attempting to edit multiple entries. This is a very common use case, as we use a "status" field, set to "open" or "closed" to track problems. When a problem is resolved, we will go to the "list" display, set it to "threaded", "select" the thread, and then edit it, to change the status field for all posts in the thread to "closed".
Now, as soon as the "edit" button is clicked, elog crashes. This happens on every thread and logbook that I've tried. The elog logfile itself doesn't show anything useful.
However, if eLog is run with "-v" in place of "-D", it does not crash.
Environment:
CentOS 5.4
eLog 2.8.0 built Aug 5 2010, 12:24:11
|
I'm now running eLog 2.9.0 and seeing the same crashes. However, I've got some more information that may be helpful.
The crash seems to be directly related to the order of replies in the thread. For example, in this thread I am replying to the original entry. The original entry has 2 children (the entries are siblings) and no grandchildren.
In our installation, eLog crashes consistently under the following conditions:
go to the "list" display
set it to "threaded"
"select" a thread that has siblings at any generation of replies
choose "edit"
If the selected thread only has one entry at any generation, eLog does not crash.
Here's a horrible attempt at a display of two message threads. Note that in the first example, there are 2 replies at the same generation (siblings)--both the person who responded and the original submitter replied to the initial submission. After that, all replies were to successive generations.
-------------- Causes eLog to Crash ------------------
! Full Name (submitter) module failure
=> Full Name (submitter) Re: module failure
=> Full Name (replier) Re: module failure
=> Full Name (submitter) Re: Re: module failure
&nb sp; => Full Name (submitter) Re: Re: Re: module failue
------------------------------------------------------
-------------- No eLog Problem ------------------
! Full Name (submitter) Labwide failure of mcc
=> Full Name (replier) Re: Labwide failure of mcc
=> Full Name (submitter) Re: Re: Labwide failure of mcc
&nb sp; => Full Name (replier) Re: Re: Re: Labwide failure of mcc
------------------------------------------------------
|
I am also experiencing the same exact problem as explained above. It only seems to happen when a part of the title has changed. I will include my config for an example. Make a few entries, then change the "Customer" paramater. Then try and edit an entry in the thread.
Enable attachments = 1
Attributes = Employee, Customer, XXX-ID, XXXX Number, SCD, Type, Status, Folder Created, XXXX Received, Equipment Installed, XXX Carrier Up, Customer Carrier Up, QA Completed
Thread display = $Customer - $SLR-ID - $Type - $Status - SCD: $SCD - XXXX: $XXXX Number
Propagate attributes = Status
Locked Attributes = Employee
Options Type = Activation, Termination, Change
Options Folder Created = Yes, No, N/A
Options XXXX Received = Yes, No, N/A
Options Equipment Installed = Yes, No, N/A
Options XXX Carrier Up = Yes, No, N/A
Options Customer Carrier Up = Yes, No, N/A
Options QA Completed = Yes, No
Entries per page = 100
Preset Text = $short_name @ $utcdate -
Append on reply = $short_name @ $utcdate -
Locked Attributes = Employee
Preset Employee = $long_name
Options Status = Open, Closed
Quick Filter = Status, Type
Type SCD = datetime
Summary lines = 0
Enable Attachments = 0
Suppress default = 2
Entries per page = 10
Suppress Email to users = 1
Display mode = threaded
Collapse to last = 1
Expand default = 0
Subst on reply Employee = $long_name
Faulting application elogd.exe, version 0.0.0.0, faulting module elogd.exe, version 0.0.0.0, fault address 0x000646c7. |
|