ID |
Date |
Icon |
Author |
Author Email |
Category |
OS |
ELOG Version |
Subject |
67884
|
Wed May 6 15:13:11 2015 |
| Christof Hanke | hanke@rzg.mpg.de | Bug fix | All | 3.1.0 | parse a correctly the username in save_user_config when using Webserver authentication | Hi Stefan,
When we use Webserver authentication, we have the correct username already in the variable http_user.
The old way of copying this http_user to "user" is wrong since we don't use the size of http_user.
Instead, just encode the http_user variable directly.
See attached patch against git HEAD.
Christof
|
67922
|
Wed May 20 18:46:27 2015 |
| Andreas Luedeke | andreas.luedeke@psi.ch | Comment | All | 3.1.0 | Re: elogd moves elog entries | > Stefan told me that the change was because some users were having thousands of yymmdda.log files
> in the logbook directories, and that sorting them into subdirectories by year at least did something to bring some
> order. Possibly to get around the lazy archivers, I suspect.
I'm actually the culprit, who did ask for it.
If you want to know the full story, here it is:
We have our logbook data of our accelerator operation logbooks on AFS (Andrew File System).
And apparently AFS has a bloody stupid, hard coded limit:
the total length of all file names in one directory cannot exceed 64k.
Our operation logbooks go back for more than a decade and do contain many, many, many attachment files.
One day - very unexpectedly - we did hit that limit.
Removing temporary files (generated picture thumbnails) bought us time, and Stefan was nice enough to upgrade ELOG swiftly for us: a big "Thank You" to Stefan! |
67923
|
Wed May 20 19:05:43 2015 |
| David Pilgram | David.Pilgram@epost.org.uk | Comment | All | 3.1.0 | Re: elogd moves elog entries | > > Stefan told me that the change was because some users were having thousands of yymmdda.log files
> > in the logbook directories, and that sorting them into subdirectories by year at least did something to
bring some
> > order. Possibly to get around the lazy archivers, I suspect.
>
> I'm actually the culprit, who did ask for it.
>
> If you want to know the full story, here it is:
> We have our logbook data of our accelerator operation logbooks on AFS (Andrew File System).
> And apparently AFS has a bloody stupid, hard coded limit:
> the total length of all file names in one directory cannot exceed 64k.
> Our operation logbooks go back for more than a decade and do contain many, many, many attachment files.
> One day - very unexpectedly - we did hit that limit.
> Removing temporary files (generated picture thumbnails) bought us time, and Stefan was nice enough to upgrade
ELOG swiftly for us: a big "Thank You" to Stefan!
Hi Andreas,
I had no intention of causing any offence with my lazy archiving comment - hope I didn't, sorry if I did. Just
that sometimes I've hit some limit or other, and
entirely due to my lazy archiving - I only get around to do it when I have to, usually when I've hit a limit, or
some other problem (broken links and orphaned
threads being common ones).
Personally, I would have found it useful to put the attachments into a separate directory - or at least to allow
the possibility. Elog as it stands sometimes
can, and sometimes cannot cope with that functionality - and even to try means messing around directly with the
yymmdda.log files. For me it would have saved me
having duplicates of the same large attachment in two or three different logbooks, if I could always reference
the same Master copy of the attachment. This was
at the time I was severely memory constrained, and in part forced me to change how I had operated elog, so for
me that need isn't as great as it once was.
David. |
67927
|
Thu May 21 10:59:07 2015 |
| Andreas Luedeke | andreas.luedeke@psi.ch | Comment | All | 3.1.0 | Re: elogd moves elog entries |
I had no intention of causing any offence with my lazy archiving comment - hope I didn't, sorry if I did.
No offence taken :-)
Personally, I would have found it useful to put the attachments into a separate directory - or at least to allow
the possibility. Elog as it stands sometimes can, and sometimes cannot cope with that functionality - and even to try means messing around directly with the
yymmdda.log files. For me it would have saved me having duplicates of the same large attachment in two or three different logbooks, if I could always reference
the same Master copy of the attachment. This was at the time I was severely memory constrained, and in part forced me to change how I had operated elog, so for
me that need isn't as great as it once was.
David.
You can put a reference to the attachment of the other entry in your logbook: elog:67896/1
Or, if it is an image, you can just include it in your new entry like I did below.
Of course this only works if the other logbook is accessible on-line.
But how would you manage access rights to a common attachment folder?
Probably I just did not understand your idea.
Cheers
Andreas
|
67942
|
Wed May 27 14:22:11 2015 |
| Edmund Hertle | edmund.hertle@kit.edu | Question | All | 3.1 | Formatting multiple datetime entries | Hey
in one of my measurement logbooks I'm using two datetime entries (for start and end time of a measurement). The entries are created automatically by the measurement script.
Attributes = Time Start, Time End
Type Time Start = datetime
Type Time End = datetime
Time format = %H:%M:%S
For better visual appearance I would like to only display the time on the two additional datetime fields but keep the full date and time on the standard date field. Using the "Time format" option will influence all three at once.
Is there an option to do something like the time format for individual attributes (similar to the syntax of adding comments etc)?
Example:Attributes = Time Start, Time End
Type Time Start = datetime
Type Time End = datetime
Time format Time Start = %H:%M:%S
Time format Time End = %H:%M:%S
|
67959
|
Fri Jun 5 14:24:34 2015 |
| Stefan Ritt | stefan.ritt@psi.ch | Info | All | 3.1.0+ | Different way CSS files are handled | Hi,
I just implemented a different way CSS files are handled in ELOG. Previously, we had the default.css, which could be adjusted for specific needs. Some people did that (like myself). So I changed a few colors etc. When I now implement a new feature in elog, it might need a new CSS class which I put in default.css. But this means that people who have modified this file get it either overwritten, or do not get the new styles.
In order to fix this, the default.css is now called elog.css and is always inluded in any ELOG page. If one specifies a CSS file with "CSS = <file.css>", then this CSS file is loaded in addition to elog.css. So one can put only the modifications into that file and inherits all the rest from elog.css. If new features come in elog.css, the installation with the personalized CSS file will then get the new features from the new elog.css automatically, and just overwrite a few settings in the personalized file. Here is an example:
elog.css:
td {
color:black;
font-size:12px;
}
Personalized file special.css, activated with "CSS = special.css" in the elogd.cfg file:
td {
font-size:18px;
}
This personalized file now overwrites the font size from elog.css to 18 pixel, while maintaining all the rest from elogd.css.
The modification is committed to GIT and will be contained in the next release of elog.
/Stefan |
67960
|
Fri Jun 5 19:01:05 2015 |
| Andreas Luedeke | andreas.luedeke@psi.ch | Info | All | 3.1.0+ | Re: Different way CSS files are handled | Hi Stefan,
there is a little problem with the Makefile (on SL5 and SL6): the following line:
@$(INSTALL) -m 0644 themes/default/* $(ELOGDIR)/themes/default/
/usr/bin/install: omitting directory `themes/default/icons'
make: *** [install] Error 1
When I go back to the old Makefile construct:
@$(INSTALL) -m 0644 themes/default/icons/* $(ELOGDIR)/themes/default/icons/
@for file in `find themes/default -type f` ;\
do \
if [ ! -f $(ELOGDIR)/themes/default/`basename $$file` ]; then \
$(INSTALL) -m 0644 $$file $(ELOGDIR)/themes/default/`basename $$file` ; \
fi; \
done
then it seems to work again.
Cheers
Andreas
Stefan Ritt wrote: |
Hi,
I just implemented a different way CSS files are handled in ELOG. Previously, we had the default.css, which could be adjusted for specific needs. Some people did that (like myself). So I changed a few colors etc. When I now implement a new feature in elog, it might need a new CSS class which I put in default.css. But this means that people who have modified this file get it either overwritten, or do not get the new styles.
In order to fix this, the default.css is now called elog.css and is always inluded in any ELOG page. If one specifies a CSS file with "CSS = <file.css>", then this CSS file is loaded in addition to elog.css. So one can put only the modifications into that file and inherits all the rest from elog.css. If new features come in elog.css, the installation with the personalized CSS file will then get the new features from the new elog.css automatically, and just overwrite a few settings in the personalized file. Here is an example:
elog.css:
td {
color:black;
font-size:12px;
}
Personalized file special.css, activated with "CSS = special.css" in the elogd.cfg file:
td {
font-size:18px;
}
This personalized file now overwrites the font size from elog.css to 18 pixel, while maintaining all the rest from elogd.css.
The modification is committed to GIT and will be contained in the next release of elog.
/Stefan
|
|
67968
|
Tue Jun 9 09:39:14 2015 |
| Stefan Ritt | stefan.ritt@psi.ch | Info | All | 3.1.0+ | Re: Different way CSS files are handled | Ok, fixed again.
Andreas Luedeke wrote: |
Hi Stefan,
there is a little problem with the Makefile (on SL5 and SL6): the following line:
@$(INSTALL) -m 0644 themes/default/* $(ELOGDIR)/themes/default/
/usr/bin/install: omitting directory `themes/default/icons'
make: *** [install] Error 1
When I go back to the old Makefile construct:
@$(INSTALL) -m 0644 themes/default/icons/* $(ELOGDIR)/themes/default/icons/
@for file in `find themes/default -type f` ;\
do \
if [ ! -f $(ELOGDIR)/themes/default/`basename $$file` ]; then \
$(INSTALL) -m 0644 $$file $(ELOGDIR)/themes/default/`basename $$file` ; \
fi; \
done
then it seems to work again.
Cheers
Andreas
Stefan Ritt wrote: |
Hi,
I just implemented a different way CSS files are handled in ELOG. Previously, we had the default.css, which could be adjusted for specific needs. Some people did that (like myself). So I changed a few colors etc. When I now implement a new feature in elog, it might need a new CSS class which I put in default.css. But this means that people who have modified this file get it either overwritten, or do not get the new styles.
In order to fix this, the default.css is now called elog.css and is always inluded in any ELOG page. If one specifies a CSS file with "CSS = <file.css>", then this CSS file is loaded in addition to elog.css. So one can put only the modifications into that file and inherits all the rest from elog.css. If new features come in elog.css, the installation with the personalized CSS file will then get the new features from the new elog.css automatically, and just overwrite a few settings in the personalized file. Here is an example:
elog.css:
td {
color:black;
font-size:12px;
}
Personalized file special.css, activated with "CSS = special.css" in the elogd.cfg file:
td {
font-size:18px;
}
This personalized file now overwrites the font size from elog.css to 18 pixel, while maintaining all the rest from elogd.css.
The modification is committed to GIT and will be contained in the next release of elog.
/Stefan
|
|
|
|