ID |
Date |
Icon |
Author |
Author Email |
Category |
OS |
ELOG Version |
Subject |
68332
|
Thu Jun 9 04:29:14 2016 |
| rudy | sylpid2007@gmail.com | Bug report | Windows | 3.113 | Re: Self register = 0 not working , | Hi Andreas,
Thanks for your help. I will try to do that and if I found how to fix this problems, I will post it at here again.
Andreas Luedeke wrote: |
Aparently I've missed that one :-)
In order to test your problem it would be useful to have a minimal config file to reproduce the problem. Yours does not include any actual logbook, only [global *] sections.
Andreas
rudy wrote: |
Hi Andreas
I'm following the instruction from https://midas.psi.ch/elog/config.html#groups , please scroll to the Top Groups
Group Linux PCs = Red Hat, Debian, Mandrake
Group Windows PCs = 98, ME, NT, XP, CE
Group CE = 1.0, 2.UL
Top group engineering = Linux PCs, Windows PCs
Top group administration = Employees, Purchases
[global engineering]
Password file = engineers.pwd
Admin user = stefan
[global administration]
Password file = admin.pwd
Admin user = bill
Andreas Luedeke wrote: |
It would be new to me if elog would support independent [global] sections for each logbook.
I thought you can only have one [global] section. Whatever is defined in that section will be valid for all logbooks.
If you need to have different user files, you'll need to run different elogd services with independent config files (and Password files).
Andreas
rudy wrote: |
I have Split Elog to Two Top Group [Check the Config Below].
Problem =
After Staff01 login successfully to http://127.0.0.1/Staff and if he/she fill the url http://127.0.0.1/Administrator and choose any elog topic, it will direct registration form.
[global]
port = 8080
Self register = 0
Show top groups = 1
Preset Author = $long_name
Locked Attributes = Author
Restrict edit = 1
Top group Staff = Website, Notes
Top group Administrator = Website Update, Admin Notes, Ticketing
[global Staff]
Menu commands = List, New, Edit, Reply, Duplicate, Find, Config
Password file = staff.pwd
Admin user = sylpid
Login user = staff01
[global Administrator]
Password file = admin.pwd
Admin user = sylpid
Login user = admin01
|
|
|
|
|
67885
|
Wed May 6 17:35:14 2015 |
| Bruce Bush | bruce_bush@sil.org | Bug report | Linux | 3.10.2 | Path disclosure on unfound file | Greetings,
Running elog 3.1.0 on CentOS 6.6. When I try to access a nonexistent file, elog reveals a path in the 404 page. For example:
Not Found
The requested file /usr/local/elog/themes/default/blortblortblort7854.htm was not found on this server
ELOG version 3.1.0
Is there any way to use a custom 404 page with elog, or to make it stop displaying the file information?
Thank you,
bb
|
67992
|
Wed Jun 10 09:12:06 2015 |
| Stefan Ritt | stefan.ritt@psi.ch | Bug report | Linux | 3.10.2 | Re: Path disclosure on unfound file | What URL did you use? If I try here on this forum I get:

which looks fine to me.
Bruce Bush wrote: |
Greetings,
Running elog 3.1.0 on CentOS 6.6. When I try to access a nonexistent file, elog reveals a path in the 404 page. For example:
Not Found
The requested file /usr/local/elog/themes/default/blortblortblort7854.htm was not found on this server
ELOG version 3.1.0
Is there any way to use a custom 404 page with elog, or to make it stop displaying the file information?
Thank you,
bb
|
|
69859
|
Mon Dec 16 15:26:26 2024 |
| Víctor M. Nouvilas | vmnouvilas@ucm.es | Bug report | Linux | 3.1.5-fc6679b | Author special characters changed when saving as draft | Hello, I have installed ELOG in an Ubuntu 22.04 machine and is working great, but I have found a small bug with Author names.
I have the config set like this for the Author attribute:
Preset Author = $long_name
Locked Attributes = Author
For context, my name is Víctor, which includes the accented "í". When creating a new entry and submitting immediately seems to work well. However, if I create a new entry, save it as draft, go back to the list, and then go to the draft entry, the accented "í" has transformed into "Ã". If I repeat the process, it turns into "ÃÂ", and so on. As I have configured the Author to not be editable, the user cannot fix this manually.
I found a way around this bug by setting
Subst Author = $long_name
Which is okay for us, but might not be for everyone.
In fact I saved this entry as a draft and then on another tab tried to edit it and it wouldn't let me edit because the author name now did not match. |
69752
|
Thu Mar 7 08:55:49 2024 |
| Andreas Warburton | andreas.warburton@mcgill.ca | Bug report | Mac OSX | 3.1.5-23df00d9 | Runaway bogus attachment counts in Summary view attachment column | On a new MacBook Pro (Silicon M3), I installed version 3.1.5 build 23df00d9. The application appears to work normally, except that, after a short while, the indicated attachment count (paperclips in the attachment column of the Summary view) starts to increment fairly rapidly with each time that I visit the page. Attachment counts appear even for records that don't have any attachments. When I access records individually, either those with or without real attachments, everything looks OK. Any insights as to what might be causing this, and how to correct?
Installation went smoothly using the (now longstanding) MacOS installation instructions, with one small exception: When doing the "sudo launchctl load ..." step, there is occasionally an I/O error of some kind. (Sorry, I don't have an exact transcript of the error at the moment, but it appears to refer to line 5 of a script.)
Many thanks,
Andreas W. |
69755
|
Sat Mar 9 17:04:13 2024 |
| Andreas Warburton | andreas.warburton@mcgill.ca | Bug report | Mac OSX | 3.1.5-23df00d9 | Re: Runaway bogus attachment counts in Summary view attachment column | A quick follow-up concerning the secondary matter I mentioned in my last post, namely the issues I had with the deprecated "sudo launchctl load ..." and "sudo launchctl unload ..." subcommands currently provided in the ELOG installation instructions for MacOS. I found a solution to this -- will post it in a separate thread.
The strangely auto-incrementing attachment counts in the Summary view are still present, and I'm curious if anyone else has experienced those. Also, I could not find a way to customize the Summary view such that the final (rightmost) column with the attachment counts can be suppressed. That would at least put the problem out of sight until a developer can intervene and fix the bug.
Andreas Warburton wrote: |
On a new MacBook Pro (Silicon M3), I installed version 3.1.5 build 23df00d9. The application appears to work normally, except that, after a short while, the indicated attachment count (paperclips in the attachment column of the Summary view) starts to increment fairly rapidly with each time that I visit the page. Attachment counts appear even for records that don't have any attachments. When I access records individually, either those with or without real attachments, everything looks OK. Any insights as to what might be causing this, and how to correct?
Installation went smoothly using the (now longstanding) MacOS installation instructions, with one small exception: When doing the "sudo launchctl load ..." step, there is occasionally an I/O error of some kind. (Sorry, I don't have an exact transcript of the error at the moment, but it appears to refer to line 5 of a script.)
Many thanks,
Andreas W.
|
|
69756
|
Sat Mar 9 17:14:09 2024 |
| Stefan Ritt | stefan.ritt@psi.ch | Bug report | Mac OSX | 3.1.5-23df00d9 | Re: Runaway bogus attachment counts in Summary view attachment column | I'm traveling right now and will only next week be able to look into that, so please be patient for a few more days.
Stefan |
69761
|
Thu Mar 14 21:21:33 2024 |
| Stefan Ritt | stefan.ritt@psi.ch | Bug report | Mac OSX | 3.1.5-23df00d9 | Re: Runaway bogus attachment counts in Summary view attachment column | The problem with the attachment paperclips has been fixed in the current version.
Stefan
Andreas Warburton wrote: |
On a new MacBook Pro (Silicon M3), I installed version 3.1.5 build 23df00d9. The application appears to work normally, except that, after a short while, the indicated attachment count (paperclips in the attachment column of the Summary view) starts to increment fairly rapidly with each time that I visit the page. Attachment counts appear even for records that don't have any attachments. When I access records individually, either those with or without real attachments, everything looks OK. Any insights as to what might be causing this, and how to correct?
|
|
|