Re: alphabetize Quick Filter items?, posted by Stefan Ritt on Tue Jun 8 09:53:09 2010
|
| Dennis Seitz wrote: |
|
| Stefan Ritt wrote: |
|
| Dennis Seitz wrote: |
|
| Stefan Ritt wrote: |
|
| Dennis Seitz wrote: |
|
Hi Stefan,
I'd like to request a feature: automatic alphabetization of the items in the Quick Filter menus.
We track quite a few detector assemblies, which are produced with non-sequential designations. It would be useful if the Quick Filter list was automatically sorted alphabetically to make it more convenient for folks to find a particular item.
I know people can always search by designation but it would be handy to have this alpha sorting feature. Would it be possible to include that in a future release?
Thanks again for a *very* useful logging system!
Dennis
|
The order of items in a Quick Filter menu is exactly as in the configuration file. Like if you have items
Options Type = C, D, A, B
they are shown like that in the quick filter menu. If you want to sort them, just do the sorting yourself in the configuration file like
Options Type = A, B, C, D
I have not implemented automatic sorting since some people want a different order, like some main topics at top. So by following the order from the configuration file, everybody can be satisfied just by chaning the order in the config file.
- Stefan
|
Yes, I have been manually sorting and resorting. We have extendable attributes and the list keeps growing so I have to resort every so often. I thought perhaps a simple alphanumeric sort as an option would be popular with most users so I thought I'd ask for it. It would really simplify things for me. Users who want to sort manually could do so by disabling the option. It never hurts to ask!
|
Ok, I implemented
Sort attribute options = 1
in the current SVN revision.
|
I've tried adding this statement to my cfg file but the attributes are still unsorted in the QuickFilter menus. Was this implemented in 2.7.7?
Shouldn't an existing configuration file entry like
Options Type = C, D, A, B
be sorted in the QuickFilter menu as A B C D?
|
You need revision 2252 or later. So you have to upgrade to 2.7.8. |
|
Re: alphabetize Quick Filter items?, posted by Dennis Seitz on Wed Jul 28 17:01:06 2010
|
| Stefan Ritt wrote: |
|
| Dennis Seitz wrote: |
|
| Stefan Ritt wrote: |
|
| Dennis Seitz wrote: |
|
| Stefan Ritt wrote: |
|
| Dennis Seitz wrote: |
|
Hi Stefan,
I'd like to request a feature: automatic alphabetization of the items in the Quick Filter menus.
We track quite a few detector assemblies, which are produced with non-sequential designations. It would be useful if the Quick Filter list was automatically sorted alphabetically to make it more convenient for folks to find a particular item.
I know people can always search by designation but it would be handy to have this alpha sorting feature. Would it be possible to include that in a future release?
Thanks again for a *very* useful logging system!
Dennis
|
The order of items in a Quick Filter menu is exactly as in the configuration file. Like if you have items
Options Type = C, D, A, B
they are shown like that in the quick filter menu. If you want to sort them, just do the sorting yourself in the configuration file like
Options Type = A, B, C, D
I have not implemented automatic sorting since some people want a different order, like some main topics at top. So by following the order from the configuration file, everybody can be satisfied just by chaning the order in the config file.
- Stefan
|
Yes, I have been manually sorting and resorting. We have extendable attributes and the list keeps growing so I have to resort every so often. I thought perhaps a simple alphanumeric sort as an option would be popular with most users so I thought I'd ask for it. It would really simplify things for me. Users who want to sort manually could do so by disabling the option. It never hurts to ask!
|
Ok, I implemented
Sort attribute options = 1
in the current SVN revision.
|
I've tried adding this statement to my cfg file but the attributes are still unsorted in the QuickFilter menus. Was this implemented in 2.7.7?
Shouldn't an existing configuration file entry like
Options Type = C, D, A, B
be sorted in the QuickFilter menu as A B C D?
|
You need revision 2252 or later. So you have to upgrade to 2.7.8.
|
We have upgraded to 2.7.8 but this still doesn't seem to work. The quick menus are still unsorted. Does it work for you? |
|
Re: alphabetize Quick Filter items?, posted by Stefan Ritt on Wed Jul 28 17:15:33 2010
|
| Dennis Seitz wrote: |
|
| Stefan Ritt wrote: |
|
| Dennis Seitz wrote: |
|
| |
|
Ok, I implemented
Sort attribute options = 1
in the current SVN revision.
|
I've tried adding this statement to my cfg file but the attributes are still unsorted in the QuickFilter menus. Was this implemented in 2.7.7?
Shouldn't an existing configuration file entry like
Options Type = C, D, A, B
be sorted in the QuickFilter menu as A B C D?
|
You need revision 2252 or later. So you have to upgrade to 2.7.8.
|
We have upgraded to 2.7.8 but this still doesn't seem to work. The quick menus are still unsorted. Does it work for you?
|
Sorry, there was a typo, you need
Sort attribute options <attribute> = 1
where <attribute> is the name of the attribute to be sorted (in case you want some attributes sorted, but not all). |
|
Re: alphabetize Quick Filter items?, posted by Dennis Seitz on Wed Jul 28 22:03:26 2010
|
| Stefan Ritt wrote: |
|
| Dennis Seitz wrote: |
|
| Stefan Ritt wrote: |
|
| Dennis Seitz wrote: |
|
| |
|
Ok, I implemented
Sort attribute options = 1
in the current SVN revision.
|
I've tried adding this statement to my cfg file but the attributes are still unsorted in the QuickFilter menus. Was this implemented in 2.7.7?
Shouldn't an existing configuration file entry like
Options Type = C, D, A, B
be sorted in the QuickFilter menu as A B C D?
|
You need revision 2252 or later. So you have to upgrade to 2.7.8.
|
We have upgraded to 2.7.8 but this still doesn't seem to work. The quick menus are still unsorted. Does it work for you?
|
Sorry, there was a typo, you need
Sort attribute options <attribute> = 1
where <attribute> is the name of the attribute to be sorted (in case you want some attributes sorted, but not all).
|
That did the trick. That was a good idea, to give us the option of which attributes to sort, too. Thanks again for adding this feature! |
Crashes when editing entries, posted by T. Ribbrock on Wed Jul 22 12:12:37 2009
|
For some odd reasons, we are experiencing frequent crashes of elogd over the past few days. It has been working fine so far, but more or less out of the blue it became rather unreliable. The current configuration is installed on two servers, one running 2.7.5.-r2174 on ClarkConnect 4 and one running 2.7.6-r2233 on Debian 4.0 - both show the same problem. Each of them has an "active" group with four logbooks and an "archive" group with three logbooks. In the "active" group, there are two logbooks that share the same index (using Subdir=...) and it looks like the crashes occur most of the time in these, though that's just a hunch so far. Also, most of the crashes seem to happen when submitting an entry that has been edited. Actually, submitting a modified entry has always been strange in our logbooks: When we hit submit, we get a pop-up window asking "Submit modified entry?". When choosing "OK", the entry that has been edited is duplicated. When choosing "Cancel", it is submitted correctly.
I've been running elogd like this (to get more info)
elogd -v > elog-2233-2.log 2>&1
The last entry I get in the log when elogd crashes is:
Same index as logbook Machine Log
elogd: src/elogd.c:727: xfree: Assertion `*((unsigned int *) (temp - 4)) == 0xdeadc0de' failed.
Received unknown cookie "wikidb_mw__session"
Received unknown cookie "wikidb_mw__session"
I did actually make a few changes to the configuration before we noticed the crashes: I added one extra attribute and a few more conditionals.
Any additional information you need: Just let me know.
Regards,
Thomas |
|
Re: Crashes when editing entries, posted by T. Ribbrock on Wed Jul 22 12:15:56 2009
|
| T. Ribbrock wrote: |
|
For some odd reasons, we are experiencing frequent crashes of elogd over the past few days. It has been working fine so far, but more or less out of the blue it became rather unreliable. The current configuration is installed on two servers, one running 2.7.5.-r2174 on ClarkConnect 4 and one running 2.7.6-r2233 on Debian 4.0 - both show the same problem. Each of them has an "active" group with four logbooks and an "archive" group with three logbooks. In the "active" group, there are two logbooks that share the same index (using Subdir=...) and it looks like the crashes occur most of the time in these, though that's just a hunch so far. Also, most of the crashes seem to happen when submitting an entry that has been edited. Actually, submitting a modified entry has always been strange in our logbooks: When we hit submit, we get a pop-up window asking "Submit modified entry?". When choosing "OK", the entry that has been edited is duplicated. When choosing "Cancel", it is submitted correctly.
I've been running elogd like this (to get more info)
elogd -v > elog-2233-2.log 2>&1
The last entry I get in the log when elogd crashes is:
Same index as logbook Machine Log
elogd: src/elogd.c:727: xfree: Assertion `*((unsigned int *) (temp - 4)) == 0xdeadc0de' failed.
Received unknown cookie "wikidb_mw__session"
Received unknown cookie "wikidb_mw__session"
I did actually make a few changes to the configuration before we noticed the crashes: I added one extra attribute and a few more conditionals.
Any additional information you need: Just let me know.
Regards,
Thomas
|
Forgot to mention: I've also seen error messages like this upon a crash:
*** glibc detected *** corrupted double-linked list: 0x0911bbc0 ***
Regards,
Thomas |
|
Re: Crashes when editing entries, posted by Stefan Ritt on Wed Jul 22 12:46:36 2009
|
| T. Ribbrock wrote: |
|
For some odd reasons, we are experiencing frequent crashes of elogd over the past few days. It has been working fine so far, but more or less out of the blue it became rather unreliable. The current configuration is installed on two servers, one running 2.7.5.-r2174 on ClarkConnect 4 and one running 2.7.6-r2233 on Debian 4.0 - both show the same problem. Each of them has an "active" group with four logbooks and an "archive" group with three logbooks. In the "active" group, there are two logbooks that share the same index (using Subdir=...) and it looks like the crashes occur most of the time in these, though that's just a hunch so far. Also, most of the crashes seem to happen when submitting an entry that has been edited. Actually, submitting a modified entry has always been strange in our logbooks: When we hit submit, we get a pop-up window asking "Submit modified entry?". When choosing "OK", the entry that has been edited is duplicated. When choosing "Cancel", it is submitted correctly.
I've been running elogd like this (to get more info)
elogd -v > elog-2233-2.log 2>&1
The last entry I get in the log when elogd crashes is:
Same index as logbook Machine Log
elogd: src/elogd.c:727: xfree: Assertion `*((unsigned int *) (temp - 4)) == 0xdeadc0de' failed.
Received unknown cookie "wikidb_mw__session"
Received unknown cookie "wikidb_mw__session"
I did actually make a few changes to the configuration before we noticed the crashes: I added one extra attribute and a few more conditionals.
Any additional information you need: Just let me know.
|
well, I need to reproduce your problem in order to fix it. The failed assertation you get is due to some internal writing beyond array boundaries, but I have no clue which part of the code makes this. It might be related to the fact that you use the same index (via Subdir=...) for two logbooks. In this scenario, you are only allowed to modify/add entries to one logbook, not the other. The other one may only be used for reading. And even then it's not guaranteed that new entries show up in the second logbook immediately, you might have to restart the server in order to re-index the logbooks. Internally, the daemon does not know that two logbooks are "the same" and one instance will not realize if the other instance modifies the data "below its feet". Can you try to give up the double logbooks and see if the problem goes away? |
|
Re: Crashes when editing entries, posted by T. Ribbrock on Wed Jul 22 15:35:57 2009
|
| Stefan Ritt wrote: |
|
well, I need to reproduce your problem in order to fix it. The failed assertation you get is due to some internal writing beyond array boundaries, but I have no clue which part of the code makes this. It might be related to the fact that you use the same index (via Subdir=...) for two logbooks. In this scenario, you are only allowed to modify/add entries to one logbook, not the other. The other one may only be used for reading. And even then it's not guaranteed that new entries show up in the second logbook immediately, you might have to restart the server in order to re-index the logbooks. Internally, the daemon does not know that two logbooks are "the same" and one instance will not realize if the other instance modifies the data "below its feet". Can you try to give up the double logbooks and see if the problem goes away?
|
Hm... I have implemented this set-up originally based on this: https://midas.psi.ch/elogs/Forum/66024. The "double logbook" is a machine log with a "software" (OS installations etc.) and a "hardware" (CPU, RAM, etc.) view. The "hardware" view has the "Subdir=" statement. Thinking about it, the "software" view is used most - I have several automatic scripts running which update the contents whenever a machine gets updated, re-installed and so on. The hardware part does not see much editing - until this week, when we decided to start an inventory... So, it's quite possible that we never noticed that this was iffy. For the rest of our goals, this set-up has worked fantastically - never noticed any problem with one view not updating, actually. Also, I do not remember any crashes with the other, single logbooks.
What I've done for now is to ask all team members to use only the software part (the one without the Subdir statement) to actually change content (the entry masks are the same in both versions) and use the hardware part just for viewing. I'll report back as soon as I get some feedback.
Nonetheless, given that this set-up has been a great help for us - if you ever get the chance to make this work (even) better, I'd be most grateful.
Regards,
Thomas |
|