| ID |
Date |
Icon |
Author |
Author Email |
Category |
OS |
ELOG Version |
Subject |
|
1421
|
Fri Sep 23 19:23:26 2005 |
 | Dan Chitwood | dchitwoo@uiuc.edu | Bug report | Linux | Windows | 2.6.0-b4 | Post appearing twice | | We are having trouble on our logbook with posts appearing twice. Both posts contain the same ID number, time, etc. This most often occurs when the e-log entry is being written for an extended period of time (ie. more than 30 minutes), but I don't know if that is the root cause of the problem. It may also be related to posts that are edited after an initial posting. Could this be due to an improper setting in our config file? |
|
1427
|
Wed Oct 5 13:22:08 2005 |
 | Stefan Ritt | stefan.ritt@psi.ch | Bug report | Linux | Windows | 2.6.0-b4 | Re: Post appearing twice |
| Dan Chitwood wrote: | | We are having trouble on our logbook with posts appearing twice. Both posts contain the same ID number, time, etc. This most often occurs when the e-log entry is being written for an extended period of time (ie. more than 30 minutes), but I don't know if that is the root cause of the problem. It may also be related to posts that are edited after an initial posting. Could this be due to an improper setting in our config file? |
Besides the trivial case that people hit the submit button twice I can only imagine one possible cause: If you edit an existing entry, there is a button Resubmit as new entry at the bottom. If that button is checked, the old entry gets deleted and a new one gets submitted. If the delete of the old entry fails for some reason, you could maybe get two entries.
May I suggest following: Use a very simple config file (like the demo one from the distribution) and see if you can reproduce the problem. If not, add you config options one by one to the config file, and see at which option the problem starts. This way you might find the cause of it.
Your problem has not been reported by anybody else so far, so chances are high that it's related to a config setting. |
|
2240
|
Mon Jun 4 22:30:44 2007 |
| Alan Grant | netman311@mts.net | Bug report | Linux | Windows | 2.6.0-b4 | Re: Post appearing twice |
| Stefan Ritt wrote: |
| Dan Chitwood wrote: | | We are having trouble on our logbook with posts appearing twice. Both posts contain the same ID number, time, etc. This most often occurs when the e-log entry is being written for an extended period of time (ie. more than 30 minutes), but I don't know if that is the root cause of the problem. It may also be related to posts that are edited after an initial posting. Could this be due to an improper setting in our config file? |
Besides the trivial case that people hit the submit button twice I can only imagine one possible cause: If you edit an existing entry, there is a button Resubmit as new entry at the bottom. If that button is checked, the old entry gets deleted and a new one gets submitted. If the delete of the old entry fails for some reason, you could maybe get two entries.
May I suggest following: Use a very simple config file (like the demo one from the distribution) and see if you can reproduce the problem. If not, add you config options one by one to the config file, and see at which option the problem starts. This way you might find the cause of it.
Your problem has not been reported by anybody else so far, so chances are high that it's related to a config setting. |
I was having a very similar problem. After clicking Submit, I was getting dialog box "Submit modified Elog entry?" (with Submit or Cancel options) even though it was a new entry. Whenever I clicked Submit, it added two identical lines (except for ID), but when I clicked Cancel, it added only one entry. This happened in both v2.6.3 and v2.6.5. I eventually deduced it down to the Required Attributes line in the cfg file. I removed almost all other lines and then started removing each required attribute until the field was identified. For some reason it didn't like field name called "Date/Time Reproted" and when I removed it, it added fine, although that one field had to be unrequired when it really should have been req'd. I didn't see anything in the cfg instuctions regarding the use of "/" (unless I missed it) but I assumed it has something to do with that "/". It's interesting to note however that fields by same name under other tabs work fine. It may be bug related. |
|
2241
|
Fri Jun 8 10:44:14 2007 |
| Stefan Ritt | stefan.ritt@psi.ch | Bug report | Linux | Windows | 2.6.0-b4 | Re: Post appearing twice |
| Alan Grant wrote: | | I was having a very similar problem. After clicking Submit, I was getting dialog box "Submit modified Elog entry?" (with Submit or Cancel options) even though it was a new entry. Whenever I clicked Submit, it added two identical lines (except for ID), but when I clicked Cancel, it added only one entry. This happened in both v2.6.3 and v2.6.5. |
Can you try to reproduce your problem with a minimal configuration file and send it to me? |
|
2243
|
Tue Jun 12 17:13:28 2007 |
| Stefan Ritt | stefan.ritt@psi.ch | Bug report | Linux | Windows | 2.6.0-b4 | Re: Post appearing twice | I finally found and fixed the problem with the help of Alan Grant. It happens when three things are used together:
- Locking (via use lock = 1)
- Attributes containing '/' characters
- Required attributes are used with attributes containing '/'
The '/' in the attribute crashes actually the JavaScript code for checking the required attributes and thus you have two submissions.
The bug is fixed in SVN revision 1866 and will be contained in the next release. |
|
1379
|
Fri Aug 5 02:27:15 2005 |
| Chris Green | greenc@fnal.gov | Bug report | Linux | 2.6.0-CVS | Top Groups, Show Top Groups, password file and Protect Selection page have nasty interaction | Hi,
Just as our ELOG went into production, I tripped over a couple of related (I think) bugs.
First, the easy one: line 21368 of src/elogd.c has a compile warning which looks non-benign. I fixed it in my local copy with:
Index: elogd.c
===================================================================
RCS file: /usr/local/cvsroot/elog/src/elogd.c,v
retrieving revision 1.739
diff -r1.739 elogd.c
21368,21369c21368
< sprintf(str, "?fail=1", user);
< redirect(lbs, str);
---
> redirect(lbs, "?fail=1");
Regardless (ie if I use the original CVS code or the patched version), a hard-to trace problem occurs with my configuration whereby users are denied access after password entry at the logbook selection page (even when details are verifiably correct), and users are dropped through to the next (non-protected) Top Group page. This problem goes away if "Protect Selection Page" is turned off.
A kind of "shadow" of this problem occurs if you create a new logbook from the Change Config File page, whereby after creating the new logbook one is dropped through to the next Top Group's selection page after saving the configuration (and the url has ?fail=1 added to it, althoguh line 21368 above is hardly the only place where this could have occurred).
I think all these things are linked. I'd be grateful if you could review this section of this code for possible causes of these problems. While we can operate for now with non-logged-in users able to see our list of logbooks, that is not something we want for the long term.
Thanks for your help,
Chris. |
|
1385
|
Fri Aug 5 12:06:47 2005 |
| Stefan Ritt | stefan.ritt@psi.ch | Bug report | Linux | 2.6.0-CVS | Re: Top Groups, Show Top Groups, password file and Protect Selection page have nasty interaction |
| Chris Green wrote: | Index: elogd.c
===================================================================
RCS file: /usr/local/cvsroot/elog/src/elogd.c,v
retrieving revision 1.739
diff -r1.739 elogd.c
21368,21369c21368
< sprintf(str, "?fail=1", user);
< redirect(lbs, str);
---
> redirect(lbs, "?fail=1");
|
Thanks, applied.
| Chris Green wrote: | | Regardless (ie if I use the original CVS code or the patched version), a hard-to trace problem occurs with my configuration whereby users are denied access after password entry at the logbook selection page (even when details are verifiably correct), and users are dropped through to the next (non-protected) Top Group page. This problem goes away if "Protect Selection Page" is turned off. |
I hope I have fixed this problem, at least it works ok here when I tried with your config file.
One note I would like to make however: "Top groups" were invented for having completely separate logbook groups. Before the invention of top groups, one had to run several instances of elogd for different departments for example, where one department should not see the other department's logbooks. But having many departments means having to maintain many elogd daemons. This led to the invention of top groups, so one daemon can serve several independent groups, each having their own [global] section, with probably their own administrator.
In your case however, it would be more applicable not to use top groups, but use nested groups. Like
Group MiniBooNE = Analysis, Miscellaneous
Group Analysis = Charged Current Pi Plus, Neutral Current Coherent Pions
Group Miscellaneous = demo
I presume this is more what you want, and you can avoid some problems which arise from top groups.
| Chris Green wrote: | | A kind of "shadow" of this problem occurs if you create a new logbook from the Change Config File page, whereby after creating the new logbook one is dropped through to the next Top Group's selection page after saving the configuration (and the url has ?fail=1 added to it, althoguh line 21368 above is hardly the only place where this could have occurred). |
I have not tested this one, but it could well be that the modification I made also fixes this. |
|
1388
|
Fri Aug 5 16:15:04 2005 |
 | Chris Green | greenc@fnal.gov | Bug report | Linux | 2.6.0-CVS | Re: Top Groups, Show Top Groups, password file and Protect Selection page have nasty interaction |
| Stefan Ritt wrote: | One note I would like to make however: "Top groups" were invented for having completely separate logbook groups. Before the invention of top groups, one had to run several instances of elogd for different departments for example, where one department should not see the other department's logbooks. But having many departments means having to maintain many elogd daemons. This led to the invention of top groups, so one daemon can serve several independent groups, each having their own [global] section, with probably their own administrator.
In your case however, it would be more applicable not to use top groups, but use nested groups. Like
Group MiniBooNE = Analysis, Miscellaneous
Group Analysis = Charged Current Pi Plus, Neutral Current Coherent Pions
Group Miscellaneous = demo
I presume this is more what you want, and you can avoid some problems which arise from top groups.
|
The quick attempt I just made to use this doesn't do what I want, which is to require password protection for the Analysis logbook selection page. If you think that *is* possible and I just didn't configure it properly, I'd appreciate pointers. In the meantime though, your bug fixes appear to have solved my top group / password problem and I think I'll proceed with that for now.
Thanks again,
Chris. |
|