| ID |
Date |
Icon |
Author |
Author Email |
Category |
OS |
ELOG Version |
Subject |
|
68607
|
Thu Apr 20 13:48:43 2017 |
 | K | p1454477@mvrht.com | Question | Linux | 2.9.2 | Re: Full anonymous access | OK, i will try that. Thanks.
| Stefan Ritt wrote: |
|
Version 2.9.2 is hopelessly outdated. Please upgrade to the current version on bitbucket. You also might have to delete any cookie in the browser sent to the elog server.
| K wrote: |
|
Does not work.
Clean install (debian 8 x64, with aptitude), only thing i've changed in the config is "URL"-parameter (global section) and redirection with Apache. No luck. Edit or delete gives an error "Error: Command "Delete" not allowed", "New" opens login-windows.
Now i removed all (guest) menu and URL settings a use it directly (port 8080), still no luck. "Error: Command "Delete" not allowed". When i click on "New" a login-windows opens.
Tested with the demo-logbook.
| Stefan Ritt wrote: |
|
Sure. Just remove "Password file = ..." and any guest menu.
Stefan
| K wrote: |
|
How can i configure eLog to be used completely anonymous without the need to log in?
I tried menu and guest menu settings without luck. I do not use password files. With earlier versions this was easy to set up...
Thanks in advance
|
|
|
|
|
|
2153
|
Fri Mar 2 16:39:22 2007 |
 | Justin Ellison | justin@techadvise.com | Question | | 2.6.4-179 | Hiding attributes in Detail view? | First off, thanks so much for this product. It works excellent for us as a server activity log. I have a question, which depending on the answer, might be a feature request 
As I mentioned, we use elog as a serverlog. Sometimes, but not always, we will have a Bugzilla bug # that is associated with the log entry. We then take that bug #, and build a link to our bugzilla server displaying the bug. Here's the relevant config entries:
Attributes = Author, Classification, Subject, Bug Number, Environment, Server, Bugzilla
...
#Make the list table narrow enough to fit in the browser
List display = ID, Date, Author, Subject, Server, Bugzilla
...
#We take in a Bug Number from the user, then calculate a Bugzilla link from that
Change Bugzilla = <a href="http://bugz:4545/bugzilla/show_bug.cgi?id=$Bug Number">$Bug Number</a>
List Change Bugzilla = <a href="http://bugz:4545/bugzilla/show_bug.cgi?id=$Bug Number">$Bug Number</a>
Hidden Attributes = Bugzilla
So, on new entry, the user has the option to enter a Bug Number. Bugzilla is not displayed because it is derived. In list view, Bug Number is not displayed, but Bugzilla is, providing a handy link to the bug on a different server.
The only thing that isn't working as I'd like is when someone views a log entry. Both Bug Number and Bugzilla show up in the attributes. This isn't a huge deal, it's just showing redundant data.
Is there a way to hide Bug Number on the view page? |
|
2160
|
Fri Mar 9 22:14:57 2007 |
| Justin Ellison | justin@techadvise.com | Question | | 2.6.4-179 | Re: Hiding attributes in Detail view? | | Any takers? |
|
2162
|
Tue Mar 13 17:27:49 2007 |
 | Justin Ellison | justin@techadvise.com | Request | | Current | Addition of a "Restrict edit attribute" option? | It would be a nice addition to have a config file option named "Restrict edit attribute".
Basically, I would like to have an attribute that was either:
a) An Option Attribute named Status with options of "Open" or "Closed"
b) An Option Attribute named Closed that was boolean.
Then, we could leave the item as editable until either choice "a" above was set to closed or choice "b" was true, at which point only admins could edit the item.
Sound plausible?
Justin |
|
2167
|
Wed Mar 14 15:03:41 2007 |
| Justin Ellison | justin@techadvise.com | Request | | Current | Re: Addition of a "Restrict edit attribute" option? | Sorry, I didn't explain it enough.
This feature is like "Restrict edit time", but instead of setting an entire entry as read only after n hours, we set it read only if attribute y is true. Admin would be able to go in and reset that attribute to false to unlock the entry for editing, but no one else would be able to.
That make more sense?
Justin |
|
2169
|
Wed Mar 14 15:43:51 2007 |
| Justin Ellison | justin@techadvise.com | Request | | Current | Re: Addition of a "Restrict edit attribute" option? |
| Stefan Ritt wrote: |
I understand what you want. The conditional attributes I showed you give you that functionality, except that unlocking is a bit painful for the admin (has to edit the config file each time). Sorry, but that's all I can give you. |
Now I understand what you were getting at. Sorry for the confusion. That should work fine for us - unlocking is something that shouldn't ever happen.
Thanks for the quick response!
Justin |
|
279
|
Sun Apr 13 14:32:52 2003 |
| Justin Dieters | enderak@yahoo.com | Bug report | | | Re: Disappearing attachments | I am using 2.3.4 and I am still having this problem. If someone posts a
message with an attachment, and I then reply to that message, the attachment
gets 'deattached' from that message. However, the file is still in the
logbook directory, so it is possible to recover it, but it did cause a slight
panic the first time it happened :)
I see there is a 2.3.5 version now, but the changelog doesn't say anything
about this problem, so I have not tried it yet.
Is there a 'trick' to fix this problem?
EDIT: I noticed when I replyed to your message, your elog.cfg attachment is
no longer there. So it appears it's not fixed in 2.3.5 either..
> This is a known problem and has been fixed in version 2.3.4, which has been
> released today. To prove that it's working, I attached the current
> elogd.cfg from this forum. |
|
284
|
Mon Apr 14 18:24:18 2003 |
| Justin Dieters | enderak@yahoo.com | Bug report | | | Re: Disappearing attachments | EDIT: I downloaded the latest elogd.c from CVS, replaced the one from the
latest tar, and recompiled. Worked great!
Thanks for the prompt response, Stefan!
> > I am using 2.3.4 and I am still having this problem. If someone posts a
> > message with an attachment, and I then reply to that message, the attachment
> > gets 'deattached' from that message. However, the file is still in the
> > logbook directory, so it is possible to recover it, but it did cause a
> slight
> > panic the first time it happened :)
>
> Uups, that is indeed a problem. I found that it was unrelated to the first
> one, so it was there since quite some time now. I fixed it. It will come out
> in 2.3.6 or can be obtained already now from CVS. It is trongly recommended
> to upgrade all installations to avoid this problem. |
|