Re: Sorting Museremail, posted by Steve Williamson on Thu Nov 20 10:29:39 2008
|
| Stefan Ritt wrote: |
|
| Steve Williamson wrote: |
|
However, the main reason for the request was that the I was so pleased with the ordering introduced in 2.7.5 but, as it is more normal for me to look down a list of names ordered by last-name/first-name than the other way about, I thought it worth asking if there was any way to do this sensibly. I appreciate that it isn't simple and what suits me may well not suit others - so thanks for taking time to consider the possibilities. I guess the only real solution is to define users differently, e.g. by structuring the name data into first name(s) and last name (not a global solution but would suit most of western europe and the USA at least!) but that is bound to have lots of impacts both on the application and on existing setups - so not really feasible, and probably not worth the disruption.
|
That's correct. Adding first name(s), last name(s) requires major modifications which are not se easy and I don't have time for that in the moment. So we'll keep it for the time being.
|
That's fine. Thanks for listenening - and for keeping on with elog
regards
Steve
|
Re: Special characters in attribute names, posted by Steve Williamson on Mon Nov 24 13:49:56 2008 
|
| Stefan Ritt wrote: |
|
| Steve Williamson wrote: |
|
Hi
Thanks for elog - it's a brilliant piece of software. I'd looked all over for open source software to log/manage change requests before discovering elog; it's so flexible that I've been able to do everything I need with it.
However, I think that I've just discovered my first undocumented 'feature'. Attribute names containing punctuation characters (e.g. / and :) cause "Redirection limit for this URL exceeded" errors in Firefox 3.0.2 and corrupt the URL if they're used in a Quick Filter. I often use '/' in attribute names for brevity, e.g. "Old/New Versions" but hadn't used one in a Quick Filter before.
|
Quick answer: Don't use '/' in attribute names ;-) but I guess you were kind of afraid to get this answer.
Somehow longer answer: I tried to reproduce your problem with following configuration:
[demo]
Attributes = Author, Type, Subject, Old/New
Options Old/New = Old, New
Quick filter = Type, Old/New
But I was not successful. Everything worked fine using ELOG V2.7.5-2137. Can you please check with the above configuration and tell me exactly when the redirection problem occurs? Is it during filtering on already on creating a new entry?
|
Thanks for the advice!
I've just had time to set up a test for this using both empty and populated logbooks (which don't have Hardware/Software in every entry as the field was added recently) and newly created logbooks (which have consistent attributes) and saw the problem on .
The control ("Hardware/Software") causing the problem has three options "Hardware Only", "Software Only" and "Both". The problem happens every time you click on the "-- Hardware/Software --" (i.e. All) option in the Quick Filter after having previously selected one (or more) of the options as a filter. This produces the error:
The page isn't redirecting properly
Firefox has detected that the server is redirecting the request for this address in a way that will never complete.
* This problem can sometimes be caused by disabling or refusing to accept cookies.
I ran elog with a trace (attached) which shows lots of:
select(1024, [5], NULL, NULL, {1, 0}) = 1 (in [5], left {1, 0})
recv(5, "GET /Change_Log/?Hardware%2FSoftware=_all_ HTTP/1.1\r\nHost: localhost:8080\r\nUser-"..., 100000, 0) = 619
stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=1323, ...}) = 0
time(NULL) = 1227528904
send(5, "HTTP/1.1 302 Found\r\nServer: ELOG HTTP 2.7.5-2130\r\nConnection: Keep-Alive\r\nKeep-A"..., 199, 0) = 199
send(5, "<html>redir</html>\r\n", 20, 0) = 20
messages after selecting "-- Hardware/Software --"
The only difference between today's test and last week's is that today the browser is on the local machine.
I also attach my (anonymised) elogd.cfg
Hope this helps
regards
Steve
|
Auto-increment attributes, posted by Steve Williamson on Wed Nov 26 10:00:25 2008
|
We have an auto-incrementing reference attribute defined as:
# RFC
Format RFC = 0,narrowattribname,narrowattribvalue,60,60
Preset RFC = RFC-######
Preset On Duplicate RFC = RFC-######
Tooltip RFC = A unique reference will be generated for this Request For Change
We also have a "Created by/when" attribute. Looking at the values this seems to be set when the user clicks "New" whereas the time stamp that appears on the line after the $@MID@$ seems to be set when the user clicks "Submit".
# Created
Format Created = 0,attribname,attribvalue,70,100
Preset Created = $long_name ($short_name) on $date
Preset On Duplicate Created = $long_name ($short_name) on $date
Every once in a while the incrementing stops working and the number 'sticks' or misses some out. It looks as if it might be because multiple people are adding entries concurrently. Could the occasion where there is a gap in the sequence (171-174) be where people abandoned changes (clicked on "Back") after having numbers allocated? Here is a list showing the discrepancies.
Date Item Time Stamp (from the line after $@MID@$) "Created" attribute time stamp
22/09/08 124 16:15:10 11:58
22/09/08 125 16:33:54 16:24
22/09/08 125 16:35:37 16:33 Should be 126
...
10/10/08 146 10:39:09 10:30 Correct
10/10/08 146 10:46:57 10:35 Should be 147
10/10/08 147 13:04:03 13:02 Should be 148
10/10/08 148 15:11:38 15:00 Should be 149
...
17/11/08 171 10:21 10:17 Correct
17/11/08 174 14:30 13:47 Should be 172
17/11/08 175 16:14 16:04 Should be 173
17/11/08 176 16:49 16:38 Should be 174
...
25/11/08 187 15:49:58 15:47 Correct
25/11/08 187 15:52:39 15:48 Should be 188
25/11/08 188 16:49:56 16:44 Should be 189
25/11/08 188 16:52:40 16:40 Should be 190
25/11/08 188 16:55:17 16:43 Should be 191
Let me know if you need any more information.
regards
Steve
|
|
Re: Special characters in attribute names, posted by Steve Williamson on Wed Nov 26 12:49:08 2008
|
| Stefan Ritt wrote: |
|
Thanks to your detailed description I could reproduce and fix the problem. Please download SVN revision #2144 and give it a try.
|
Tested SVN v 2147 and all looks OK
thanks
Steve |
|
Re: Auto-increment attributes, posted by Steve Williamson on Fri Dec 5 16:14:19 2008
|
| Steve Williamson wrote: |
|
We have an auto-incrementing reference attribute defined as:
# RFC
Format RFC = 0,narrowattribname,narrowattribvalue,60,60
Preset RFC = RFC-######
Preset On Duplicate RFC = RFC-######
Tooltip RFC = A unique reference will be generated for this Request For Change
We also have a "Created by/when" attribute. Looking at the values this seems to be set when the user clicks "New" whereas the time stamp that appears on the line after the $@MID@$ seems to be set when the user clicks "Submit".
# Created
Format Created = 0,attribname,attribvalue,70,100
Preset Created = $long_name ($short_name) on $date
Preset On Duplicate Created = $long_name ($short_name) on $date
Every once in a while the incrementing stops working and the number 'sticks' or misses some out. It looks as if it might be because multiple people are adding entries concurrently. Could the occasion where there is a gap in the sequence (171-174) be where people abandoned changes (clicked on "Back") after having numbers allocated? Here is a list showing the discrepancies.
Date Item Time Stamp (from the line after $@MID@$) "Created" attribute time stamp
22/09/08 124 16:15:10 11:58
22/09/08 125 16:33:54 16:24
22/09/08 125 16:35:37 16:33 Should be 126
...
10/10/08 146 10:39:09 10:30 Correct
10/10/08 146 10:46:57 10:35 Should be 147
10/10/08 147 13:04:03 13:02 Should be 148
10/10/08 148 15:11:38 15:00 Should be 149
...
17/11/08 171 10:21 10:17 Correct
17/11/08 174 14:30 13:47 Should be 172
17/11/08 175 16:14 16:04 Should be 173
17/11/08 176 16:49 16:38 Should be 174
...
25/11/08 187 15:49:58 15:47 Correct
25/11/08 187 15:52:39 15:48 Should be 188
25/11/08 188 16:49:56 16:44 Should be 189
25/11/08 188 16:52:40 16:40 Should be 190
25/11/08 188 16:55:17 16:43 Should be 191
Let me know if you need any more information.
regards
Steve
|
Hi
This is to let you know that the increment problem has just happened again.
Item 206 has timestamp (from the line after $@MID@$) of 11:59:45 and "created" attribute timestamp of 11:29
overlapping with this, a second item 206 has timestamp of 12:04:02 and "created" attribute of 11:53
So, both users were entering information between 11:53 and 11:59:45 and both picked up the same increment number.
There's no easy solution tho, is there? If you pick up the increment number at the start so it can be displayed on screen and ensure uniqueness then, if a user cancels a new entry you end up with "holes" in the sequence. If you pick it up at the end then you can't display it until the user presses submit.
regards
Steve |
|
Re: Auto-increment attributes, posted by Steve Williamson on Mon Dec 8 13:13:13 2008
|
| Stefan Ritt wrote: |
|
I finally found some time to address this problem. It is indeed related to the fact that the new number gets assigned when you click on 'New'. So if two people edit the new entries at the same time, they get assigned the same number. To fix this problem, I made the tag generation work with the 'Subst' command, which is evaluated at the entry submission, and not when you click on 'New'. So to make this work, you need to upgrade to SVN revision 2152 and then put into your configuration file:
Attributes = Author, RFC, Subject
Preset RFC = <will be assigned when you submit>
Preset on duplicate RFC = <will be assigned when you submit>
Locked attributes = RFC Subst RFC = RFC-######
I also changed the documentation accordingly.
|
Stefan
Thanks for fix - I've just tested it and it works beautifully.
regards
Steve
|
|
Attachments, posted by Steve Williamson on Fri Feb 6 12:08:49 2009
|
If I open an elog entry as read-only then attachments show as links which can be clicked to open the attachment. However, if I open an entry using Edit then attachments show as text with a delete button - I would expect to be able to read attachments when editing an entry but there may be some good reason for not being able to.
Also, on attachments, if I click on the attachment icon (paperclip) on the list page the URL encodes "/" as "%2f", e.g.
http://xxx.xxx.xxx.xxx:8080/Change_Log/..%2FChange_Log%2F090205_123135%2FCHANGE_CONTROL_NOTICE_050209.doc and I get the following error:
"Invalid URL: Change_Log/..%2FChange_Log%2F090205_123135%2FCHANGE_CONTROL_NOTICE_050209.doc" . If I then change all occurrences of "%2f" to "/" the link works.
We don't use attachments very often but occasionally they are just what you need - and so is elog!
great piece of software - many thanks for sharing it
Steve
|
|
Re: Attachments, posted by Steve Williamson on Tue Feb 17 12:28:19 2009
|
| Stefan Ritt wrote: |
|
| Steve Williamson wrote: |
|
Also, on attachments, if I click on the attachment icon (paperclip) on the list page the URL encodes "/" as "%2f", e.g.
http://xxx.xxx.xxx.xxx:8080/Change_Log/..%2FChange_Log%2F090205_123135%2FCHANGE_CONTROL_NOTICE_050209.doc and I get the following error:
"Invalid URL: Change_Log/..%2FChange_Log%2F090205_123135%2FCHANGE_CONTROL_NOTICE_050209.doc" . If I then change all occurrences of "%2f" to "/" the link works.
|
You have an old version of elog, this bug has been fixed some time ago. Have a look for example at https://midas.psi.ch/elogs/Linux+Demo/.
If you click on a peperclip there, the attachment is shown correctly.
|
Thanks - just downloaded and compiled the latest version and all is well |
|