Re: feature req.: identify ELOG web pages via META element, posted by Stefan Ritt on Wed Oct 21 19:06:59 2009
|
| Bill Pier wrote: |
|
* Withdrawn *
The HTML layout produced by elogd is horrendous to deal with programmatically; I give up.
Hi,
I'm writing a greasemonkey script to slightly alter the look of the pages served by the ELOG server. One difficulty that I'm struggling with is how to identify what type of page ELOG has created. While I have several methods to determine the page type, such as a log entry vs. log entries summary, the solutions are not straight forward and not clean. As far as I tell, there's no specific identification in HTML document currently that describes and identifies the type of page being served by the ELOG server.
So, I'm requesting that the pages created by ELOG be identified in some fashion with the META element, such as:
<meta name="description" content="elog log entry" />
or
<meta name="description" content="elog log summary" />
or even using the keywords attribute:
<meta name="keywords" content="elog log summary" />
|
Sorry, I didn't yet have time to implement your request.
Have you considered to download an entry in plain text? Like this entry you can load with
https://midas.psi.ch/elogs/Forum/66555?cmd=Download
which should be much easier to interprete. If you write your entries in ELCode or plain format, it should be even easier. |
|
Re: Option list length, posted by soren poulsen on Mon Oct 26 10:13:54 2009
|
| Stefan Ritt wrote: |
|
| soren poulsen wrote: |
|
Hi,
I use the following attribute definition:
Options <attribute> = <list>
However, I am being limited by the list length limit of 100. I have 103 items, but I only see 100.
Could the limit be extended (to 200 for instance) ?
Thanks a lot for your help
Soren
|
You can change that yourself. Just find following line in elogd.c:
#define MAX_N_LIST 100
and change it to 200, then recompile. But you are there on your own, at some point you will get a stack overflow and elogd will crash, but I don't know exactly where this limit is.
Anyhow I would propose that if you have so many options in an attribute, that you better go and group these options somehow. Like using two attributes, where the first defines the group, and the second gets different list for each option of the first attribute using conditional attributes. Have a look here.
|
Thanks. This is a good explanation. It might indeed be better to re-group the options to have a shorter list.
Soren |
|
Re: User authorization file corruption, posted by soren poulsen on Mon Oct 26 10:15:20 2009
|
| Stefan Ritt wrote: |
|
| soren poulsen wrote: |
|
Hi,
Here is what happens (I think) if E-log encounters a full file system where it keeps the user authorization file:
1. When a user connects, E-log will make a backup of the file. The backup will be corrupt since the file system is full.
2. E-log will modify the contents of the original file, and write it back. The file will be corrupt since the file system is full.
3. Now, both the backup and the normal file are corrupt and you cannot log on, until someone cleans up the file system and restores a valid copy of the file.
Would it be possible to fix this ? Like abort if step 1 is not successful. And restore the backup file if step 2 is not successful.
Thanks a lot for you help
Soren
|
Ok, I finally found some time (I'm pretty busy these days) to add a check for a potential full file system in SVN revision 2258. So before the password file would get corrupted, elog shows an error message about the full file system and just stops to work until space is freed up.
|
Great. We fully appreciate that your are busy (with other things than E-log).
Thanks for the resolution.
Soren |
|
Re: Automatically generated incrementing tags (#), posted by soren poulsen on Mon Oct 26 15:43:55 2009
|
| soren poulsen wrote: |
|
| soren poulsen wrote: |
|
Hi,
I am using the # character to generate automatically incrementing numbers for new messages.
My issue is that # is evaluated when you hit "New" but E-log is only aware of the new value being used when you hit "Submit".
So, two E-logs can have the same value substituted for # if two E-logs are being edited in parallel.
Maybe someone has a solution to this ?
Soren Poulsen
|
The solution is to use "Subst" instead of "Preset".
|
This is not really resolved, since "Subst" creates a new number on both "New" and "Reply". I would like "Subst" to create a new number only on "New" and preserve this number through replies throughout the thread. I would like to be able to say "Subst thread = #" to make a new number for the thread and combine it with "Subst on reply thread = $thread" to preserve the number on replies, but this does not work. Maybe someone has already done this ?
Soren |
|
Re: "Collapse to last = 1" problem when reply twice to the same entry, posted by David Pilgram on Thu Oct 29 20:58:59 2009
|
> Hello.
>
> Please look at the entry 66525 of this forum (just 5 thread before this one):
>
> -> chain.crt, posted by Gerhard Schneider on Thu Sep 3 21:55:52 2009 (66525)
> |-> Re: chain.crt, posted by Stefan Ritt on Fri Sep 4 08:33:16 2009 (66526)
> |-> Re: chain.crt, posted by Gerhard Schneider on Wed Oct 7 07:56:52 2009 (66556)
>
> When you collapse the thread, it is collapsed to the 66526 instead of the 66556 (more recent)
>
> + Re: chain.crt, posted by Stefan Ritt on Fri Sep 4 08:33:16 2009
>
> I guess it is because both 66526 and 66556 replies to the first entry.
> I have the same problem with Elog v2.7.7-2246 and Windows.
>
> In general, it seems to work well only if you always reply to the last entry of a thread.
>
> Thank you.
>
>
> b.t.w. : is there any tip to always force reply to the last entry of a thread?
As the person who suggested this concept, I have to admit I've yet to think of a good way around this issue.
Preventing "branching" is all very well, but sometimes it is relivent to have a branch (although I usually try to
avoid them). Unless elog scans every possible branch to find where the latest entry, I cannot think of a
foolproof, practical scheme. |
|
Re: 2.7.6 and 2.7.7 crash upon opening logbook that runs on 2.7.5, posted by Stefan Ritt on Tue Nov 3 09:04:34 2009
|
| David Spindler wrote: |
|
I upgraded 2.7.5 rev 2175 to 2.7.7 rev 2246 last Thursday. I tested it with several logbooks with no problems. However I received a rep[ort today that it was down. I discovered whenever I tried to open a logbook entitled "Equipment Reservation" in the folder "EquipmentReservations" Elog would crash. I checked the elog.log file with no entries in it other than showing when it was restarted. I backed up to 2.7.5 and had no porblems with the same logbook. I repeated the upgrade to 2.7.7 with the crash problem returning. I am now back on 2.7.5 with no problems.
I just decided to try 2.7.6 rev 2239 and had the same results as 2.7.7.
This is running under Win2K with SP4 as an automatic service on port 80.
I am also running Elog V2.7.4-2118 on a different port (8080) simultaneously with no problems.
If you wish I will send the elog.cfg file. Anything else I can do to help, please let me know.
|
I need to reproduce your problem. Therefore I need the configuration and the xxxxxxa.log file containing the offending entries. You can strip it down to the minimum needed to do the crash. |
|
Re: Emails generated by *this* discussion forum, posted by Stefan Ritt on Tue Nov 3 09:14:14 2009
|
> Hi Stefan,
>
> After 21.Oct, all the emails sent out by this discussion form now are addressed to
>
> ELOG@ananke.jtan.com
> the name of the server my mails are sent to.
>
> Before that the emails were addressed to
>
> ELOG@emix.psi.ch
>
> Obviouisly my real email address is there, in the headers (as it would appear for a BCC)
>
> The only consequence for me was these emails turned up in the wrong mailbox, but perhaps it has wider implications?
Indeed on Oct. 21st the SMPT server sending out emails from this forum has been changed. I checked my own mails coming
from the forum, but I could not find any hint of what you describe above. The "From:" header contains "noreply@psi.ch"
and the "To:" header is my email address. The "Received:" header contains our SMTP server, but you should not that field
for filtering your email.
- Stefan |
|
Re: Access control, group level, posted by Stefan Ritt on Tue Nov 3 09:24:15 2009
|
| Niklas wrote: |
|
Hi elog experts =)
Anyone know if it's possible to have access control per group-level?
For instance:
Group A = B,C
Group B = LogA
Group C = LogB, LogC
Group C: Read password = abc
//NH
|
I added your vote to the wishlist
https://midas.psi.ch/elog/wishlist.html |
|