Re: Hiding attributes in Detail view?, posted by Justin Ellison on Fri Mar 9 22:14:57 2007
|
| Any takers? |
Addition of a "Restrict edit attribute" option?, posted by Justin Ellison on Tue Mar 13 17:27:49 2007
|
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 |
|
Re: Addition of a "Restrict edit attribute" option?, posted by Justin Ellison on Wed Mar 14 15:03:41 2007
|
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 |
|
Re: Addition of a "Restrict edit attribute" option?, posted by Justin Ellison on Wed Mar 14 15:43:51 2007
|
| 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 |
|
Re: Disappearing attachments, posted by Justin Dieters on Sun Apr 13 14:32:52 2003
|
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. |
|
Re: Disappearing attachments, posted by Justin Dieters on Mon Apr 14 18:24:18 2003
|
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. |
|
Re: problem with 20+ attachments, posted by Justin Dieters on Tue Apr 22 22:23:27 2003
|
I've been using elog for several months now, and one thing that's always
seemed odd to me are the things like max number of attachments and max
attachment size are defined right in the source code, and not in the config
file. It would seem that it would be simple to be able to define stuff like
that in the config file (and have defaults in case they weren't specified),
which would fix a lot of the recompiling problems - just edit the config file
and restart elog. Not that recompiling elog is difficult, it just seems like
recompiling for such a simple setting is overkill...
Anyway, just curious. Is there a technical reason this is not done?
Justin
> source of it. The reply/attachment bug is fixed, and a warning about
> exceeding the number of attachments will come soon. |
Update request for Admin Guide, posted by Justin Dieters on Tue Nov 18 23:19:57 2003
|
Heya, I've been using elog for a year or so, with a proxy through Apache,
but recently I've ran into some trouble with my Apache config, where
spammers were using my incorrectly configured proxy to send spam.
I have
some requests for the Administrator's Guide: "Running elogd under Apache".
I'm hoping a few little notes will save others the trouble I've gone
through. Neither of these are any fault of elog's or Apache's, but of my own
ignorance. (I am using elog 2.3.9, and Apache 2.something, if that matters)
1) When doing "ProxyPass ..." when setting up elog under Apache, do NOT put
"ProxyRequests On". This is not needed, if it is enabled and not set up
correctly, it allows spammers to send spam via Apache's proxy. More
information on this is here: http://www.apacheweek.com/issues/03-07-25,
about halfway down the page, under "Spammers use open Apache proxies"
Even though it doesn't mention ProxyRequests in the guide, I think there
should be a little side note mentioning that "ProxyRequests On" is NOT
needed, because I put it in, thinking it was - I am probably not the only one.
2) I have found that mod_proxy_http.c must be loaded in addition to
mod_proxy.c and mod_alias.c for the proxy to work, otherwise I get a 403
error. I think this should be mentioned as well. |
|