ID |
Date |
Icon |
Author |
Author Email |
Category |
OS |
ELOG Version |
Subject |
67011
|
Mon Feb 7 15:14:36 2011 |
| Stefan Ritt | stefan.ritt@psi.ch | Bug report | Other | 2.9.0-2384 | Re: Odd bug with conditional and required attributes |
T. Ribbrock wrote: |
I just ran into an odd bug with conditional attributes: If I add a certain attribute to "Required Attributes", none of the conditionals will work anymore. I have tried to create a small logbook definition that will demonstrate the problem (the original logbook is more complex and uses two sets of conditionals, both of which will be disabled when the bug hits):
; General settings
Menu commands = List, New, Edit, Duplicate, Delete, Reply, Select, Move to, Download, Find, Logout, Help, Config,Admin
List Menu commands = New, Select, Find, Logout, Help, Config, Admin, Import, Download
Date Format = %d/%m/%Y
List conditions = 1
List display = Edit, Type, Created, StatusA, StatusB, Archived, Test Text, Public?
; Attributes
Attributes = Type, Created, StatusA, StatusB, Archived, Test Text, Public?
Required Attributes = Type
; Attribute Types
Type Created = date
Type Archived = date
; Options & Tooltips
Options Type = Type1{0}, Type2{1}
Options StatusA = Status-A-red, Status-A-orange, Status-A
Options StatusB = Status-B-red, Status-B-orange, Status-B
Options Public? = yes,no
; Conditionals
{0}Show Attributes Edit = Type, Created, StatusA, StatusB, Archived, Test Text, Public?
{1}Show Attributes Edit = Type, Created, StatusA, Archived, Test Text, Public?
The above logbook definition works. However, if I replace the Required Attributes = Type with Required Attributes = Type, Public?, the conditionals will no longer work. I can see the difference in the reactions of the browser - with the extra attribute, nothing happens when I change "Type". Without, the browser will spring into action and reload as soon as I change "Type". I've tested this with both Firefox 3.6.13 and Konqueror 4.4.5 on Kubuntu 10.04 as clients. Fortunately, this is not a showstopper for me, as it is not mandatory to have this attribute defined as required, but I find it a weird issue nonetheless.
Cheerio,
Thomas
P.S.: I'm currently running the latest SVN version of elogd on OPenBSD as I ran into the same problem as described in Message 66984. The above problem also happens with the 2.8.1 I was using before. Some feedback: The SVN version compiled and ran without any further intervention on OpenBSD - very nice!
|
Your problem is the "?" in the attribute Public?. Attributes may only contain ordinary characters. Unfortunately I did not document this so far. Therefore I put some fix in SVN revision 2387 which allows your attribute Public?, but I'm not 100% sure if this works in all places. The safest is just to remove the question mark. |
67013
|
Mon Feb 7 17:26:26 2011 |
| T. Ribbrock | emgaron+elog@ribbrock.org | Bug report | Other | 2.9.0-2384 | Re: Odd bug with conditional and required attributes |
Stefan Ritt wrote: |
Your problem is the "?" in the attribute Public?. Attributes may only contain ordinary characters. Unfortunately I did not document this so far. Therefore I put some fix in SVN revision 2387 which allows your attribute Public?, but I'm not 100% sure if this works in all places. The safest is just to remove the question mark.
|
Thanks Stefan, I'll try that. It's strange, though: At work, we're running 2.7.6 (and have used older versions in the past) and we have several logbooks with each at least one or two attributes with '?' and never had a problem with conditionals. Hence my surprise when this suddenly hit me with 2.8.1+ at home. Removing the '?' would be quite some work, as I'd have to change all logbooks and the associated data (the latter could probably be done with "rpl", I hope). I'll think about it. |
67102
|
Mon Aug 15 11:36:02 2011 |
| Kester Habermann | kester.habermann@gmail.com | Bug report | Other | 2.9.0 | SEGV after upgrade from 2.7.8 to 2.9.0 | Hello,
We've been using ELOG 2.6.5 to 2.7.8 for 4 years without any major problems.
Recently we upgraded to version 2.9.0 and since we've had the daemon frequently crash with SEGV.
I've detached debugging output from one time when ELOG the crashed. We've had many crashes
it was a different logbook each time. Platform is Solaris 10 5/08 on SPARC.
Has anyone else experienced problems with 2.9.0?
Best Regards
Kester
|
Attachment 1: elog-2.9.0-dbx.txt
|
signal SEGV (no mapping at the fault address) in show_elog_list at line 19781 in file "elogd.c"
19781 message_id = msg_list[index].lbs->el_index[msg_list[index].index].message_id;
(dbx)
(dbx) list
19781 message_id = msg_list[index].lbs->el_index[msg_list[index].index].message_id;
19782
19783 if (filtering) {
19784 status = el_retrieve(msg_list[index].lbs, message_id, date, attr_list, attrib, lbs->n_attr, text,
19785 &size, in_reply_to, reply_to, attachment, encoding, locked_by);
19786 if (status != EL_SUCCESS)
19787 break;
19788
19789 /* apply filter for attributes */
19790 for (i = 0; i < lbs->n_attr; i++) {
(dbx) print index
index = 0
(dbx) where
=>[1] show_elog_list(lbs = 0x1180200, past_n = 0, last_n = 0, page_n = 0, default_page = 1, info = (nil)), line 19781 in "elogd.c"
[2] interprete(lbook = 0xffbd89f8 "Galileo-Coord", path = 0xffbd8648 ""), line 27213 in "elogd.c"
[3] decode_get(logbook = 0xffbd89f8 "Galileo-Coord", string = 0xffbfe896 ""), line 27253 in "elogd.c"
[4] process_http_request(request = 0x13a4eb8 "GET /Galileo-Coord/", i_conn = 1), line 28001 in "elogd.c"
[5] server_loop(), line 28926 in "elogd.c"
[6] main(argc = 5, argv = 0xffbffb8c), line 29947 in "elogd.c"
(dbx) print n_msg
n_msg = 49
(dbx) print *msg_list
*msg_list = {
lbs = 0x1195dd0
index = 1667786092
string = "\001\017��-D"
number = 0
in_reply_to = 0
}
(dbx) print msg_list[index].lbs->el_index[msg_list[index].index].message_id
dbx: cannot access address 0x18da195b00
(dbx) print ms(dbx) [index].lbs->el_index[msg_list[index].index].message_id
(dbx) print msg_list[index].lbs
msg_list[index].lbs = 0x1195dd0
(dbx) print msg_list[index].lbs->el_index
msg_list[index].lbs->el_index = (nil)
(dbx) pr(dbx) g_list[index].lbs->el_index
(dbx) print *msg_list[index].lbs
*msg_list[index].lbs = {
name = ""
name_enc = ""
data_dir = ""
top_group = ""
el_index = (nil)
n_el_index = (nil)
n_attr = 0
pwd_xml_tree = (nil)
}
(dbx) print msg_list[1].lbs
msg_list[1].lbs = (nil)
(dbx) print msg_list[2].lbs
msg_list[2].lbs = (nil)
(dbx) print msg_list[3].lbs
msg_list[3].lbs = (nil)
(dbx) exit
|
67121
|
Fri Sep 9 12:54:13 2011 |
| Stefan Ritt | stefan.ritt@psi.ch | Info | Other | 2.9.0 | Expiration of ELOG forum accounts | Dear ELOG users,
the ELOG discussion forum at PSI contains in meantime many old accounts with non-functional email addresses. Since this causes some overhead, it has been decided to clean up the current account database. In order to keep your account alive, please log in at the above forum before Friday, Sept. 30th, 2011. If you fail to log in until that date, your account will be automatically deleted. Note that it will be always possible to re-create your account afterwards by simply clicking on "Register as new user", but before that you won't get automatic email notifications any more once your account has be deleted.
Sorry for the inconvenience, but the database contains currently too many wrong email addresses causing some flooding of our mail systems.
Best regards,
Stefan Ritt |
67917
|
Wed May 20 01:52:23 2015 |
| Konstantin Olchanski | olchansk@triumf.ca | Bug report | Other | this one | this elog errors sending email | this elog gives errors sending mail through PSI email server. (did not capture the error messages, sorry). K.O. |
67918
|
Wed May 20 01:54:55 2015 |
| Konstantin Olchanski | olchansk@triumf.ca | Bug report | Other | this one | edit somebody else's draft | this elog offers me to edit a draft message, then yells at me "only some other user can edit this draft!!!".
methinks I should only be offered to edit draft messages that I own or I can edit. K.O. |
67926
|
Wed May 20 22:12:49 2015 |
| David Pilgram | David.Pilgram@epost.org.uk | Bug report | Other | this one | Re: edit somebody else's draft | > this elog offers me to edit a draft message, then yells at me "only some other user can edit this draft!!!".
> methinks I should only be offered to edit draft messages that I own or I can edit. K.O.
I find it odd that I can see someone elses draft, but never one that I am in the middle of composing (using a
different tab of the browser) in the elog listing. There's one such draft Konstantin refers to in the logbook
listings now - last one was dark blue, this one a pink background, is there a reason for these different colours? |
67930
|
Fri May 22 13:50:31 2015 |
| Stefan Ritt | stefan.ritt@psi.ch | Bug report | Other | this one | Re: edit somebody else's draft | > > this elog offers me to edit a draft message, then yells at me "only some other user can edit this draft!!!".
> > methinks I should only be offered to edit draft messages that I own or I can edit. K.O.
> I find it odd that I can see someone elses draft, but never one that I am in the middle of composing (using a
> different tab of the browser) in the elog listing. There's one such draft Konstantin refers to in the logbook
> listings now - last one was dark blue, this one a pink background, is there a reason for these different colours?
I just tried that on the "Demo" logbook and could see my own draft entry (which appears pink) in a second tab.
Dark blue means you have not updated the default.css file properly from the current distribution.
Stefan |
|