Option to require new user registration to subscribe to ALL logbooks, posted by Steve Jones on Mon Nov 6 19:03:11 2006
|
Stefan, any chance of having an option that eliminates the ability of new users to pick the logbooks they can register with? I would like to limit this to the "admin" user to pick per individual.
Also, any thoughts to adding a management panel that will the admin user to make global changes to the password file? I do this by bringing it into a text editor and making changes, but it would be nice to do it from the application. |
Re: Option to require new user registration to subscribe to ALL logbooks, posted by Stefan Ritt on Thu Nov 9 22:57:38 2006
|
| Steve Jones wrote: | | Stefan, any chance of having an option that eliminates the ability of new users to pick the logbooks they can register with? I would like to limit this to the "admin" user to pick per individual. |
The logbook list new users can register with is exactly the list the users have access to. So if you omit a logbook there, they can later just go to that logbook, hit config, and add themselves. If you want to prevent a user from getting notifications from a logbook, prevent user access to that logbook, like a new top group.
| Steve Jones wrote: | | Also, any thoughts to adding a management panel that will the admin user to make global changes to the password file? I do this by bringing it into a text editor and making changes, but it would be nice to do it from the application. |
Not at the moment. It would take days of work which I don't have right now. Much more than what it takes you editing the password file in an editor  |
|
Re: Option to require new user registration to subscribe to ALL logbooks, posted by Steve Jones on Thu Nov 9 23:37:37 2006
|
| Stefan Ritt wrote: |
| Steve Jones wrote: | | Stefan, any chance of having an option that eliminates the ability of new users to pick the logbooks they can register with? I would like to limit this to the "admin" user to pick per individual. |
The logbook list new users can register with is exactly the list the users have access to. So if you omit a logbook there, they can later just go to that logbook, hit config, and add themselves. If you want to prevent a user from getting notifications from a logbook, prevent user access to that logbook, like a new top group.
| Steve Jones wrote: | | Also, any thoughts to adding a management panel that will the admin user to make global changes to the password file? I do this by bringing it into a text editor and making changes, but it would be nice to do it from the application. |
Not at the moment. It would take days of work which I don't have right now. Much more than what it takes you editing the password file in an editor |
| Quote: |
Hmm, by default all users have access to all logs. What I have setup is an announcement logbook and I would simply like to send to all registered users the email when announcements happen. My thought was to simply not allow people to pick which logbooks to "register" with and default to the Announcements logbook. I went ahead and hacked the password file and simply set all accounts to subscribe to all logbooks 
|
|
How can I configure to prevent empty entries?, posted by Alan Stone on Mon Apr 10 20:28:37 2006
|
I have accidentally created a couple of entries recently. It is pretty easy. I
fill in the header, type in a Subject, and then hit Enter, instead of TAB.
I have turned off the edit option intentionally.
I want to avoid this in the future. Is there a configuration option which would
confirm that the user before submitting an entry without a Body? I know I can require
attributes like Author and Subject. I am not sure I want to require a Body, in case
someone submits an entry with just an attachment (and a Subject).
Thanks, Alan |
|
Re: How can I configure to prevent empty entries?, posted by Stefan Ritt on Thu Nov 9 23:10:08 2006
|
| Alan Stone wrote: | I have accidentally created a couple of entries recently. It is pretty easy. I
fill in the header, type in a Subject, and then hit Enter, instead of TAB.
I have turned off the edit option intentionally.
I want to avoid this in the future. Is there a configuration option which would
confirm that the user before submitting an entry without a Body? I know I can require
attributes like Author and Subject. I am not sure I want to require a Body, in case
someone submits an entry with just an attachment (and a Subject).
Thanks, Alan |
Actually the submit/edit behavior is controlled by your browser, not by elog. I do not know any mean of how the HTML code could control this independently of the browser. So you have to get used to it |
|
Is it possible to require certain attributes for specific users (guests)?, posted by Mark Bergman on Tue May 2 22:58:48 2006
|
First of all, thanks for writing and maintaining eLog.
I've been using it for a few years, but I'm now introducing it in an environment that may have a lot of "Guest"
accounts.
I'd like to have two "Required Attributes" when a guest enters a new entry; their name and e-mail address. These
fields don't need to be required for registered accounts, since that information is available already.
Is there any way to have conditional statements act on the value of $short_name?
Thanks,
Mark |
|
Re: Is it possible to require certain attributes for specific users (guests)?, posted by Stefan Ritt on Wed May 3 08:31:52 2006
|
> First of all, thanks for writing and maintaining eLog.
>
> I've been using it for a few years, but I'm now introducing it in an environment that may have a lot of "Guest"
> accounts.
>
> I'd like to have two "Required Attributes" when a guest enters a new entry; their name and e-mail address. These
> fields don't need to be required for registered accounts, since that information is available already.
>
> Is there any way to have conditional statements act on the value of $short_name?
No, this is not implemented. The only way you have right now is to make two separate logbooks, one for guests and
one for registered users. But I know this is not an optimal solution. I will think about it. |
|
Re: Is it possible to require certain attributes for specific users (guests)?, posted by Stefan Ritt on Thu Nov 9 23:04:32 2006
|
> First of all, thanks for writing and maintaining eLog.
>
> I've been using it for a few years, but I'm now introducing it in an environment that may have a lot of "Guest"
> accounts.
>
> I'd like to have two "Required Attributes" when a guest enters a new entry; their name and e-mail address. These
> fields don't need to be required for registered accounts, since that information is available already.
>
> Is there any way to have conditional statements act on the value of $short_name?
>
> Thanks,
>
> Mark
Actually there is one possibility:
Preset Author = $long_name
Required Attributes = Author
This will force the author to be supplied. If one is logged in, the login name will be put into the author field. If
there is guest access, the field will contain "anonymous", so hopefully each guest will change that to the real name... |
suggestion for "new user registration" page, posted by Mark Bergman on Sat May 6 02:12:10 2006
|
I'm testing elog, and one user was having difficulty creating a new account for himself. This problem had three reasons:
1. the user expected a "submit" button or some other way to exit the account registration screen to appear near the password boxes, at the bottom of the page.
2. I'm using the "Bottom text" option, which has a URL to execute a "find" (search) within elog for all open tickets. The user simply entered the info for their new account, and then clicked on the button at the bottom of the page--which would be the expected behavior.
3. In our environment, there are many logbooks (~100), as each computing device has it's own logbook. This isn't a problem on the main page, since the logbooks are grouped into 7 categories. However, the account registration page combines two functions--setting up a new account, and selecting which logbooks to subscribe to for e-mail notification. The logbooks are presented in a list (rather than groups), which causes the "Save" button at the top left to scroll off the screen before the user enters their password.
Suggestions for improving the registration page:
Put a "submit" button after the password entry.
Possibly supress the local "bottom text", or allow the specification of a different file for the registration page.
After the user has registered, then show a page allowing them to subscribe for e-mail notifcation. That page should be organized the same way as the main page, with groups. Users should be allowed to subscribe to entire groups, or to expand each group to select or unsubscribe from individual logbooks.
Thanks,
Mark |
|
Re: suggestion for "new user registration" page, posted by Stefan Ritt on Thu Nov 9 22:40:06 2006
|
| Mark Bergman wrote: | Suggestions for improving the registration page:
Put a "submit" button after the password entry.
Possibly supress the local "bottom text", or allow the specification of a different file for the registration page.
After the user has registered, then show a page allowing them to subscribe for e-mail notifcation. That page should be organized the same way as the main page, with groups. Users should be allowed to subscribe to entire groups, or to expand each group to select or unsubscribe from individual logbooks.
Thanks,
Mark |
I put the "save" button below the password entry and removed the "bottom text", I hope this helps a bit. |
|
Problem with large entry size, posted by Dimitrios Tsirigkas on Mon Oct 16 16:20:06 2006
|
Hi Stefan,
I have posted an entry of approximately a thousand lines (ten thousand words). Posting it took some time, which is logical to a certain degree. However, whenever a user asks for "Full" view of the logbook, the page takes around two minutes to load and the CPU usage on the elog server goes to beyond 90% for all this time. Is this to be expected for an entry of that size or is there something going wrong here?
Thanks,
Dimitris |
|
Re: Problem with large entry size, posted by Stefan Ritt on Mon Oct 16 16:53:43 2006
|
| Dimitrios Tsirigkas wrote: | | I have posted an entry of approximately a thousand lines (ten thousand words). Posting it took some time, which is logical to a certain degree. However, whenever a user asks for "Full" view of the logbook, the page takes around two minutes to load and the CPU usage on the elog server goes to beyond 90% for all this time. Is this to be expected for an entry of that size or is there something going wrong here? |
The problem lies in the ELCode parsing. When you post an entry in ELCode form, the elogd server has to parse every word to see if it's any of the ELcode tags. This is right now implemented in a kind of poor way, such that it takes very long for long entries. I will work to optimize that. In the meantime, it will help if you post such long entries just in "plain" form.
- Stefan |
|
Re: Problem with large entry size, posted by Stefan Ritt on Mon Oct 16 17:18:58 2006
|
I improved the performance by some factor in SVN revision 1733. Can you give it a try and report your speed improvement? Depending on the result, I can probably do even a bit better with some more effort.
- Stefan |
|
Re: Problem with large entry size, posted by Dimitrios Tsirigkas on Mon Oct 16 17:32:58 2006
|
| Stefan Ritt wrote: | I improved the performance by some factor in SVN revision 1733. Can you give it a try and report your speed improvement? Depending on the result, I can probably do even a bit better with some more effort.
- Stefan |
Dear Stefan,
Thank you for your quick reply. I will install the new version and I will let you know as soon soon as possible.
Best,
Dimitris |
|
Re: Problem with large entry size, posted by Dimitrios Tsirigkas on Tue Oct 17 14:39:29 2006
|
| Stefan Ritt wrote: |
The problem lies in the ELCode parsing. When you post an entry in ELCode form, the elogd server has to parse every word to see if it's any of the ELcode tags. This is right now implemented in a kind of poor way, such that it takes very long for long entries. I will work to optimize that. In the meantime, it will help if you post such long entries just in "plain" form.
- Stefan |
Hi again,
I was wondering what is the cleanest way of changing old entries already submitted in ELCode into plain text. If I do not include ELCode in the allowed encodings does this apply to already submitted entries as well or will they still be treated as ELCode?
Thanks,
Dimitris |
|
Re: Problem with large entry size, posted by Stefan Ritt on Tue Oct 17 14:42:58 2006
|
| Dimitrios Tsirigkas wrote: | | I was wondering what is the cleanest way of changing old entries already submitted in ELCode into plain text. If I do not include ELCode in the allowed encodings does this apply to already submitted entries as well or will they still be treated as ELCode? |
The encoding is stored as an "invisible" attribute in each entry. You can change it in two ways:
1) Select each entry, click "edit", change the encoding with the radio buttons at the bottom and submit it again
2) Go and edit directly the xxxxxxa.log files in your logbook directory. You will see in those files something like
Encoding: ELCode
and you can change it with an editor to
Encoding: plain
Afterwards you have to restart the elogd daemon.
Did you try the new version, would be interesting to see if it's any better... |
|
Re: Problem with large entry size, posted by Dimitrios Tsirigkas on Tue Oct 17 14:47:53 2006
|
Thanks Stefan,
| Stefan Ritt wrote: | | Did you try the new version, would be interesting to see if it's any better... |
I didn't find the time to try it yet but I will do that later today. I will keep you posted - more soon.
Cheers,
Dimitris |
|
Re: Problem with large entry size, posted by Dimitrios Tsirigkas on Mon Oct 23 12:53:08 2006
|
Hi Stefan,
A lot of performance-related trouble for us comes from the ability of users to click on "All" and display thousands of entries on the same page. Is there a way to disable that? Even if the ELCode parsing performance of Elog increases greatly, the combination of "Full" mode and "All" will still cause trouble, will it not?
Thanks,
Dimitris |
|
Re: Problem with large entry size, posted by Stefan Ritt on Tue Oct 24 21:58:54 2006
|
| Dimitrios Tsirigkas wrote: | Hi Stefan,
A lot of performance-related trouble for us comes from the ability of users to click on "All" and display thousands of entries on the same page. Is there a way to disable that? Even if the ELCode parsing performance of Elog increases greatly, the combination of "Full" mode and "All" will still cause trouble, will it not?
Thanks,
Dimitris |
What about a threshold for the "All" display? If a logbook contains less than, let's say, 500 entries, the "All" link is displayed, and above 500 entries it's hidden. Would that make sense? |
|
Re: Problem with large entry size, posted by Dimitrios Tsirigkas on Thu Nov 2 10:14:11 2006
|
| Stefan Ritt wrote: | | What about a threshold for the "All" display? If a logbook contains less than, let's say, 500 entries, the "All" link is displayed, and above 500 entries it's hidden. Would that make sense? |
Hi Stefan,
Sorry for the late response, I was away for a few days. Yes, I think that this would make perfect sense, especially if the maximum number of entries was configurable.
Cheers,
Dimitris |
|
Re: Problem with large entry size, posted by Stefan Ritt on Thu Nov 9 21:22:27 2006
|
| Dimitrios Tsirigkas wrote: |
| Stefan Ritt wrote: | | What about a threshold for the "All" display? If a logbook contains less than, let's say, 500 entries, the "All" link is displayed, and above 500 entries it's hidden. Would that make sense? |
Hi Stefan,
Sorry for the late response, I was away for a few days. Yes, I think that this would make perfect sense, especially if the maximum number of entries was configurable.
Cheers,
Dimitris |
Agree. So I implemented the new config option All display limit. The default is 500. So you can see that at this forum, the All link is not shown any more, since the logbook contains more than 500 entries. The promised performance improvement of the page display will take me some more time, but I will not forget it. |
|
ELCode, posted by Alexandre Lindote on Wed Oct 25 18:00:24 2006
|
Hi,
can you think of any obvious reason why the ELCode would not work in the logbooks I set up?
I can use it here, on the forum, and on the DEMO logbook, but not on the ones I created...
Oh, and me inserting "Allowed encoding = " whatever in the config file doesn't seem to mater as well... I always get the 3 options!
Am I missing a flag somewhere?
The config file for this logbook is below...
Thanks a lot
Alex
Theme = default
Page Title = ZEPLIN-III Idiot's Guide
Comment = ZEPLIN-III Idiot's Guide - test phase
Subdir = idiots_guide
Time format = %A, %B %d, %Y, %H:%M
Date format = %A, %B %d, %Y
Menu commands = List, New, Edit, Delete, Download, Find, Last day, Config, Admin, Login, Logout, Help
Display mode = summary
Preset Author = $long_name
Attributes = Author, Type, Subject
Options Type = Software, Hardware
Required Attributes = Author, Type, Subject
Reverse sort = 1
Quick filter = Type, Subject
List Display = Edit, Type, Subject, Author, Date
;define zeplin3 as a user who can enter and read entries, but not modify
;or create new entries
;Deny New = zeplin3
;Deny Edit = zeplin3
;Deny Reply = zeplin3
;Deny Delete = zeplin3
Deny Config = zeplin3
;Deny CSV Import = zeplin3
;define that only the administrator will see the Admin link
Allow Admin = alex
;Remove email notification for now. There's no SMTP server working...
Suppress default = 3
Suppress Email on edit = 3
;show or hide the mode menu
Mode commands = 0
;With this option, an entry being edited by another user becomes red
;Use Lock = 1
;allow only html and text entries for now
Allowed encoding = 3
Default encoding = 1 |
|
Re: ELCode, posted by Stefan Ritt on Wed Oct 25 19:44:11 2006
|
| Alexandre Lindote wrote: | | can you think of any obvious reason why the ELCode would not work in the logbooks I set up? |
There is a good reason why this forum contains a ELOG Version tag which you are supposed to fill out for new entries. Without knowing which version you are using I cannot help you. Probably you have an old version which does not support the Allowed encoding. |
|
Re: ELCode, posted by Alexandre Lindote on Wed Oct 25 21:52:13 2006
|
| Stefan Ritt wrote: |
| Alexandre Lindote wrote: | | can you think of any obvious reason why the ELCode would not work in the logbooks I set up? |
There is a good reason why this forum contains a ELOG Version tag which you are supposed to fill out for new entries. Without knowing which version you are using I cannot help you. Probably you have an old version which does not support the Allowed encoding. |
Sorry about that... it's 2.6.2-1699, so a very recent one. |
|
Re: ELCode, posted by Alexandre Lindote on Fri Oct 27 13:02:50 2006
|
| Alexandre Lindote wrote: | Hi,
can you think of any obvious reason why the ELCode would not work in the logbooks I set up?
|
Ok, I think I found the problem... For some reason the elcode.js file was only in /usr/local/elog/scripts, but it was supposed to be in
/usr/local/elog/themes/default/ as well.
Creating a symlink between the two solved that problem. I can now do most things with the ELCode, but inserting images is still failing. I get this message from the firefox javascript console:
text.value has no properties (line 32 of elcode.js)
Any thoughts?
Alex |
|
Re: ELCode, posted by Stefan Ritt on Thu Nov 9 21:03:03 2006
|
| Alexandre Lindote wrote: |
| Alexandre Lindote wrote: | Hi,
can you think of any obvious reason why the ELCode would not work in the logbooks I set up?
|
Ok, I think I found the problem... For some reason the elcode.js file was only in /usr/local/elog/scripts, but it was supposed to be in
/usr/local/elog/themes/default/ as well.
Creating a symlink between the two solved that problem. I can now do most things with the ELCode, but inserting images is still failing. I get this message from the firefox javascript console:
text.value has no properties (line 32 of elcode.js)
Any thoughts?
Alex |
That's really strange. In the forum (http://midas.psi.ch/elogs/Forum), I have the elcode.js only in /usr/local/elog/scripts, and it works as you can try out yourself. Getting your javascript error might indicate that you have an old version of elcode.js combined with a newer executable of elogd. Try to update it. |
|
calling a shell in the Options tag, posted by Alexandre Lindote on Tue Oct 31 20:05:07 2006
|
Hi,
is it possible to run a shell script in an "Options" tag, as it is with the "Preset", "Subst", and so on?
I need to have something like this:
Options Update of = $shell(/home/alex/zeplin3/elog/z3elog-mirror/documents/ext_docs.sh MinGen)
the script returns a line with comma separated values...
Thanks
Alex |
|
Re: calling a shell in the Options tag, posted by Steve Jones on Tue Oct 31 22:07:06 2006
|
| Alexandre Lindote wrote: | Hi,
is it possible to run a shell script in an "Options" tag, as it is with the "Preset", "Subst", and so on?
I need to have something like this:
Options Update of = $shell(/home/alex/zeplin3/elog/z3elog-mirror/documents/ext_docs.sh MinGen)
the script returns a line with comma separated values...
Thanks
Alex |
| Steve Jones wrote: |
Alex, have you tried it? Novel idea!
|
|
|
Re: calling a shell in the Options tag, posted by Alexandre Lindote on Wed Nov 1 09:53:05 2006
|
| Steve Jones wrote: |
| Alexandre Lindote wrote: | Hi,
is it possible to run a shell script in an "Options" tag, as it is with the "Preset", "Subst", and so on?
I need to have something like this:
Options Update of = $shell(/home/alex/zeplin3/elog/z3elog-mirror/documents/ext_docs.sh MinGen)
the script returns a line with comma separated values...
Thanks
Alex |
| Steve Jones wrote: |
Alex, have you tried it? Novel idea!
|
|
Yes, I have. It doesn't seem to... 
I just get one option, which is the shell line itself.
Something like:
--- Please select ---
$shell(/home/alex/zeplin3/elog/z3elog-mirror/documents/ext_docs.sh MinGen)
Cheers
Alex |
|
Re: calling a shell in the Options tag, posted by Stefan Ritt on Thu Nov 9 20:59:01 2006
|
| Alexandre Lindote wrote: | Hi,
is it possible to run a shell script in an "Options" tag, as it is with the "Preset", "Subst", and so on?
I need to have something like this:
Options Update of = $shell(/home/alex/zeplin3/elog/z3elog-mirror/documents/ext_docs.sh MinGen)
the script returns a line with comma separated values...
Thanks
Alex |
Interesting idea, but substitutions only work for config setting where the documentation explicitly states so. The complete list comes here:
- Preset <attibute>
- Preset on reply <attribute>
- Preset on duplicate <attribute>
- Subst <attribute>
- Subst on reply <attribute>
- Subst on edit <attribute>
- Change <attribute>
- Email <attribute> <value>
- Use email from
- Use Email heading
- Use Email subject
- Bottom text
- Top text
- Edit page title
- Prepend on edit
- Append on edit
- Append on reply
- Quote on reply
- Preset text
- Page title
- RSS title
- List page title
Doing shell execution for all configuration settings would slow down the server too much. |
|
Denial of Service Vulnerability of elog 2.6.2-6, posted by Stefan Ritt on Wed Nov 8 13:59:52 2006
|
Dear ELOG users,
a denial of service vulnerability has been reported which affects all elog versions prior to 2.6.2-7. With a special request one can crash the elogd server, given that one has access either through a public read access or through an account. This vulnerability has been fixed in version 2.6.2-7. It is advised that all sensitive installations of ELOG are being updated.
Stefan Ritt |