ID |
Date |
Icon |
Author |
Author Email |
Category |
OS |
ELOG Version |
Subject |
68056
|
Wed Jul 22 22:54:59 2015 |
| Jaime Duran | jduran@yorku.ca | Bug report | Linux | 3.1.0-2 | elogd crashes with a URL | URL causes elogd to crash when a global password file name doesn't match any group's password file name.
The offending URL is copied from the address field of the browser after sorting a logbook by on of the fileds.
After login out and using the copied URL, elogd shows the authentication dialog and then crashes after the credentials are submited.
Some debugging point me to a NULL pointer on the following instruction in line 25502 of elogd.c :
if (lbs->pwd_xml_tree) {
The work around was to name the global password file as the password file of one of the groups. |
68064
|
Tue Aug 4 13:18:26 2015 |
| Stefan Ritt | stefan.ritt@psi.ch | Bug report | Linux | 3.1.0-2 | Re: elogd crashes with a URL | I could not reproduce your problem. I can only fix it if I can reproduce it, so let's agree on a common test base. May I ask you to do the following:
- Download the most recent elog version from bitbucket and compile it
- Create two new logbooks "demo1" and "demo2" with minimal configuration, but using yor global password file which differs from the group ones
- Send me step-by-step instructions how to trigger the problem, including your elogd.cfg file and your password files (of course with fake accounts)
If I can reproduce the crash, I can fix it.
Jaime Duran wrote: |
URL causes elogd to crash when a global password file name doesn't match any group's password file name.
The offending URL is copied from the address field of the browser after sorting a logbook by on of the fileds.
After login out and using the copied URL, elogd shows the authentication dialog and then crashes after the credentials are submited.
Some debugging point me to a NULL pointer on the following instruction in line 25502 of elogd.c :
if (lbs->pwd_xml_tree) {
The work around was to name the global password file as the password file of one of the groups.
|
|
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
|
|
|
67859
|
Sun Apr 12 21:12:29 2015 |
| David Pilgram | David.Pilgram@epost.org.uk | Question | Linux | 3.1.0 c701 | Odd behaviour when attaching a file to an entry | Having installed v3.1.0 on a test logbook, I find that I can browse and select a file, but when I click on the "Upload" button, I get a pop-up message from the browser asking me:
"This page is asking you to confirm that you want to leave - data you have entered may not be saved."
The stay on page does nothing, the leave page option does what one expects from elog - that is the attachment thumbnail is generated etc.
I guess this is something to do with the drag and drop feature, but wondered if others have this issue or whether it may just be some mystery setting of the browser (firefox).
|
67863
|
Thu Apr 23 15:13:06 2015 |
| Stefan Ritt | stefan.ritt@psi.ch | Question | Linux | 3.1.0 c701 | Re: Odd behaviour when attaching a file to an entry | This problem has been fixed in Version 3.1.0-2. Please upgrade.
David Pilgram wrote: |
Having installed v3.1.0 on a test logbook, I find that I can browse and select a file, but when I click on the "Upload" button, I get a pop-up message from the browser asking me:
"This page is asking you to confirm that you want to leave - data you have entered may not be saved."
The stay on page does nothing, the leave page option does what one expects from elog - that is the attachment thumbnail is generated etc.
I guess this is something to do with the drag and drop feature, but wondered if others have this issue or whether it may just be some mystery setting of the browser (firefox).
|
|
67864
|
Thu Apr 23 15:37:37 2015 |
| David Pilgram | David.Pilgram@epost.org.uk | Question | Linux | 3.1.0 c701 | Re: Odd behaviour when attaching a file to an entry | Thanks Stefan, that did the trick.
Had a bit of an effort with the git repository, though, kept getting 403 errors when tried the
git clone https://bitbucket.org/ritt/elog as per the "download" page.
error: The requested URL returned error: 403 while accessing https://bitbucket.org/ritt/elog/info/refs
Stefan Ritt wrote: |
This problem has been fixed in Version 3.1.0-2. Please upgrade.
David Pilgram wrote: |
Having installed v3.1.0 on a test logbook, I find that I can browse and select a file, but when I click on the "Upload" button, I get a pop-up message from the browser asking me:
"This page is asking you to confirm that you want to leave - data you have entered may not be saved."
The stay on page does nothing, the leave page option does what one expects from elog - that is the attachment thumbnail is generated etc.
I guess this is something to do with the drag and drop feature, but wondered if others have this issue or whether it may just be some mystery setting of the browser (firefox).
|
|
|
|