Re: Why are Preset fields blanked out?, posted by Stefan Ritt on Mon Sep 18 15:21:56 2006 
|
| Steve Jones wrote: | The snippet of code below sets an attribute to a date depending on the selection. Problem is, if attribute ApprovedDate was previously set, selecting any other value for CRStatus will blank out ApprovedDate (the same occurs for CompletedDate). Why would this be occurring when the conditionals are mutually exclusive?
##################################################
# Define CRState
#
Options CRState = PENDING{a}, APPROVED{b}, HOLD{a}, REJECTED{a}, COMPLETED{c}
{a}
{b} Preset ApprovedDate = $date
{c} Preset CompletedDate = $date
|
I don't understand your problem. If I use following config file:
[demo]
Theme = default
Attributes = Author, CRState, ApprovedDate, CompletedDate
Options CRState = PENDING{a}, APPROVED{b}, HOLD{a}, REJECTED{a}, COMPLETED{c}
{a}
{b} Preset ApprovedDate = $date
{c} Preset CompletedDate = $date
and make an entry, then edit it, selecting approved, then submit, then edit again, then select completed, then I get following:
which looks ok to me (the previous ApprovedDate does not get blanked out). Can you reproduce that behaviour? |
|
Re: Re: Why are Preset fields blanked out?, posted by Steve Jones on Mon Sep 18 18:19:44 2006
|
| Stefan Ritt wrote: |
| Steve Jones wrote: | The snippet of code below sets an attribute to a date depending on the selection. Problem is, if attribute ApprovedDate was previously set, selecting any other value for CRStatus will blank out ApprovedDate (the same occurs for CompletedDate). Why would this be occurring when the conditionals are mutually exclusive?
##################################################
# Define CRState
#
Options CRState = PENDING{a}, APPROVED{b}, HOLD{a}, REJECTED{a}, COMPLETED{c}
{a}
{b} Preset ApprovedDate = $date
{c} Preset CompletedDate = $date
|
I don't understand your problem. If I use following config file:
[demo]
Theme = default
Attributes = Author, CRState, ApprovedDate, CompletedDate
Options CRState = PENDING{a}, APPROVED{b}, HOLD{a}, REJECTED{a}, COMPLETED{c}
{a}
{b} Preset ApprovedDate = $date
{c} Preset CompletedDate = $date
and make an entry, then edit it, selecting approved, then submit, then edit again, then select completed, then I get following:
which looks ok to me (the previous ApprovedDate does not get blanked out). Can you reproduce that behaviour? |
| Quote: |
I think I found it. Try this:
Locked Attributes = ApprovedDate, CompletedDate
##################################################
# Define CRState
#
Options CRState = PENDING{a}, APPROVED{b}, HOLD{a}, REJECTED{a}, COMPLETED{c}
{a}
{b} Preset ApprovedDate = $date
{c} Preset CompletedDate = $date
In my config when I remove the two attributes from "LOCKED ATTRIBUTES" the fields do not get blanked out.
|
|
|
Re: Re: Why are Preset fields blanked out?, posted by Stefan Ritt on Tue Sep 19 17:32:28 2006
|
| Steve Jones wrote: |
I think I found it. Try this:
Locked Attributes = ApprovedDate, CompletedDate
##################################################
# Define CRState
#
Options CRState = PENDING{a}, APPROVED{b}, HOLD{a}, REJECTED{a}, COMPLETED{c}
{a}
{b} Preset ApprovedDate = $date
{c} Preset CompletedDate = $date
In my config when I remove the two attributes from "LOCKED ATTRIBUTES" the fields do not get blanked out.
|
No, even with that it does not get blanked out. Attached is the complete elogd.cfg with which it works fine in my case (R1714). Can you try that? |
|
Re: Re: Why are Preset fields blanked out?, posted by Steve Jones on Tue Sep 19 19:22:31 2006
|
| Stefan Ritt wrote: |
| Steve Jones wrote: |
I think I found it. Try this:
Locked Attributes = ApprovedDate, CompletedDate
##################################################
# Define CRState
#
Options CRState = PENDING{a}, APPROVED{b}, HOLD{a}, REJECTED{a}, COMPLETED{c}
{a}
{b} Preset ApprovedDate = $date
{c} Preset CompletedDate = $date
In my config when I remove the two attributes from "LOCKED ATTRIBUTES" the fields do not get blanked out.
|
No, even with that it does not get blanked out. Attached is the complete elogd.cfg with which it works fine in my case (R1714). Can you try that? |
| Quote: |
Stefan, when I try that config in a demo logbook in my installation *but with all other items in [global] I get the same field-blanking behavior. I am going to try going back to a completely pristine .cfg, but I suspect this will work fine. I will need to add back in configuration items until I run into the culprit.
Ok, I found it. Try this config:
[global]
port = 8080
[demo]
Comment = Test
Attributes = Author, CRState, ApprovedDate, CompletedDate
Locked Attributes = ApprovedDate, CompletedDate
Type CompletedDate = date
Type ApprovedDate = date
Format CompletedDate = 1
Options CRState = PENDING{a}, APPROVED{b}, HOLD{a}, REJECTED{a}, COMPLETED{c}
{a}
{b} Preset ApprovedDate = $date
{c} Preset CompletedDate = $date
Setting the "Type" to "date" causes the blanking to occur.
|
|
|
Re: Re: Why are Preset fields blanked out?, posted by Stefan Ritt on Tue Sep 19 20:28:15 2006
|
| Steve Jones wrote: |
Setting the "Type" to "date" causes the blanking to occur.
|
Ok, then don't set the "Type" to "date"  |
|
Re: Re: Why are Preset fields blanked out?, posted by Steve Jones on Tue Sep 19 20:38:49 2006
|
| Stefan Ritt wrote: |
| Steve Jones wrote: |
Setting the "Type" to "date" causes the blanking to occur.
|
Ok, then don't set the "Type" to "date" |
| Quote: |
Yuk! Thanks!
|
|
Why are Preset fields blanked out?, posted by Steve Jones on Thu Sep 14 22:59:39 2006
|
The snippet of code below sets an attribute to a date depending on the selection. Problem is, if attribute ApprovedDate was previously set, selecting any other value for CRStatus will blank out ApprovedDate (the same occurs for CompletedDate). Why would this be occurring when the conditionals are mutually exclusive?
##################################################
# Define CRState
#
Options CRState = PENDING{a}, APPROVED{b}, HOLD{a}, REJECTED{a}, COMPLETED{c}
{a}
{b} Preset ApprovedDate = $date
{c} Preset CompletedDate = $date
|
|
Re: Why are Preset fields blanked out?, posted by Stefan Ritt on Mon Sep 18 15:21:56 2006
|
| Steve Jones wrote: | The snippet of code below sets an attribute to a date depending on the selection. Problem is, if attribute ApprovedDate was previously set, selecting any other value for CRStatus will blank out ApprovedDate (the same occurs for CompletedDate). Why would this be occurring when the conditionals are mutually exclusive?
##################################################
# Define CRState
#
Options CRState = PENDING{a}, APPROVED{b}, HOLD{a}, REJECTED{a}, COMPLETED{c}
{a}
{b} Preset ApprovedDate = $date
{c} Preset CompletedDate = $date
|
I don't understand your problem. If I use following config file:
[demo]
Theme = default
Attributes = Author, CRState, ApprovedDate, CompletedDate
Options CRState = PENDING{a}, APPROVED{b}, HOLD{a}, REJECTED{a}, COMPLETED{c}
{a}
{b} Preset ApprovedDate = $date
{c} Preset CompletedDate = $date
and make an entry, then edit it, selecting approved, then submit, then edit again, then select completed, then I get following:
which looks ok to me (the previous ApprovedDate does not get blanked out). Can you reproduce that behaviour? |
|
Re: Re: Why are Preset fields blanked out?, posted by Steve Jones on Mon Sep 18 18:19:44 2006
|
| Stefan Ritt wrote: |
| Steve Jones wrote: | The snippet of code below sets an attribute to a date depending on the selection. Problem is, if attribute ApprovedDate was previously set, selecting any other value for CRStatus will blank out ApprovedDate (the same occurs for CompletedDate). Why would this be occurring when the conditionals are mutually exclusive?
##################################################
# Define CRState
#
Options CRState = PENDING{a}, APPROVED{b}, HOLD{a}, REJECTED{a}, COMPLETED{c}
{a}
{b} Preset ApprovedDate = $date
{c} Preset CompletedDate = $date
|
I don't understand your problem. If I use following config file:
[demo]
Theme = default
Attributes = Author, CRState, ApprovedDate, CompletedDate
Options CRState = PENDING{a}, APPROVED{b}, HOLD{a}, REJECTED{a}, COMPLETED{c}
{a}
{b} Preset ApprovedDate = $date
{c} Preset CompletedDate = $date
and make an entry, then edit it, selecting approved, then submit, then edit again, then select completed, then I get following:
which looks ok to me (the previous ApprovedDate does not get blanked out). Can you reproduce that behaviour? |
| Quote: |
I think I found it. Try this:
Locked Attributes = ApprovedDate, CompletedDate
##################################################
# Define CRState
#
Options CRState = PENDING{a}, APPROVED{b}, HOLD{a}, REJECTED{a}, COMPLETED{c}
{a}
{b} Preset ApprovedDate = $date
{c} Preset CompletedDate = $date
In my config when I remove the two attributes from "LOCKED ATTRIBUTES" the fields do not get blanked out.
|
|
|
Re: Re: Why are Preset fields blanked out?, posted by Stefan Ritt on Tue Sep 19 17:32:28 2006
|
| Steve Jones wrote: |
I think I found it. Try this:
Locked Attributes = ApprovedDate, CompletedDate
##################################################
# Define CRState
#
Options CRState = PENDING{a}, APPROVED{b}, HOLD{a}, REJECTED{a}, COMPLETED{c}
{a}
{b} Preset ApprovedDate = $date
{c} Preset CompletedDate = $date
In my config when I remove the two attributes from "LOCKED ATTRIBUTES" the fields do not get blanked out.
|
No, even with that it does not get blanked out. Attached is the complete elogd.cfg with which it works fine in my case (R1714). Can you try that? |
|
Re: Re: Why are Preset fields blanked out?, posted by Steve Jones on Tue Sep 19 19:22:31 2006
|
| Stefan Ritt wrote: |
| Steve Jones wrote: |
I think I found it. Try this:
Locked Attributes = ApprovedDate, CompletedDate
##################################################
# Define CRState
#
Options CRState = PENDING{a}, APPROVED{b}, HOLD{a}, REJECTED{a}, COMPLETED{c}
{a}
{b} Preset ApprovedDate = $date
{c} Preset CompletedDate = $date
In my config when I remove the two attributes from "LOCKED ATTRIBUTES" the fields do not get blanked out.
|
No, even with that it does not get blanked out. Attached is the complete elogd.cfg with which it works fine in my case (R1714). Can you try that? |
| Quote: |
Stefan, when I try that config in a demo logbook in my installation *but with all other items in [global] I get the same field-blanking behavior. I am going to try going back to a completely pristine .cfg, but I suspect this will work fine. I will need to add back in configuration items until I run into the culprit.
Ok, I found it. Try this config:
[global]
port = 8080
[demo]
Comment = Test
Attributes = Author, CRState, ApprovedDate, CompletedDate
Locked Attributes = ApprovedDate, CompletedDate
Type CompletedDate = date
Type ApprovedDate = date
Format CompletedDate = 1
Options CRState = PENDING{a}, APPROVED{b}, HOLD{a}, REJECTED{a}, COMPLETED{c}
{a}
{b} Preset ApprovedDate = $date
{c} Preset CompletedDate = $date
Setting the "Type" to "date" causes the blanking to occur.
|
|
|
Re: Re: Why are Preset fields blanked out?, posted by Stefan Ritt on Tue Sep 19 20:28:15 2006
|
| Steve Jones wrote: |
Setting the "Type" to "date" causes the blanking to occur.
|
Ok, then don't set the "Type" to "date" |
|
Re: Re: Why are Preset fields blanked out?, posted by Steve Jones on Tue Sep 19 20:38:49 2006
|
| Stefan Ritt wrote: |
| Steve Jones wrote: |
Setting the "Type" to "date" causes the blanking to occur.
|
Ok, then don't set the "Type" to "date" |
| Quote: |
Yuk! Thanks!
|
|
Unsubscribe from logbooks, posted by Chris Warner on Fri Sep 8 18:42:05 2006
|
| Is there a way for user to unsubscribe from a logbook? Can a user delete their own account? |
|
Re: Unsubscribe from logbooks, posted by Stefan Ritt on Mon Sep 11 17:25:54 2006
|
| Chris Warner wrote: | | Is there a way for user to unsubscribe from a logbook? Can a user delete their own account? |
Yes. Yes.
Just click on "Config", and you will see a page where you can unsubscribe from each logbook and a button to remove your account. |
Auto-refresh ELog display, posted by Alan Stone on Thu Aug 24 15:52:54 2006
|
We have multiple LCDs at a console, and usually one is dedicated to displaying a browser
with the local ELog. Meanwhile, others are making entries from another machine. If
no one clicks on refresh, the ELog display becomes stale. Is there a method to have
the ELog reload every X minutes?
Thanks, Alan |
|
Re: Auto-refresh ELog display, posted by Steve Jones on Thu Aug 24 19:02:47 2006
|
Couldn't a small bit of javascript be added that would accomplish this? Me saying this and I have no idea what I am talking about!!
| Alan Stone wrote: | We have multiple LCDs at a console, and usually one is dedicated to displaying a browser
with the local ELog. Meanwhile, others are making entries from another machine. If
no one clicks on refresh, the ELog display becomes stale. Is there a method to have
the ELog reload every X minutes?
Thanks, Alan |
|
|
Re: Auto-refresh ELog display, posted by Steve Jones on Thu Aug 24 19:28:35 2006
|
<html>
<head>
<title>Refresh JavaScript Example</title>
<noscript>
<!--
We have the "refresh" meta-tag in case the user's browser does
not correctly support JavaScript or has JavaScript disabled.
Notice that this is nested within a "noscript" block.
-->
<meta http-equiv="refresh" content="2">
</noscript>
<script language="JavaScript">
<!--
var sURL = unescape(window.location.pathname);
function doLoad()
{
// the timeout value should be the same as in the "refresh" meta-tag
setTimeout( "refresh()", 2*1000 );
}
function refresh()
{
// This version of the refresh function will cause a new
// entry in the visitor's history. It is provided for
// those browsers that only support JavaScript 1.0.
//
window.location.href = sURL;
}
//-->
</script>
<script language="JavaScript1.1">
<!--
function refresh()
{
// This version does NOT cause an entry in the browser's
// page view history. Most browsers will always retrieve
// the document from the web-server whether it is already
// in the browsers page-cache or not.
//
window.location.replace( sURL );
}
//-->
</script>
<script language="JavaScript1.2">
<!--
function refresh()
{
// This version of the refresh function will be invoked
// for browsers that support JavaScript version 1.2
//
// The argument to the location.reload function determines
// if the browser should retrieve the document from the
// web-server. In our example all we need to do is cause
// the JavaScript block in the document body to be
// re-evaluated. If we needed to pull the document from
// the web-server again (such as where the document contents
// change dynamically) we would pass the argument as 'true'.
//
window.location.reload( false );
}
//-->
</script>
</head>
<!--
Use the "onload" event to start the refresh process.
-->
<body onload="doLoad()">
<script language="JavaScript">
<!--
// we put this here so we can see something change
document.write('<b>' + (new Date).toLocaleString() + '</b>');
//-->
</script>
</body>
</html>
| Steve Jones wrote: | Couldn't a small bit of javascript be added that would accomplish this? Me saying this and I have no idea what I am talking about!!
| Alan Stone wrote: | We have multiple LCDs at a console, and usually one is dedicated to displaying a browser
with the local ELog. Meanwhile, others are making entries from another machine. If
no one clicks on refresh, the ELog display becomes stale. Is there a method to have
the ELog reload every X minutes?
Thanks, Alan |
|
|
|
Re: Auto-refresh ELog display, posted by Alan Stone on Thu Aug 24 20:16:23 2006
|
I appreciate your posting of the JavaScript. However, I have no idea what
to do with it. The page appears to be generated by some elog daemon. I do
not know how to hook into that.
Alan
| Steve Jones wrote: | Couldn't a small bit of javascript be added that would accomplish this? Me saying this and I have no idea what I am talking about!!
| Alan Stone wrote: | We have multiple LCDs at a console, and usually one is dedicated to displaying a browser
with the local ELog. Meanwhile, others are making entries from another machine. If
no one clicks on refresh, the ELog display becomes stale. Is there a method to have
the ELog reload every X minutes?
Thanks, Alan |
|
|
|
Re: Auto-refresh ELog display, posted by Steve Jones on Fri Aug 25 05:27:13 2006
|
eLog allows one to add custom headers or footers as well as include Cascading Style Sheets. I believe there is a post somewhere in here from Stefan indicating that javascript can be added through one of these methods . . . hold on, a simple search, yes Stefan mentions it at http://midas.psi.ch/elogs/Forum/1837
| Alan Stone wrote: | I appreciate your posting of the JavaScript. However, I have no idea what
to do with it. The page appears to be generated by some elog daemon. I do
not know how to hook into that.
Alan
| Steve Jones wrote: | Couldn't a small bit of javascript be added that would accomplish this? Me saying this and I have no idea what I am talking about!!
| Alan Stone wrote: | We have multiple LCDs at a console, and usually one is dedicated to displaying a browser
with the local ELog. Meanwhile, others are making entries from another machine. If
no one clicks on refresh, the ELog display becomes stale. Is there a method to have
the ELog reload every X minutes?
Thanks, Alan |
|
|
|
|
Re: Auto-refresh ELog display, posted by Stefan Ritt on Mon Sep 11 16:32:52 2006
|
| Alan Stone wrote: | We have multiple LCDs at a console, and usually one is dedicated to displaying a browser
with the local ELog. Meanwhile, others are making entries from another machine. If
no one clicks on refresh, the ELog display becomes stale. Is there a method to have
the ELog reload every X minutes?
Thanks, Alan |
The JavaScript is one possibility as Steve mentioned correctly. Another possibility is to use the RSS feed capability of ELOG. Use any RSS reader, and it will notify you immediately if there is a new entry in ELOG. Have a look at http://midas.psi.ch/elog/config.html and search for RSS on how to configure this. |
elog perl script and the command prompt and eof, posted by Arno Teunisse on Thu Sep 7 22:06:00 2006
|
hello
Just wrote a quick and dirty perl script ( See Attachment ) that let's you enter a record into the database. Put it into the directory where the config file is located. It look's at the "attributes = " and the "required attributes = "
within a section in the elog configuration file. The script is using elog.exe to accomplish this.
One problem with the script is that you must press Control_Z ( ^Z ) to store the data into the database.
Does anybody know how to prevent this ? It works also when redirecting the data into the script with a file input.txt. ( add2elog.pl confgi.cfg logbook < input.txt )
I Know this is NOT an elog question but maybe someone is happy with the script and has the answer for me. |
|
reply option in elog client not working, posted by Gerald Ebberink on Tue Aug 22 11:31:11 2006
|
When I try to make a reply with the following command
elog -v -h hostname -p 80 -l 'logbook wannabe' -u 'guess' 'what' -a 'Phase=During Measuring' -a Author='Gerald Ebberink' -a 'Subject=Octave measurements' -n 1 -f '22-Aug-2006 boxplot hole sizes of panel2SqTop.jpg' -f '22-Aug-2006 boxplot hole area of panel2SqTop.jpg' -f '22-Aug-2006 boxplot POA of panel2SqTop.jpg' -f '22-Aug-2006 boxplot hole sizes of panel2RTop.jpg' -f '22-Aug-2006 boxplot hole area of panel2RTop.jpg' -f '22-Aug-2006 boxplot POA of panel2RTop.jpg' -f '22-Aug-2006 boxplot hole sizes of panel6SqTop.jpg' -f '22-Aug-2006 boxplot hole area of panel6SqTop.jpg' -f '22-Aug-2006 boxplot POA of panel6SqTop.jpg' -f '22-Aug-2006 boxplot comparison of POA.jpg' -r 65 'Automated addition of measurment results (png)'
In verbose mode I found that the main difference is that
with the -r option it wants to go to the following url
Location: http://host/logbook/
and without it goes to
Location http://host/logbook+wannabe/66
my best guess would be that it should also point to logbook+wannabe |
|
Re: reply option in elog client not working, posted by Gerald Ebberink on Wed Sep 6 12:02:52 2006
|
| Today I found, I have the same problem with editing the log (with the -e option) |
|
Re: reply option in elog client not working, posted by Gerald Ebberink on Thu Sep 7 08:01:37 2006
|
I have made patch witch solves the problem partialy.
If there are not no attachments this patch works.... (But since I have attachments I'll have to dig in deeper in the code.
Attached you will find the diff. |
|
Re: reply option in elog client not working, posted by Gerald Ebberink on Thu Sep 7 17:17:17 2006
|
| Gerald Ebberink wrote: | I have made patch witch solves the problem partialy.
If there are not no attachments this patch works.... (But since I have attachments I'll have to dig in deeper in the code.
Attached you will find the diff. |
Now I am digging deeper, and I have a question:
In the function retrive_elog near line 427 a start is made with putting the attributes in an array.
As far as I can see there is no exception for the Attachment attribute. Where this attribute can be very large (e.g. many files attached) and overrun to the boundary variable (in the function submit_elog function). At least that is where I find end of my attachment string.
Could Mr. Ritt please shine some light on this, becouse I |
Corrupt page link, posted by Ulrich Trüssel on Wed Jun 21 14:21:01 2006
|
If a loggbook contains more than one page of entries, above and under the list are links for changing the page by number (or privous / last and all) conatining links looking like "http://localhost:8080/logbook/page2?mode=mode". This is the correct link and will work until Version 2.6.1-5!
In Version 2.6.1-6 the link is corrupted and look always like "http://localhost:8080/logbook/pag" |
|
Re: Corrupt page link, posted by Stefan Ritt on Wed Jun 21 17:03:23 2006
|
| Ulrich Trüssel wrote: | If a loggbook contains more than one page of entries, above and under the list are links for changing the page by number (or privous / last and all) conatining links looking like "http://localhost:8080/logbook/page2?mode=mode". This is the correct link and will work until Version 2.6.1-5!
In Version 2.6.1-6 the link is corrupted and look always like "http://localhost:8080/logbook/pag" |
Well, in this forum the link is fine, so it must have to do with your special configuration. Can you try with the demo logbook and find out which configuration option causes this problem? |
|
Re: Corrupt page link, posted by Arno Teunisse on Wed Jul 5 00:18:29 2006
|
| Ulrich Trüssel wrote: | If a loggbook contains more than one page of entries, above and under the list are links for changing the page by number (or privous / last and all) conatining links looking like "http://localhost:8080/logbook/page2?mode=mode". This is the correct link and will work until Version 2.6.1-5!
In Version 2.6.1-6 the link is corrupted and look always like "http://localhost:8080/logbook/pag" |
In this version, the above is true. It also has corrupted entries when clicking : Full | Summary | Threaded.
On MSExplorer and Firefox only a part of the link is shown in the left-down corner of the browser :
http://localhost:8080/?mo
No matter what button you click.
It should be : http://localhost:8080/?mode=full
http://localhost:8080/?mode=Summary
http://localhost:8080/?mode=Attachments
I'v tested is with the default elogd.cfg file which comes with the installation.
Something is going wrong here.
When importing a csv text file the above is introduced also.
Just installed the previous version :
====================================
[C:\Program Files\ELOG]elogd -c elogd.cfg
elogd 2.6.1 built May 24 2006, 08:59:09 revision 1688
Indexing logbooks ... done
Server listening on port 8080 ...
And the problem is gone. !!!!
problem is in version :
==========================
[C:\Program Files\ELOG1]elogd -c elogd.cfg
elogd 2.6.1 built Jun 13 2006, 08:43:21 revision 1691
Indexing logbooks ... done
Server listening on port 8080 ...
I love elog , for it's simplicity,
but will not upgrade to the lastest release untill this is solved. |
|
Re: Corrupt page link, posted by Stefan Ritt on Wed Jul 5 12:51:25 2006
|
| Arno Teunisse wrote: | Just installed the previous version :
====================================
[C:\Program Files\ELOG]elogd -c elogd.cfg
elogd 2.6.1 built May 24 2006, 08:59:09 revision 1688
Indexing logbooks ... done
Server listening on port 8080 ...
And the problem is gone. !!!!
problem is in version :
==========================
[C:\Program Files\ELOG1]elogd -c elogd.cfg
elogd 2.6.1 built Jun 13 2006, 08:43:21 revision 1691
Indexing logbooks ... done
Server listening on port 8080 ...
|
Thanks for your detailed information. The hint with the two different revisions heally helped. I fixed that in revision 1695, and made an intermediate release 2.6.1-7. This will fix the problem. Can you please check that this is working? |
|
Re: Corrupt page link, posted by Arno Teunisse on Sun Sep 3 23:16:31 2006
|
| Stefan Ritt wrote: |
| Arno Teunisse wrote: | Just installed the previous version :
====================================
[C:\Program Files\ELOG]elogd -c elogd.cfg
elogd 2.6.1 built May 24 2006, 08:59:09 revision 1688
Indexing logbooks ... done
Server listening on port 8080 ...
And the problem is gone. !!!!
problem is in version :
==========================
[C:\Program Files\ELOG1]elogd -c elogd.cfg
elogd 2.6.1 built Jun 13 2006, 08:43:21 revision 1691
Indexing logbooks ... done
Server listening on port 8080 ...
|
Thanks for your detailed information. The hint with the two different revisions heally helped. I fixed that in revision 1695, and made an intermediate release 2.6.1-7. This will fix the problem. Can you please check that this is working? |
Sorry for my ( very ) late answer , But yes the problem is GONE after installing the new release? Thanks. |
|
Access to global configuration in v2.6.1, posted by Giorgio Croci Candiani on Thu Jan 19 15:02:38 2006
|
Hi,
I just installed v.2.6.1 coming from the previous 2.6.0 (on Win2000)
When I access the "configuration" function from a logbook, in the cfg page I only see two buttons in the header
(save or cancel); in the previous version I saw more buttons there ("global config", "create new logbook" and so
on), so here I'm unable to access global configuration or logbook management (except for current logbook options).
I am logged in as admin (actually I have a single-user configuration, thus no particular users defined).
I hope this report may be helpful, and not just being caused by a misunderstanding on my side ;)
Thanks
GiorgioCC |
|
Re: Access to global configuration in v2.6.1, posted by Stefan Ritt on Thu Jan 19 15:23:02 2006
|
> I just installed v.2.6.1 coming from the previous 2.6.0 (on Win2000)
> When I access the "configuration" function from a logbook, in the cfg page I only see two buttons in the header
> (save or cancel); in the previous version I saw more buttons there ("global config", "create new logbook" and so
> on), so here I'm unable to access global configuration or logbook management (except for current logbook options).
I tried to reproduce your problem, but could not. In my windows installation it looks fine. You only see the
(save and cancel) buttons only if you go to "Change [global]", otherwise you see the "Change [global]", "Delete
this logbook" etc. buttons. Have you tried with the default elogd.cfg which comes from the distribution? |
|
Re: Access to global configuration in v2.6.1, posted by Giorgio Croci Candiani on Sat Jan 21 14:02:57 2006
|
> I tried to reproduce your problem, but could not. In my windows installation it looks fine. You only see the
> (save and cancel) buttons only if you go to "Change [global]", otherwise you see the "Change [global]", "Delete
> this logbook" etc. buttons. Have you tried with the default elogd.cfg which comes from the distribution?
Yes, I tried that. Maybe I'll have some other try on other PCs and investigate further, I'll surely let you know. Thanks
for the prompt response and compliments for your very good work! ELog is really a great piece of software. |
|
Re: Access to global configuration in v2.6.1, posted by Giorgio Croci Candiani on Wed Jan 25 01:08:06 2006
|
> > I just installed v.2.6.1 coming from the previous 2.6.0 (on Win2000)
> > When I access the "configuration" function from a logbook, in the cfg page I only see two buttons in the header
> > (save or cancel); in the previous version I saw more buttons there ("global config", "create new logbook" and so
> > on), so here I'm unable to access global configuration or logbook management (except for current logbook options).
>
> I tried to reproduce your problem, but could not. In my windows installation it looks fine. You only see the
> (save and cancel) buttons only if you go to "Change [global]", otherwise you see the "Change [global]", "Delete
> this logbook" etc. buttons. Have you tried with the default elogd.cfg which comes from the distribution?
Here I am again... I built and installed v2.6.1 also on a different system, this time on linux; i tried both with the
existing cfg file and with the new cfg.
Choosing "configuration", I still only see the current logbook configuration file section with "Save" and "cancel"
buttons, no access to global config whatsoever; the same as I saw on windows version. I tried version 2.6.1-1622.
Regards
Giorgio |
|
Re: Access to global configuration in v2.6.1, posted by Stefan Ritt on Wed Jan 25 08:24:28 2006
|
> Here I am again... I built and installed v2.6.1 also on a different system, this time on linux; i tried both
with the
> existing cfg file and with the new cfg.
> Choosing "configuration", I still only see the current logbook configuration file section with "Save" and "cancel"
> buttons, no access to global config whatsoever; the same as I saw on windows version. I tried version 2.6.1-1622.
I tried again, using the configuration file from the distribution (elog:1627/1). Hitting "config", I see the picture
attached (elog:1627/2). So it's a mystery why it is different in your case... |
|
Re: Access to global configuration in v2.6.1, posted by Giorgio Croci Candiani on Wed Jan 25 12:08:13 2006
|
> I tried again, using the configuration file from the distribution (elog:1627/1). Hitting "config", I see the picture
> attached (elog:1627/2). So it's a mystery why it is different in your case...
Indeed... I peeked into the code, and I got the feeling it could be a matter of incorrect user setup (though I have no
users/authorizations defined at all) or maybe browser cookies. A thin trail, but I'll try some debug directly on the
code and, should I come up with something, I'll surely notice you.
Thanks for your support! |
|
Re: Access to global configuration in v2.6.1, posted by Stefan Ritt on Wed Jan 25 12:10:46 2006
|
> or maybe browser cookies.
That rings a bell. If you change user permissions (like password file/no password file/rename logbooks) you might be
fooled by old cookies. Just delete all cookies in your browser and try again. |
|
Re: Access to global configuration in v2.6.1, posted by Giorgio Croci Candiani on Tue Mar 14 17:11:10 2006
|
> > or maybe browser cookies.
>
> That rings a bell. If you change user permissions (like password file/no password file/rename logbooks) you might be
> fooled by old cookies. Just delete all cookies in your browser and try again.
Hi,
here I am at it again. Since my first posts, I tried to install the latest version of elog out-of-the-box on one pair of
PCs from scratch (fresh elog install on new, just-installed PCs, OS WinXP Pro and Win2000), but with no results. No
trace of the global configuration menu or the buttons to reach it.
Neither taking a look at the code has helped, I could not figure out exactly where the button bar was generated.
Didn't anybody other point out a similar behaviour? Do you have any suggestion for any tests to carry out?
Thanks
GiorgioCC |
|
Re: Access to global configuration in v2.6.1, posted by Giorgio Croci Candiani on Tue Aug 29 15:16:31 2006
|
Hi,
after a long time, I thought I could try to investigate the code some further,
and maybe I found some hint.
The page where I expected the options to show was (probably) the one generated by this function:
void show_admin_page(LOGBOOK * lbs, char *top_group)
Inside, it, the buttons are generated by following code snippets:
(elogd.c:10443)
if (is_admin_user_global(getparam("unm"))) {
sprintf(str, loc("Change %s"), "[global]");
rsprintf("<input type=submit name=cmd value=\"%s\">\n", str);
}
(elogd.c:10461)
if (is_admin_user("global", getparam("unm"))) {
rsprintf("<input type=submit name=cmd value=\"%s\">\n", loc("Delete this logbook"));
rsprintf("<input type=submit name=cmd value=\"%s\">\n", loc("Rename this logbook"));
rsprintf("<input type=submit name=cmd value=\"%s\">\n", loc("Create new logbook"));
}
The functions called to validate the user are following:
(elogd.c:21298)
BOOL is_admin_user(char *logbook, char *user):
//...
if (user == NULL)
return FALSE;
(elogd.c:21324)
BOOL is_admin_user_global(char *user)
{
//...
if (user == NULL)
return FALSE;
Since I assume that I'm probably in the "userless" case (no users are defined in the configuration,
and no usernames are set when launching elog either), I would understand that this causes the options for
global config editing etc etc not to be shown on the admin page.
In my opinion (and given that my interpretation of the code flow isn't wrong), the "null"
user should be indeed considered admin, at least as long as no user management is defined whatsoever.
(If I got it right, if user==NULL, but a password file exists, user management is applied,
thus we're in the case of anonymous user which is correctly not admin).
Again, I might be wrong, but I would be curious to hear an opinion from you about this issue.
Thanks again for your attention.
GiorgioCC |
|