Timstamp button in ckedit inserts an incorrect string ( elogd 3.1.0-2), posted by David Wallis on Thu May 28 17:28:20 2015
|
I just updated to the latest official release (V3.1.0-2411f95) and have this problem:
The Time Stamp button pastes the logbook name when "Time format" is not specified in elogd.cfg, and when it is set to "%m/%d/%Y %H:%M", it adds the string "5/28/."
My users are loving the new functionality added in 3.1! |
ELOG Forum: drafts cannot be deleted, posted by Andreas Luedeke on Fri May 29 09:46:11 2015
|
I wanted to reply to the post "Three problems..." and then changed my mind.
But since this logbook does not allow to delete entries (not even my own) I was neither able to remove the draft
nor the final entry.
Another strange thing: the draft got submitted when I hit the "Back" button after reopening it.
Cheers
Andreas |
ELOG Forum: drafts cannot be deleted, posted by Stefan Ritt on Tue Jun 9 17:09:22 2015
|
> Another strange thing: the draft got submitted when I hit the "Back" button after reopening it.
Well, this is a problem indeed. When edit entries now, drafts gets saved regularly, overwriting your original entry. This is a limitation of the elog database, which cannot do full versioning. So "Back" is actually the same as "Commit without email notification". Or better "Commit some ten seconds ago". Now I
don't know what the best solution is. I'm tempted to just remove the "Back" button and replace it with a "Delete" button. So people can either submit an entry or delete it completely. Any thoughts? |
ELOG Forum: drafts cannot be deleted, posted by Andreas Luedeke on Wed Jun 10 10:43:02 2015
|
> > Another strange thing: the draft got submitted when I hit the "Back" button after reopening it.
>
> Well, this is a problem indeed. When edit entries now, drafts gets saved regularly, overwriting your original entry.
> This is a limitation of the elog database, which cannot do full versioning.
> So "Back" is actually the same as "Commit without email notification". Or better "Commit some ten seconds ago".
> Now I don't know what the best solution is.
> I'm tempted to just remove the "Back" button and replace it with a "Delete" button.
> So people can either submit an entry or delete it completely. Any thoughts?
I think it would be nice to have three options:
- "Submit": making the draft entry a "real" entry, with an ID
- "Abort": keeping the entry as a draft entry as it currently is (or was 10 sec ago)
- "Delete": removing the draft entry.
I understand that the draft is overwritten currently by the "Back" button, but why does it get an ID and does not stay as a "Draft"?
As a quick fix you may skip the "Abort" for now and just provide "Submit" and "Delete". |
ELOG Forum: drafts cannot be deleted, posted by Stefan Ritt on Wed Jun 10 10:55:00 2015
|
> I think it would be nice to have three options:
> - "Submit": making the draft entry a "real" entry, with an ID
> - "Abort": keeping the entry as a draft entry as it currently is (or was 10 sec ago)
> - "Delete": removing the draft entry.
>
> I understand that the draft is overwritten currently by the "Back" button, but why does it get an ID and does not stay as a "Draft"?
> As a quick fix you may skip the "Abort" for now and just provide "Submit" and "Delete".
Any entry in elog (also drafts) need an ID in order to be stored on the server, no way around that.
The "Abort" button is exactly the same as the "Back" button, just the name is different. But I think the meaning will not be so clear
to the users. They could expect to abort the edit, and get the version as it was before they started editing (which is not possible).
So I'm tempted to just have "Submit" and "Delete". If one wants to abort, one can navigate away from the page, and confirm the "Leave page"
dialog box. So experts who know what they do can still do an abort if necessary.
Stefan |
Re: Timstamp button in ckedit inserts an incorrect string ( elogd 3.1.0-2), posted by David Wallis on Thu Jun 4 18:12:43 2015
|
Additional info:
"Time format = %Y" results in "2015" being pasted into the edit window when I hit the "time stamp" button.
"Time format = %m/%Y" results in the string "06/2015"
"TIme format = %m/%d/%Y" results in the string "06/04"
"Time format = %m/%d %H" results in the string "06/04 "
David Wallis wrote: |
I just updated to the latest official release (V3.1.0-2411f95) and have these problems:
- The Time Stamp button pastes the logbook name when "Time format" is not specified in elogd.cfg, and when it is set to "%m/%d/%Y %H:%M", it adds the string "5/28/."
- Drag and drop for attachments dosn't work on either Chrome 37.0.2062.94 (64-bit) or FIrefox 31.5.3 (both on Linux). D&D works on the midas.psi.ch demo page. On my logbooks, the "drop attachements here" area does not have a dashed line border
- Auto-saving does not seem to be working.
The "Syntax of elogd.cfg" help file doesn't seem to reflect some of these features... it took me a while to find the settings for LDAP authentication. Am I just missing some settings for these features?
My users are loving the new functionality added in 3.1!
|
|
Re: ckeditor "Insert Timestamp" bug (was: Three problems with elogd 3.1.0-2), posted by Andreas Luedeke on Fri Jun 5 19:08:17 2015
|
I can confirm that there is currently a problem with the ckeditor "Insert Timestamp" button.
It apparently calls javascript code in ckeditor/plugins/timestamp/plugin.js
to catch a string from the URL "../../?cmd=gettimedate"
(I think this is one too many "../", but anyway). if you try this for the Forum:
https://midas.psi.ch/elogs/Forum/?cmd=gettimedate
it returns the wrong string. It is "Forum" instead of the date.
PS to David: The subject "Three problems ..." is not giving any indication what it is about. I would find it better in this case to post three entries to the Forum, each with a striking title :-)
David Wallis wrote: |
Additional info:
"Time format = %Y" results in "2015" being pasted into the edit window when I hit the "time stamp" button.
"Time format = %m/%Y" results in the string "06/2015"
"TIme format = %m/%d/%Y" results in the string "06/04"
"Time format = %m/%d %H" results in the string "06/04 "
David Wallis wrote: |
I just updated to the latest official release (V3.1.0-2411f95) and have these problems:
- The Time Stamp button pastes the logbook name when "Time format" is not specified in elogd.cfg, and when it is set to "%m/%d/%Y %H:%M", it adds the string "5/28/."
- Drag and drop for attachments dosn't work on either Chrome 37.0.2062.94 (64-bit) or FIrefox 31.5.3 (both on Linux). D&D works on the midas.psi.ch demo page. On my logbooks, the "drop attachements here" area does not have a dashed line border
- Auto-saving does not seem to be working.
The "Syntax of elogd.cfg" help file doesn't seem to reflect some of these features... it took me a while to find the settings for LDAP authentication. Am I just missing some settings for these features?
My users are loving the new functionality added in 3.1!
|
|
|
Re: ckeditor "Insert Timestamp" bug (was: Three problems with elogd 3.1.0-2), posted by David Wallis on Fri Jun 5 23:02:06 2015
|
Andreas,
I too was able to track the problem down to the "gettimedate" function in elogd.c. It looks like the code is using a variable named "str" for several different purposes. I haven't had a chance to do any testing, but my suspsicion is that the size of the dynamically allocated variable is ending up too small for the time stamp string, so it gets truncated.
Your point about the topic title is a good one - I'll split this into separate issues, thanks!
Andreas Luedeke wrote: |
I can confirm that there is currently a problem with the ckeditor "Insert Timestamp" button.
It apparently calls javascript code in ckeditor/plugins/timestamp/plugin.js
to catch a string from the URL "../../?cmd=gettimedate"
(I think this is one too many "../", but anyway). if you try this for the Forum:
https://midas.psi.ch/elogs/Forum/?cmd=gettimedate
it returns the wrong string. It is "Forum" instead of the date.
PS to David: The subject "Three problems ..." is not giving any indication what it is about. I would find it better in this case to post three entries to the Forum, each with a striking title :-)
David Wallis wrote: |
Additional info:
"Time format = %Y" results in "2015" being pasted into the edit window when I hit the "time stamp" button.
"Time format = %m/%Y" results in the string "06/2015"
"TIme format = %m/%d/%Y" results in the string "06/04"
"Time format = %m/%d %H" results in the string "06/04 "
David Wallis wrote: |
I just updated to the latest official release (V3.1.0-2411f95) and have these problems:
- The Time Stamp button pastes the logbook name when "Time format" is not specified in elogd.cfg, and when it is set to "%m/%d/%Y %H:%M", it adds the string "5/28/."
- Drag and drop for attachments dosn't work on either Chrome 37.0.2062.94 (64-bit) or FIrefox 31.5.3 (both on Linux). D&D works on the midas.psi.ch demo page. On my logbooks, the "drop attachements here" area does not have a dashed line border
- Auto-saving does not seem to be working.
The "Syntax of elogd.cfg" help file doesn't seem to reflect some of these features... it took me a while to find the settings for LDAP authentication. Am I just missing some settings for these features?
My users are loving the new functionality added in 3.1!
|
|
|
|
Re: ckeditor "Insert Timestamp" bug (was: Three problems with elogd 3.1.0-2), posted by Stefan Ritt on Mon Jun 8 12:02:30 2015
|
Indeed the "str" variable at the gettimedate function had the wrong string size, so that all date strings got truncated at 8 characters. That's what you've seen. Also the ../../?cmd=gettimedate was wrong and it should be ./?cmd=gettimedate. I committed the fix to GIT so it will be contained in the next release ofe log.
David Wallis wrote: |
Andreas,
I too was able to track the problem down to the "gettimedate" function in elogd.c. It looks like the code is using a variable named "str" for several different purposes. I haven't had a chance to do any testing, but my suspsicion is that the size of the dynamically allocated variable is ending up too small for the time stamp string, so it gets truncated.
Your point about the topic title is a good one - I'll split this into separate issues, thanks!
Andreas Luedeke wrote: |
I can confirm that there is currently a problem with the ckeditor "Insert Timestamp" button.
It apparently calls javascript code in ckeditor/plugins/timestamp/plugin.js
to catch a string from the URL "../../?cmd=gettimedate"
(I think this is one too many "../", but anyway). if you try this for the Forum:
https://midas.psi.ch/elogs/Forum/?cmd=gettimedate
it returns the wrong string. It is "Forum" instead of the date.
PS to David: The subject "Three problems ..." is not giving any indication what it is about. I would find it better in this case to post three entries to the Forum, each with a striking title :-)
David Wallis wrote: |
Additional info:
"Time format = %Y" results in "2015" being pasted into the edit window when I hit the "time stamp" button.
"Time format = %m/%Y" results in the string "06/2015"
"TIme format = %m/%d/%Y" results in the string "06/04"
"Time format = %m/%d %H" results in the string "06/04 "
David Wallis wrote: |
I just updated to the latest official release (V3.1.0-2411f95) and have these problems:
- The Time Stamp button pastes the logbook name when "Time format" is not specified in elogd.cfg, and when it is set to "%m/%d/%Y %H:%M", it adds the string "5/28/."
- Drag and drop for attachments dosn't work on either Chrome 37.0.2062.94 (64-bit) or FIrefox 31.5.3 (both on Linux). D&D works on the midas.psi.ch demo page. On my logbooks, the "drop attachements here" area does not have a dashed line border
- Auto-saving does not seem to be working.
The "Syntax of elogd.cfg" help file doesn't seem to reflect some of these features... it took me a while to find the settings for LDAP authentication. Am I just missing some settings for these features?
My users are loving the new functionality added in 3.1!
|
|
|
|
|
subject line bug on resumit elog entries as new?, posted by Jacky Li on Fri May 29 22:32:20 2015
|
Hi,
I updated an old elog entry and resubmit it as new by checking the box resubmit as new. Does the subject line should said it is a "New ELOG entry" instead of "Updated ELOG entry"? Thank you.
Also when some people submit a new elog, the subject line is "Updated ELOG entry". This is a bit odd. I can't reproduce that bug when I did my test.
Jacky |
Re: subject line bug on resumit elog entries as new?, posted by Stefan Ritt on Tue Jun 9 12:51:07 2015
|
I fixed both issues, now resubmitting an entry or submitting a new entry both yields "New LEOG entry".
Jacky Li wrote: |
Hi,
I updated an old elog entry and resubmit it as new by checking the box resubmit as new. Does the subject line should said it is a "New ELOG entry" instead of "Updated ELOG entry"? Thank you.
Also when some people submit a new elog, the subject line is "Updated ELOG entry". This is a bit odd. I can't reproduce that bug when I did my test.
Jacky
|
|
Re: subject line bug on resumit elog entries as new?, posted by David Pilgram on Tue Jun 9 16:17:06 2015
|
Hi Stefan,
I see that you've updated the elog running this forum today, 5 versions after you reported fixing the "A new elog entry has been entered" and "An old elog entry has been updated" issue. But the emails coming out are still all of the "An old elog entry...", rather than "A new..."
David.
Stefan Ritt wrote: |
I fixed both issues, now resubmitting an entry or submitting a new entry both yields "New LEOG entry".
Jacky Li wrote: |
Hi,
I updated an old elog entry and resubmit it as new by checking the box resubmit as new. Does the subject line should said it is a "New ELOG entry" instead of "Updated ELOG entry"? Thank you.
Also when some people submit a new elog, the subject line is "Updated ELOG entry". This is a bit odd. I can't reproduce that bug when I did my test.
Jacky
|
|
|
Re: subject line bug on resumit elog entries as new?, posted by Stefan Ritt on Tue Jun 9 16:46:48 2015
|
Any better now?
David Pilgram wrote: |
Hi Stefan,
I see that you've updated the elog running this forum today, 5 versions after you reported fixing the "A new elog entry has been entered" and "An old elog entry has been updated" issue. But the emails coming out are still all of the "An old elog entry...", rather than "A new..."
|
|
Re: subject line bug on resumit elog entries as new?, posted by David Pilgram on Tue Jun 9 16:51:55 2015
|
Hi Stefan,
The email sent from here had he expected (correct) message "A new ELOG entry..."
Thanks, David.
Stefan Ritt wrote: |
Any better now?
David Pilgram wrote: |
Hi Stefan,
I see that you've updated the elog running this forum today, 5 versions after you reported fixing the "A new elog entry has been entered" and "An old elog entry has been updated" issue. But the emails coming out are still all of the "An old elog entry...", rather than "A new..."
|
|
|
Re: subject line bug on resumit elog entries as new?, posted by Jacky Li on Tue Jun 9 22:31:59 2015
|
Hi,
I compiled the 3.1.0-2 source rpm from the download area. Unless there is a minor release, I think the problem is still there. Thank you.
Jacky
David Pilgram wrote: |
Hi Stefan,
The email sent from here had he expected (correct) message "A new ELOG entry..."
Thanks, David.
Stefan Ritt wrote: |
Any better now?
David Pilgram wrote: |
Hi Stefan,
I see that you've updated the elog running this forum today, 5 versions after you reported fixing the "A new elog entry has been entered" and "An old elog entry has been updated" issue. But the emails coming out are still all of the "An old elog entry...", rather than "A new..."
|
|
|
|
Re: subject line bug on resumit elog entries as new?, posted by Stefan Ritt on Wed Jun 10 08:13:50 2015
|
Making a new release takes me about an hour (compile under Windows, Linux, Mac OSX), so I don't do it for each little change. If you want to follow the development closely, I recommend that you learn to compile elog from the GIT repository. It's pretty easy: a git pull, followed by a make and make install.
If you want to see which changes are already in the version you are running, look at the 7 digit GIT hash at the bottom of each elog page and compare it with the bitbucket repository:

Jacky Li wrote: |
Hi,
I compiled the 3.1.0-2 source rpm from the download area. Unless there is a minor release, I think the problem is still there. Thank you.
Jack
|
|
Problem with a draft message, posted by David Pilgram on Tue Jun 9 17:17:11 2015
|
Hi Stefan,
I had started to write a completely different bug report, but then realised I had not checked a detail. I had written about one sentence. So I decided to abort the message, and hit the "back" button. Only I found that this had created a new entry in the elog listings. I immediately went in and deleted it, but I had expected the "Back" button to have aborted the entry (as it does in 2.9.x) not to submit the entry!
It doesn't seem to have created an email, though. And for the sake of all your users, I'd not want to experiment here on the matter too much! |
Re: Problem with a draft message, posted by David Pilgram on Tue Jun 9 17:21:25 2015
|
Just to comment that I submitted the entry below by pressing the "Back" button!
David Pilgram wrote: |
Hi Stefan,
I had started to write a completely different bug report, but then realised I had not checked a detail. I had written about one sentence. So I decided to abort the message, and hit the "back" button. Only I found that this had created a new entry in the elog listings. I immediately went in and deleted it, but I had expected the "Back" button to have aborted the entry (as it does in 2.9.x) not to submit the entry!
It doesn't seem to have created an email, though. And for the sake of all your users, I'd not want to experiment here on the matter too much!
|
|
Re: Problem with a draft message, posted by David Pilgram on Tue Jun 9 17:23:27 2015
|
Just to comment that the expected emails that one would have expected with the last two entries have either
been held up or simply have not been generated and sent - both the preceeding entries were submitted by using the "Back" button, this time I'll use the "Submit" button, which should generate a email.
David Pilgram wrote: |
Just to comment that I submitted the entry below by pressing the "Back" button!
David Pilgram wrote: |
Hi Stefan,
I had started to write a completely different bug report, but then realised I had not checked a detail. I had written about one sentence. So I decided to abort the message, and hit the "back" button. Only I found that this had created a new entry in the elog listings. I immediately went in and deleted it, but I had expected the "Back" button to have aborted the entry (as it does in 2.9.x) not to submit the entry!
It doesn't seem to have created an email, though. And for the sake of all your users, I'd not want to experiment here on the matter too much!
|
|
|
Re: Problem with a draft message, posted by Stefan Ritt on Tue Jun 9 19:35:28 2015
|
Just read what I wrote at elog:67983
David Pilgram wrote: |
Just to comment that the expected emails that one would have expected with the last two entries have either
been held up or simply have not been generated and sent - both the preceeding entries were submitted by using the "Back" button, this time I'll use the "Submit" button, which should generate a email.
David Pilgram wrote: |
Just to comment that I submitted the entry below by pressing the "Back" button!
David Pilgram wrote: |
Hi Stefan,
I had started to write a completely different bug report, but then realised I had not checked a detail. I had written about one sentence. So I decided to abort the message, and hit the "back" button. Only I found that this had created a new entry in the elog listings. I immediately went in and deleted it, but I had expected the "Back" button to have aborted the entry (as it does in 2.9.x) not to submit the entry!
It doesn't seem to have created an email, though. And for the sake of all your users, I'd not want to experiment here on the matter too much!
|
|
|
|
Re: Problem with a draft message, posted by David Pilgram on Tue Jun 9 20:26:00 2015
|
I missed or don't remember that post. My vote is replace "Back" with "Delete" - or "Abort"
Stefan Ritt wrote: |
Just read what I wrote at elog:67983
David Pilgram wrote: |
Just to comment that the expected emails that one would have expected with the last two entries have either
been held up or simply have not been generated and sent - both the preceeding entries were submitted by using the "Back" button, this time I'll use the "Submit" button, which should generate a email.
David Pilgram wrote: |
Just to comment that I submitted the entry below by pressing the "Back" button!
David Pilgram wrote: |
Hi Stefan,
I had started to write a completely different bug report, but then realised I had not checked a detail. I had written about one sentence. So I decided to abort the message, and hit the "back" button. Only I found that this had created a new entry in the elog listings. I immediately went in and deleted it, but I had expected the "Back" button to have aborted the entry (as it does in 2.9.x) not to submit the entry!
It doesn't seem to have created an email, though. And for the sake of all your users, I'd not want to experiment here on the matter too much!
|
|
|
|
|
logout to external page, posted by Christof Hanke on Wed May 6 11:00:14 2015
|
Hi Stefan,
I am happy to see that you include the webserver authentication.
So I can now login at some other page and then access elog.
However, I would also need some means of logging out some where else.
For this I propose a new Configuration option "Logout to page" which redirects to another page if set and "Logout to main" is 0.
See the attached patch (against git HEAD)
Does this make sense to you ?
Christof
PS: Many thanks for the autosave mode, I already used it ;-)
|
Re: logout to external page, posted by Stefan Ritt on Tue Jun 9 16:09:39 2015
|
I implemented it, but actually called it Logout to URL = <URL>
Christof Hanke wrote: |
Hi Stefan,
I am happy to see that you include the webserver authentication.
So I can now login at some other page and then access elog.
However, I would also need some means of logging out some where else.
For this I propose a new Configuration option "Logout to page" which redirects to another page if set and "Logout to main" is 0.
See the attached patch (against git HEAD)
Does this make sense to you ?
Christof
PS: Many thanks for the autosave mode, I already used it ;-)
|
|
Re: logout to external page, posted by Christof Hanke on Tue Jun 9 16:58:28 2015
|
Yes, I saw it on bitbucket, also all the commits. Thanks!
Stefan Ritt wrote: |
I implemented it, but actually called it Logout to URL = <URL>
Christof Hanke wrote: |
Hi Stefan,
I am happy to see that you include the webserver authentication.
So I can now login at some other page and then access elog.
However, I would also need some means of logging out some where else.
For this I propose a new Configuration option "Logout to page" which redirects to another page if set and "Logout to main" is 0.
See the attached patch (against git HEAD)
Does this make sense to you ?
Christof
PS: Many thanks for the autosave mode, I already used it ;-)
|
|
|
Documentation of the webserver authentication, posted by Christof Hanke on Wed May 6 12:31:04 2015
|
Hi Stefan,
here is a draft of how you could describe the webserver authentication in your docs.
T/Christof |
Re: Documentation of the webserver authentication, posted by Stefan Ritt on Tue Jun 9 16:57:06 2015
|
Also this made it now to the docs. Thanks.
Christof Hanke wrote: |
Hi Stefan,
here is a draft of how you could describe the webserver authentication in your docs.
T/Christof
|
|
parse a correctly the username in save_user_config when using Webserver authentication, posted by Christof Hanke on Wed May 6 15:13:11 2015
|
Hi Stefan,
When we use Webserver authentication, we have the correct username already in the variable http_user.
The old way of copying this http_user to "user" is wrong since we don't use the size of http_user.
Instead, just encode the http_user variable directly.
See attached patch against git HEAD.
Christof
|
Re: parse a correctly the username in save_user_config when using Webserver authentication, posted by Stefan Ritt on Tue Jun 9 15:44:49 2015
|
Hi Christof,
thanks for the patch, I merged it into the current HEAD.
/Stefan
Christof Hanke wrote: |
Hi Stefan,
When we use Webserver authentication, we have the correct username already in the variable http_user.
The old way of copying this http_user to "user" is wrong since we don't use the size of http_user.
Instead, just encode the http_user variable directly.
See attached patch against git HEAD.
Christof
|
|
Attribute not updated, posted by Francois Cloutier on Wed May 13 14:58:46 2015
|
Good day,
I'm populating 2 fields based on the Option set in a third one.
It works, but for some reason, sometimes when I change the entry from one value to another (from 3/01/2015 to 26/03/2016) , the field "# Volume" stays at the first position
(149) and doesn't get updated... I tried both with Chrome and IE.
Attributes = #Réception, #Galée, #Volume, #Parution, Partie, Parution, Infographiste, Traitement, Réviseur, Révision, Contrôleur, Contrôle, Correcteur, Correction,
Commentaires, Contrôle final
List display = Edit, #Réception, #Volume, #Parution, #Galée, Parution, Infographiste, Traitement, Réviseur, Révision, Contrôleur, Contrôle, Correcteur, Correction,
Contrôle
final
Show attributes edit = #Réception, #Volume, Partie, #Galée, Parution, #Parution, Infographiste, Traitement, Réviseur, Révision, Contrôleur, Contrôle, Correcteur,
Correction,
Commentaires, Contrôle final
Menu commands = Select, edit, Move to, Delete
List menu commands = Select, New, Find
Move to = Archives
Fixed Attributes Edit = #Réception, #Parution
Locked Attributes = #Réception, #Volume, Partie, #Parution
Preset #Réception = 1-#####
Preset Partie = 1
Preset Infographiste = -
Preset Réviseur = -
Preset Contrôleur = -
Preset Correcteur = -
Options Parution = 3/01/2015{1}, 10/01/2015{2}, 17/01/2015{3}, 24/01/2015{4}, 31/01/2015{5}, 7/02/2015{6}, 14/02/2015{7}, 21/02/2015{8}, 28/02/2015{9}, 7/03/2015{10},
14/03/2015{11}, 21/03/2015{12}, 28/03/2015{13}, 4/04/2015{14}, 11/04/2015{15}, 18/04/2015{16}, 25/04/2015{17}, 2/05/2015{18}, 9/05/2015{19}, 16/05/2015{20}, 23/05/2015{21},
30/05/2015{22}, 6/06/2015{23}, 13/06/2015{24}, 20/06/2015{25}, 27/06/2015{26}, 4/07/2015{27}, 11/07/2015{28}, 18/07/2015{29}, 25/07/2015{30}, 1/08/2015{31}, 8/08/2015{32},
15/08/2015{33}, 22/08/2015{34}, 29/08/2015{35}, 5/09/2015{36}, 12/09/2015{37}, 19/09/2015{38}, 26/09/2015{39}, 3/10/2015{40}, 10/10/2015{41}, 17/10/2015{42}, 24/10/2015{43},
31/10/2015{44}, 7/11/2015{45}, 14/11/2015{46}, 21/11/2015{47}, 28/11/2015{48}, 5/12/2015{49}, 12/12/2015{50}, 19/12/2015{51}, 26/12/2015{52}, 2/01/2016{53}, 9/01/2016{54},
16/01/2015{55}, 23/01/2016{56}, 30/01/2016{57}, 6/02/2016{58}, 13/02/2016{59}, 20/02/2016{60}, 27/02/2016{61}, 5/03/2016{62}, 12/03/2016{63}, 19/03/2016{64}, 26/03/2016{65}
Options Infographiste = -, ML, TS, AN, AC
Options Réviseur = -, MB, JC, SS, AR, LH, CA, NB, CL, TM, NR, MS
Options Contrôleur = -, MB, JC, SS, AR, LH, CA, NB, CL, TM, NR, MS
Options Correcteur = -, ML, TS, AN, AC
{1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51}Preset #Volume = 149
{53,54,55,56,57,58,59,60,61,62,63,64,65}Preset #Volume = 150
{1} Preset #Parution = 1
{2} Preset #Parution = 2
{3} Preset #Parution = 3
{4} Preset #Parution = 4
{5} Preset #Parution = 5
{6} Preset #Parution = 6
{7} Preset #Parution = 7
{8} Preset #Parution = 8
{9} Preset #Parution = 9
{10} Preset #Parution = 10
{11} Preset #Parution = 11
{12} Preset #Parution = 12
{13} Preset #Parution = 13
{14} Preset #Parution = 14
{15} Preset #Parution = 15
{16} Preset #Parution = 16
{17} Preset #Parution = 17
{18} Preset #Parution = 18
{19} Preset #Parution = 19
{20} Preset #Parution = 20
{21} Preset #Parution = 21
{22} Preset #Parution = 22
{23} Preset #Parution = 23
{24} Preset #Parution = 24
{25} Preset #Parution = 25
{26} Preset #Parution = 26
{27} Preset #Parution = 27
{28} Preset #Parution = 28
{29} Preset #Parution = 29
{30} Preset #Parution = 30
{31} Preset #Parution = 31
{32} Preset #Parution = 32
{33} Preset #Parution = 33
{34} Preset #Parution = 34
{35} Preset #Parution = 35
{36} Preset #Parution = 36
{37} Preset #Parution = 37
{38} Preset #Parution = 38
{39} Preset #Parution = 39
{40} Preset #Parution = 40
{41} Preset #Parution = 41
{42} Preset #Parution = 42
{43} Preset #Parution = 43
{44} Preset #Parution = 44
{45} Preset #Parution = 45
{46} Preset #Parution = 46
{47} Preset #Parution = 47
{48} Preset #Parution = 48
{49} Preset #Parution = 49
{50} Preset #Parution = 50
{51} Preset #Parution = 51
{52} Preset #Parution = 52
{53} Preset #Parution = 1
{54} Preset #Parution = 2
{55} Preset #Parution = 3
{56} Preset #Parution = 4
{57} Preset #Parution = 5
{58} Preset #Parution = 6
{59} Preset #Parution = 7
{60} Preset #Parution = 8
{61} Preset #Parution = 9
{62} Preset #Parution = 10
{63} Preset #Parution = 11
{64} Preset #Parution = 12
{65} Preset #Parution = 13 |
Re: Attribute not updated, posted by Francois Cloutier on Wed May 13 15:19:55 2015
|
I also tried with :
{1, 53} Preset #Parution = 1
{2, 54} Preset #Parution = 2
{3, 55} Preset #Parution = 3
{4, 56} Preset #Parution = 4
{5,57} Preset #Parution = 5
{6, 58} Preset #Parution = 6
{7, 59} Preset #Parution = 7
{8, 60} Preset #Parution = 8
{9, 61} Preset #Parution = 9
{10, 62} Preset #Parution = 10
{11, 63} Preset #Parution = 11
{12, 64} Preset #Parution = 12
{13,65} Preset #Parution = 13
> Good day,
>
> I'm populating 2 fields based on the Option set in a third one.
> It works, but for some reason, sometimes when I change the entry from one value to another (from 3/01/2015 to 26/03/2016) , the field "# Volume" stays at the first position
> (149) and doesn't get updated... I tried both with Chrome and IE.
>
> Attributes = #Réception, #Galée, #Volume, #Parution, Partie, Parution, Infographiste, Traitement, Réviseur, Révision, Contrôleur, Contrôle, Correcteur, Correction,
> Commentaires, Contrôle final
> List display = Edit, #Réception, #Volume, #Parution, #Galée, Parution, Infographiste, Traitement, Réviseur, Révision, Contrôleur, Contrôle, Correcteur, Correction,
> Contrôle
> final
> Show attributes edit = #Réception, #Volume, Partie, #Galée, Parution, #Parution, Infographiste, Traitement, Réviseur, Révision, Contrôleur, Contrôle, Correcteur,
> Correction,
> Commentaires, Contrôle final
>
> Menu commands = Select, edit, Move to, Delete
> List menu commands = Select, New, Find
> Move to = Archives
>
> Fixed Attributes Edit = #Réception, #Parution
> Locked Attributes = #Réception, #Volume, Partie, #Parution
>
> Preset #Réception = 1-#####
>
> Preset Partie = 1
> Preset Infographiste = -
> Preset Réviseur = -
> Preset Contrôleur = -
> Preset Correcteur = -
>
> Options Parution = 3/01/2015{1}, 10/01/2015{2}, 17/01/2015{3}, 24/01/2015{4}, 31/01/2015{5}, 7/02/2015{6}, 14/02/2015{7}, 21/02/2015{8}, 28/02/2015{9}, 7/03/2015{10},
> 14/03/2015{11}, 21/03/2015{12}, 28/03/2015{13}, 4/04/2015{14}, 11/04/2015{15}, 18/04/2015{16}, 25/04/2015{17}, 2/05/2015{18}, 9/05/2015{19}, 16/05/2015{20}, 23/05/2015{21},
> 30/05/2015{22}, 6/06/2015{23}, 13/06/2015{24}, 20/06/2015{25}, 27/06/2015{26}, 4/07/2015{27}, 11/07/2015{28}, 18/07/2015{29}, 25/07/2015{30}, 1/08/2015{31}, 8/08/2015{32},
> 15/08/2015{33}, 22/08/2015{34}, 29/08/2015{35}, 5/09/2015{36}, 12/09/2015{37}, 19/09/2015{38}, 26/09/2015{39}, 3/10/2015{40}, 10/10/2015{41}, 17/10/2015{42},
24/10/2015{43},
> 31/10/2015{44}, 7/11/2015{45}, 14/11/2015{46}, 21/11/2015{47}, 28/11/2015{48}, 5/12/2015{49}, 12/12/2015{50}, 19/12/2015{51}, 26/12/2015{52}, 2/01/2016{53}, 9/01/2016{54},
> 16/01/2015{55}, 23/01/2016{56}, 30/01/2016{57}, 6/02/2016{58}, 13/02/2016{59}, 20/02/2016{60}, 27/02/2016{61}, 5/03/2016{62}, 12/03/2016{63}, 19/03/2016{64}, 26/03/2016{65}
>
> Options Infographiste = -, ML, TS, AN, AC
> Options Réviseur = -, MB, JC, SS, AR, LH, CA, NB, CL, TM, NR, MS
> Options Contrôleur = -, MB, JC, SS, AR, LH, CA, NB, CL, TM, NR, MS
> Options Correcteur = -, ML, TS, AN, AC
>
> {1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51}Preset #Volume = 149
> {53,54,55,56,57,58,59,60,61,62,63,64,65}Preset #Volume = 150
>
> {1} Preset #Parution = 1
> {2} Preset #Parution = 2
> {3} Preset #Parution = 3
> {4} Preset #Parution = 4
> {5} Preset #Parution = 5
> {6} Preset #Parution = 6
> {7} Preset #Parution = 7
> {8} Preset #Parution = 8
> {9} Preset #Parution = 9
> {10} Preset #Parution = 10
> {11} Preset #Parution = 11
> {12} Preset #Parution = 12
> {13} Preset #Parution = 13
> {14} Preset #Parution = 14
> {15} Preset #Parution = 15
> {16} Preset #Parution = 16
> {17} Preset #Parution = 17
> {18} Preset #Parution = 18
> {19} Preset #Parution = 19
> {20} Preset #Parution = 20
> {21} Preset #Parution = 21
> {22} Preset #Parution = 22
> {23} Preset #Parution = 23
> {24} Preset #Parution = 24
> {25} Preset #Parution = 25
> {26} Preset #Parution = 26
> {27} Preset #Parution = 27
> {28} Preset #Parution = 28
> {29} Preset #Parution = 29
> {30} Preset #Parution = 30
> {31} Preset #Parution = 31
> {32} Preset #Parution = 32
> {33} Preset #Parution = 33
> {34} Preset #Parution = 34
> {35} Preset #Parution = 35
> {36} Preset #Parution = 36
> {37} Preset #Parution = 37
> {38} Preset #Parution = 38
> {39} Preset #Parution = 39
> {40} Preset #Parution = 40
> {41} Preset #Parution = 41
> {42} Preset #Parution = 42
> {43} Preset #Parution = 43
> {44} Preset #Parution = 44
> {45} Preset #Parution = 45
> {46} Preset #Parution = 46
> {47} Preset #Parution = 47
> {48} Preset #Parution = 48
> {49} Preset #Parution = 49
> {50} Preset #Parution = 50
> {51} Preset #Parution = 51
> {52} Preset #Parution = 52
> {53} Preset #Parution = 1
> {54} Preset #Parution = 2
> {55} Preset #Parution = 3
> {56} Preset #Parution = 4
> {57} Preset #Parution = 5
> {58} Preset #Parution = 6
> {59} Preset #Parution = 7
> {60} Preset #Parution = 8
> {61} Preset #Parution = 9
> {62} Preset #Parution = 10
> {63} Preset #Parution = 11
> {64} Preset #Parution = 12
> {65} Preset #Parution = 13 |
Re: Attribute not updated, posted by Andreas Luedeke on Thu May 14 02:02:45 2015
|
Hi Francois,
as far as I know there is a limit on the number of conditions you can use (See elog:67303).
I guess you did hit that limit.
I think I've mentioned recently that ELOG is not a relational database, didn't I?
It is of course possible to drive screws with a hammer, but there do exist more suitable tools for that ;-)
Kind regards
Andreas |
Re: Attribute not updated, posted by Francois Cloutier on Thu May 14 02:27:58 2015
|
> Hi Francois,
> as far as I know there is a limit on the number of conditions you can use (See elog:67303).
> I guess you did hit that limit.
>
> I think I've mentioned recently that ELOG is not a relational database, didn't I?
> It is of course possible to drive screws with a hammer, but there do exist more suitable tools for that ;-)
>
> Kind regards
> Andreas
Got it...
But again, I found it strange that it works from time to time.... is it an elog limit or a javascript issue....
the guide mentions :
Options <attribute> = <list>
Usually, an text field is used for an attribute, where the user can fill in text of up to 100 characters.
but no words on options size...
I would say if it was a size issue it would not work at all no ?... but now it works from time to time....
But you are right, maybe I should get a bigger hammer :)
Seriously, I really hope It could make it... Could you try it on your side ? could I enable some sort of debug mode other than running elogd from a shell ? |
Re: Attribute not updated, posted by Andreas Luedeke on Thu May 14 04:59:03 2015
|
> Seriously, I really hope It could make it... Could you try it on your side ?
My personal opinion here is, that if you want others to investigate your problems, then the best way to do it is like that:
- attach a minimal configuration that reproduces your problem (never attach a 100 line configuration, unless you've tested that the problem disappears
regardless of which line you remove!);
- attach the entry data, if the behaviour depends on the data;
- use a specific, to the point subject line;
- explain what you did, what happened and what you would have expected to happen;
- ask kindly; and then
- wait and hope for the best ;-)
(This is actually a very general procedure; I think it is applicable to all newsgroups, forums, etc.)
BTW: This tip was absolutely free of charge ;-) |
Re: Attribute not updated, posted by Francois Cloutier on Thu May 14 05:08:06 2015
|
>
> > Seriously, I really hope It could make it... Could you try it on your side ?
>
> My personal opinion here is, that if you want others to investigate your problems, then the best way to do it is like that:
> - attach a minimal configuration that reproduces your problem (never attach a 100 line configuration, unless you've tested that the problem disappears
> regardless of which line you remove!);
> - attach the entry data, if the behaviour depends on the data;
> - use a specific, to the point subject line;
> - explain what you did, what happened and what you would have expected to happen;
> - ask kindly; and then
> - wait and hope for the best ;-)
>
> (This is actually a very general procedure; I think it is applicable to all newsgroups, forums, etc.)
>
> BTW: This tip was absolutely free of charge ;-)
Andreas,
Thanks for your comments. Thats why I posted in the first msg my configuration details... I just hope there can be a solution :)
I saw in the doc that an attribute cant be bigger than 100 char. but I couldn't figure the maximum size for options... I'm wondering if the issue comes from the browser not refreshing correctly or if its elog..
Again, I tought that if that was from elog limitations, the attributes wouldn't load the options presets at all... but they do, (attribute volume) ... just not all the time :)
I understand that you are proactive on this forum and eventually I was thinking of contributing with detailed specific config examples but for now I just would like to get on track :)
The last time I used Elog was 10 years ago :) it changed alot since :) |
Re: Attribute not updated, posted by Midas User on Tue Jun 9 15:28:53 2015
|
> I saw in the doc that an attribute cant be bigger than 100 char. but I couldn't figure the maximum size for options... I'm wondering if the issue comes from the browser not refreshing correctly or if its elog..
The number of possible options is limited in elog to 100. This is defined by MAX_N_LIST in elogd.h. You can try to increase it and recompile elogd, but no guarantee that this works.
The reason that it *sometimes* work is really a bug, I should do better limit checkings...
/Stefan |
edit somebody else's draft, posted by Konstantin Olchanski on Wed May 20 01:54:55 2015
|
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. |
Re: edit somebody else's draft, posted by David Pilgram on Wed May 20 22:12:49 2015
|
> 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? |
Re: edit somebody else's draft, posted by Stefan Ritt on Fri May 22 13:50:31 2015
|
> > 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 |
Re: edit somebody else's draft, posted by Midas User on Tue Jun 9 15:22:03 2015
|
> 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 changed this behaviour now, so authors can only edit their own drafts. Furthermore, drafts are not shown any more in the elog lists. In addition, deleting of entries is allowed now again in this forum, so if someone creates a draft by accident, he/she can delete it.
/Stefan |
|