Date in CSV and XML in UNIX time, posted by PJ Meyer on Fri Jul 22 03:15:29 2005
|
Q: How can dates be exported correctly in CSV and XML?
In windows version I'm getting the Unix seconds since 1970.
XML export:
<DATE>Wed Jun 22 08:29:58 2005</DATE>
<Date_Needed>1119384000</Date_Needed>
<Date_Added>1119470400</Date_Added>
the date record added is good and readable, the two user defined dates are Unix and not real useful in Excel.
Same behavior is the CSV file, the date record added is good, the two user defined dates are Unix seconds.
Now when E-log emails the records all the dates are good - ie readable dates.
So what can be done to make all the dates look like dates? |
Re: Date in CSV and XML in UNIX time, posted by Stefan Ritt on Fri Jul 22 08:56:20 2005
|
| PJ Meyer wrote: | | So what can be done to make all the dates look like dates? |
Simply upgrade to 2.6.0beta where this problem has been solved. |
|
Re: Date in CSV and XML in UNIX time, posted by PJ Meyer on Mon Jul 25 19:15:33 2005
|
| Stefan Ritt wrote: |
| PJ Meyer wrote: | | So what can be done to make all the dates look like dates? |
Simply upgrade to 2.6.0beta where this problem has been solved. |
I did upgrade to "2.60-beta2" of the Windows binaries - June 16th date stamps on Elog.exe and Elogd.exe.
I'm still getting dates that are in "Unix time"
Anything else? |
|
Re: Date in CSV and XML in UNIX time, posted by Stefan Ritt on Mon Jul 25 20:20:18 2005
|
| PJ Meyer wrote: |
| Stefan Ritt wrote: |
| PJ Meyer wrote: | | So what can be done to make all the dates look like dates? |
Simply upgrade to 2.6.0beta where this problem has been solved. |
I did upgrade to "2.60-beta2" of the Windows binaries - June 16th date stamps on Elog.exe and Elogd.exe.
I'm still getting dates that are in "Unix time"
Anything else? |
I just tried again myself. Put following into elgod.cfg:
[demo]
Attributes = Author, Category, Arrival
Type Arrival = Date
type in one entry, did a XML extract, and got
<?xml version="1.0" encoding="ISO-8859-1"?>
<!-- ELOGD Version 2.6.0-beta2 export.xml -->
<ELOG_LIST>
<ENTRY>
<MID>1</MID>
<DATE>Fri Jul 22 22:50:34 2005</DATE>
<Author>sr</Author>
<Category>Problem</Category>
<Arrival>7/25/2005</Arrival>
<TEXT></TEXT>
</ENTRY>
</ELOG_LIST>
where the date looks ok. So what do you do differently? |
|
Re: Date in CSV and XML in UNIX time, posted by PJ Meyer on Mon Jul 25 22:27:06 2005
|
| Stefan Ritt wrote: |
| PJ Meyer wrote: |
| Stefan Ritt wrote: |
| PJ Meyer wrote: | | So what can be done to make all the dates look like dates? |
Simply upgrade to 2.6.0beta where this problem has been solved. |
I did upgrade to "2.60-beta2" of the Windows binaries - June 16th date stamps on Elog.exe and Elogd.exe.
I'm still getting dates that are in "Unix time"
Anything else? |
I just tried again myself. Put following into elgod.cfg:
[demo]
Attributes = Author, Category, Arrival
Type Arrival = Date
type in one entry, did a XML extract, and got
<?xml version="1.0" encoding="ISO-8859-1"?>
<!-- ELOGD Version 2.6.0-beta2 export.xml -->
<ELOG_LIST>
<ENTRY>
<MID>1</MID>
<DATE>Fri Jul 22 22:50:34 2005</DATE>
<Author>sr</Author>
<Category>Problem</Category>
<Arrival>7/25/2005</Arrival>
<TEXT></TEXT>
</ENTRY>
</ELOG_LIST>
where the date looks ok. So what do you do differently? |
Not sure where we differ....
My cfg:
Attributes = System, Requestor, Title, Priority, Date Needed, Type, Also Notify, Subsystem, Status, Work Order, Assigned To, Team Lead, Percent Complete, Estimated Hrs, Actual Hrs, Date Added, Expected Delivery, Date Completed, Notifications, Completed
Options Priority = A-Emergency{p1}, B-Critical{p2}, C-High{p3}, D-Medium{p4}, E-Low{p5}
Preset Priority = D-Medium
Type Date Needed = Date
XML Extract:
<?xml version="1.0" encoding="ISO-8859-1"?>
<!-- ELOGD Version 2.6.0-beta2 export.xml -->
<ELOG_LIST>
<ENTRY>
<MID>585</MID>
<DATE>Wed Jun 22 08:29:58 2005</DATE>
<System>SDWIS</System>
<Requestor>Other...</Requestor>
<Title>EDI rejects report to George WAUN</Title>
<Priority>B-Critical</Priority>
<Date_Needed>1119384000</Date_Needed>
Q: could it be the spaces in Attribute name????
Or the differences between Linux and Windows ports? |
|
Re: Date in CSV and XML in UNIX time, posted by Stefan Ritt on Tue Jul 26 09:25:40 2005
|
| PJ Meyer wrote: | Q: could it be the spaces in Attribute name????
Or the differences between Linux and Windows ports? |
I tried following elogd.cfg:
[global]
port = 8080
[demo]
Attributes = System, Requestor, Title, Priority, Date Needed, Type, Also Notify, Subsystem, Status, Work Order, Assigned To, Team Lead, Percent Complete, Estimated Hrs, Actual Hrs, Date Added, Expected Delivery, Date Completed, Notifications, Completed
Options Priority = A-Emergency{p1}, B-Critical{p2}, C-High{p3}, D-Medium{p4}, E-Low{p5}
Preset Priority = D-Medium
Type Date Needed = Date
and got
<?xml version="1.0" encoding="ISO-8859-1"?>
<!-- ELOGD Version 2.6.0-beta2 export.xml -->
<ELOG_LIST>
<ENTRY>
<MID>2</MID>
<DATE>Tue Jul 26 09:10:33 2005</DATE>
<System>s</System>
<Requestor>r</Requestor>
<Title>t</Title>
<Priority>D-Medium</Priority>
<Date_Needed>07/26/05</Date_Needed>
<Type></Type>
<Also_Notify></Also_Notify>
<Subsystem></Subsystem>
<Status></Status>
<Work_Order></Work_Order>
<Assigned_To></Assigned_To>
<Team_Lead></Team_Lead>
<Percent_Complete></Percent_Complete>
<Estimated_Hrs></Estimated_Hrs>
<Actual_Hrs></Actual_Hrs>
<Date_Added></Date_Added>
<Expected_Delivery></Expected_Delivery>
<Date_Completed></Date_Completed>
<Notifications></Notifications>
<Completed></Completed>
<TEXT></TEXT>
</ENTRY>
</ELOG_LIST>
So I have the blank in the attribute, and I tried it both under windows and linux. I looked again at the code, and am pretty sure you run an old version. So I made a 2.6.0beta3 windows binaries, with which you could try it again. |
|
Literal comma in elogd.conf entries where "," is an item separator?, posted by Chris Green on Mon Jul 25 19:24:47 2005
|
Hi,
Could you tell me if there is a way to escape characters in elogd.conf? Particularly, I want to have a drop-down "Keyword" attribute where one of the options is "Spelling, grammar and typos.". This invariably gets split into "Spelling" and "grammar and typos". I've tried "\,", ",,", "%," and "%27", to no avail.
Can I get there from here, or do I have to go someplace else?
Thanks,
Chris. |
|
Re: Literal comma in elogd.conf entries where "," is an item separator?, posted by Stefan Ritt on Mon Jul 25 20:25:26 2005
|
| Chris Green wrote: | | Could you tell me if there is a way to escape characters in elogd.conf? Particularly, I want to have a drop-down "Keyword" attribute where one of the options is "Spelling, grammar and typos.". This invariably gets split into "Spelling" and "grammar and typos". I've tried "\,", ",,", "%," and "%27", to no avail. |
Just put it in quotations, like
Options Keyword = "Spelling, grammar and typos", Other
that will do the job. |
|
Re: Literal comma in elogd.conf entries where "," is an item separator?, posted by Chris Green on Mon Jul 25 21:41:00 2005
|
Sorry for being dense. Thanks for this,
Chris. |
A new ELOG user wants to register on "127.0.0.1", posted by Emiliano Gabrielli on Thu Jul 14 15:58:07 2005
|
A new ELOG user wants to register on "127.0.0.1"
the scenario is:
- elog on localhost
- stunnel on the external interface
I dont want elog to listen on external interface, so.. why do not use the URL cfg attribute for this issue ? |
|
Re: A new ELOG user wants to register on "127.0.0.1", posted by Stefan Ritt on Thu Jul 14 17:29:42 2005
|
| Emiliano Gabrielli wrote: | A new ELOG user wants to register on "127.0.0.1"
the scenario is:
- elog on localhost
- stunnel on the external interface
I dont want elog to listen on external interface, so.. why do not use the URL cfg attribute for this issue ? |
You can specify the interface to liste on with the "-n <interface>" parameter of elogd. |
|
Re: A new ELOG user wants to register on "127.0.0.1", posted by Emiliano Gabrielli on Thu Jul 14 19:16:06 2005
|
| Stefan Ritt wrote: |
| Emiliano Gabrielli wrote: | A new ELOG user wants to register on "127.0.0.1"
the scenario is:
- elog on localhost
- stunnel on the external interface
I dont want elog to listen on external interface, so.. why do not use the URL cfg attribute for this issue ? |
You can specify the interface to liste on with the "-n <interface>" parameter of elogd. |
I know 
the following is the configuration I'm telling about... and it raises the problem reported
albert@YYYYYYYYY:~$ ps axu | grep elog
elog 22348 1.0 1.9 23660 20408 ? Ss 11:32 4:54 /usr/sbin/elogd -f /var/run/elogd.pid -c /etc/elog.conf -d /var/lib/elog -s /usr/share/elog -p 8081 -n 127.0.0.1 -x -D
root 22353 0.0 0.2 45436 2276 ? Ss 11:32 0:17 /usr/sbin/stunnel -o /var/log/elog/elog_daemon.log -p /etc/ssl/certs/stunnel_XXXXXXX.pem -d XXXXXX.roma2.infn.it:8080 -r 127.0.0.1:8081
|
|
Re: A new ELOG user wants to register on "127.0.0.1", posted by Stefan Ritt on Sat Jul 23 15:46:06 2005
|
Ok, I kind of misunderstood the "-n" parameter. It is the interface to listen to, which is not necessarily the host name as seen from outside. I changed that in the following way:
- if the URL option is present, the host name is taken from there
- if the URL option is not present, elog calls gethostname()/gethostbyname() to retrieve the local host name
the host name which comes from these two possibilities is used internally in all cases where it's needed, like email notifications. |
Display Subject and HTML tags, regression, posted by Emiliano Gabrielli on Mon Jul 18 10:16:35 2005
|
rev 1.703 makes the following code not to work:
Display Subject = <b>$subject</b>
the <b> tag is displayed and not interpreted, as it was in previous revisions.. |
|
Re: Display Subject and HTML tags, regression, posted by Emiliano Gabrielli on Mon Jul 18 18:36:32 2005
|
| Emiliano Gabrielli wrote: | rev 1.703 makes the following code not to work:
Display Subject = <b>$subject</b>
the <b> tag is displayed and not interpreted, as it was in previous revisions.. |
this patch should fix the problem .. a little bug still remain, if you insert some allowed HTML tags in the subject this is detected by is_html() so the Display Attribute and the Link is not applied .. the result is that the HTML is working but no elog featur is applied |
|
Re: Display Subject and HTML tags, regression, posted by Stefan Ritt on Wed Jul 20 22:39:05 2005
|
| Emiliano Gabrielli wrote: |
| Emiliano Gabrielli wrote: | rev 1.703 makes the following code not to work:
Display Subject = <b>$subject</b>
the <b> tag is displayed and not interpreted, as it was in previous revisions.. |
this patch should fix the problem .. a little bug still remain, if you insert some allowed HTML tags in the subject this is detected by is_html() so the Display Attribute and the Link is not applied .. the result is that the HTML is working but no elog featur is applied |
Your line
if (p && strchr(str, '>') && p >= str && *(p-1) != '\\')
in the code does not work. If the pattern is at the beginning of the string (p == str), then (p-1) points to an invalid location and can cause a segmentation fault. The correct patch is in CVS. |
|
Re: Display Subject and HTML tags, regression, posted by Emiliano Gabrielli on Thu Jul 21 11:02:44 2005
|
| Stefan Ritt wrote: |
| Emiliano Gabrielli wrote: |
| Emiliano Gabrielli wrote: | rev 1.703 makes the following code not to work:
Display Subject = <b>$subject</b>
the <b> tag is displayed and not interpreted, as it was in previous revisions.. |
this patch should fix the problem .. a little bug still remain, if you insert some allowed HTML tags in the subject this is detected by is_html() so the Display Attribute and the Link is not applied .. the result is that the HTML is working but no elog featur is applied |
Your line
if (p && strchr(str, '>') && p >= str && *(p-1) != '\\')
in the code does not work. If the pattern is at the beginning of the string (p == str), then (p-1) points to an invalid location and can cause a segmentation fault. The correct patch is in CVS. |
ehhe, I used "should" infact  |
|
Re: Display Subject and HTML tags, regression, posted by Stefan Ritt on Wed Jul 20 22:28:14 2005
|
| Emiliano Gabrielli wrote: | rev 1.703 makes the following code not to work:
Display Subject = <b>$subject</b>
the <b> tag is displayed and not interpreted, as it was in previous revisions.. |
rev. 1.707 makes it work again  |
|
Re: Display Subject and HTML tags, regression, posted by Emiliano Gabrielli on Thu Jul 21 11:00:47 2005
|
| Stefan Ritt wrote: |
| Emiliano Gabrielli wrote: | rev 1.703 makes the following code not to work:
Display Subject = <b>$subject</b>
the <b> tag is displayed and not interpreted, as it was in previous revisions.. |
rev. 1.707 makes it work again |
ok, nice |
|
[code] should be a sort of <CDATA >, posted by Emiliano Gabrielli on Wed Jul 13 15:09:48 2005
|
Using the [code] elocode should be intended also to preserve the tagged text from beeing parsed as html or elcode itself ..
this is an example:
| Quote: | Note that, for security reasons, you should check the MD5 FINGERPRINT of the SSL certificate issued by the server agaist the following one:
MD5 Fingerprint = 23:A7:AD:33:3C:08:BE:2A:62:6E:85:DF:B8:00:23:40
Thank you |
|
|
Re: [code] should be a sort of <CDATA >, posted by Stefan Ritt on Wed Jul 20 21:43:56 2005
|
| Emiliano Gabrielli wrote: | Using the [code] elocode should be intended also to preserve the tagged text from beeing parsed as html or elcode itself ..
this is an example:
| Quote: | Note that, for security reasons, you should check the MD5 FINGERPRINT of the SSL certificate issued by the server agaist the following one:
MD5 Fingerprint = 23:A7:AD:33:3C:08:BE:2A:62:6E:85:DF:B8:00:23:40
Thank you |
|
As you can see, your entry with the [code] section is now shown without interpretation. So everything between [code] and [/code] is not interpreted as ELCode tags. The modification is committed to CVS. |
|
Re: [code] should be a sort of <CDATA >, posted by Emiliano Gabrielli on Thu Jul 21 10:59:22 2005
|
| Stefan Ritt wrote: |
| Emiliano Gabrielli wrote: | Using the [code] elocode should be intended also to preserve the tagged text from beeing parsed as html or elcode itself ..
this is an example:
| Quote: | Note that, for security reasons, you should check the MD5 FINGERPRINT of the SSL certificate issued by the server agaist the following one:
MD5 Fingerprint = 23:A7:AD:33:3C:08:BE:2A:62:6E:85:DF:B8:00:23:40
Thank you |
|
As you can see, your entry with the [code] section is now shown without interpretation. So everything between [code] and [/code] is not interpreted as ELCode tags. The modification is committed to CVS. |
thanks |
|
elog utility for submission used wrong 'Host:' in POST header, posted by Heiko Scheit on Mon Jul 11 19:04:38 2005
|
The 'elog' utility for commandline submission used wrong 'Host:' in POST header.
The host listed after 'Host:' should be the host where the server runs, not the
localhost (see patch below).
$ diff -u elog.c_20050711 elog.c
--- elog.c_20050711 Mon Jul 11 18:54:20 2005
+++ elog.c Mon Jul 11 18:55:31 2005
@@ -421,7 +421,7 @@
sprintf(request + strlen(request), "%s/%d?cmd=download", experiment, message_id);
strcat(request, " HTTP/1.0\r\n");
- sprintf(request + strlen(request), "Host: %s\r\n", host_name);
+ sprintf(request + strlen(request), "Host: %s\r\n", host);
sprintf(request + strlen(request), "User-Agent: ELOG\r\n");
first = 1;
@@ -872,7 +872,7 @@
strcat(request, " HTTP/1.0\r\n");
sprintf(request + strlen(request), "Content-Type: multipart/form-data; boundary=%s\r\n", boundary);
- sprintf(request + strlen(request), "Host: %s\r\n", host_name);
+ sprintf(request + strlen(request), "Host: %s\r\n", host);
sprintf(request + strlen(request), "User-Agent: ELOG\r\n");
sprintf(request + strlen(request), "Content-Length: %d\r\n", content_length); |
|
Re: elog utility for submission used wrong 'Host:' in POST header, posted by Emiliano Gabrielli on Tue Jul 12 10:15:30 2005
|
> The 'elog' utility for commandline submission used wrong 'Host:' in POST header.
> The host listed after 'Host:' should be the host where the server runs, not the
> localhost (see patch below).
>
> $ diff -u elog.c_20050711 elog.c
> --- elog.c_20050711 Mon Jul 11 18:54:20 2005
> +++ elog.c Mon Jul 11 18:55:31 2005
> @@ -421,7 +421,7 @@
> sprintf(request + strlen(request), "%s/%d?cmd=download", experiment, message_id);
> strcat(request, " HTTP/1.0\r\n");
>
> - sprintf(request + strlen(request), "Host: %s\r\n", host_name);
> + sprintf(request + strlen(request), "Host: %s\r\n", host);
> sprintf(request + strlen(request), "User-Agent: ELOG\r\n");
>
> first = 1;
> @@ -872,7 +872,7 @@
> strcat(request, " HTTP/1.0\r\n");
>
> sprintf(request + strlen(request), "Content-Type: multipart/form-data; boundary=%s\r\n", boundary);
> - sprintf(request + strlen(request), "Host: %s\r\n", host_name);
> + sprintf(request + strlen(request), "Host: %s\r\n", host);
> sprintf(request + strlen(request), "User-Agent: ELOG\r\n");
> sprintf(request + strlen(request), "Content-Length: %d\r\n", content_length);
This is not completally true IMHO .. better, it is, but it is not the only problem.
Elog seems to speak HTML/1.0, where "host:" is not implemented ... Since ELOG does not support Vhosts I think the right beaviour is to remove the "Host:" header at all ...
On the other hand it should replay with an error when a bogus client tries to speak HTML/1.0 specifing "host:",
and (the wrost case) when the bogus client says to speak HTML/1.1 and doesnt provide the required "Host:" header ...
Yes .. elog will ignore it, but it is an RFC requirement for HTML/1.1 ! |
|
Re: elog utility for submission used wrong 'Host:' in POST header, posted by Stefan Ritt on Wed Jul 20 21:03:29 2005
|
| Emiliano Gabrielli wrote: | This is not completally true IMHO .. better, it is, but it is not the only problem.
Elog seems to speak HTML/1.0, where "host:" is not implemented ... Since ELOG does not support Vhosts I think the right beaviour is to remove the "Host:" header at all ... |
So I remove the Host: ... line at all, I hope this is ok with everybody. |
Cannot stat() config file , posted by Stefan Rudat on Wed Jul 20 08:32:06 2005
|
Hi
Elog runs now for serveral month without any problem at a Windows 2000 server.
I must change the access rights for all Folders, remove the user everyone and set the
Rights only to defined groups .
Now I can see following Event ID
Event Type: Information
Event Source: ELOG
Event Category: None
Event ID: 0
Date: 20.07.2005
Time: 08:14:24
User: N/A
Computer: SNDSRV1
Description:
The description for Event ID ( 0 ) in Source ( ELOG ) cannot be found.
The local computer may not have the necessary registry information or message DLL files to display messages from a remote computer. The following information is part of the event: Cannot stat() config file; No such file or directory.
My question now. Have someone see the same Problem ?
It this is a access right problem How to set up the access rights for Elog
Elog folders ?
Bye |
|
Re: Cannot stat() config file , posted by Stefan Ritt on Wed Jul 20 20:13:26 2005
|
| Stefan Rudat wrote: | | Cannot stat() config file; No such file or directory. |
I do not know what exactly is going on. This error occurs during runtime when elog tries to check if the config file (usually elogd.cfg) has changed. It checks if the file is there on startup, but apparently it is there, otherwise elog would not start. Then it checks about once per second if the file access time has changed. If so, it rereads the file. This way changes to the file become valid immediately, without restarting elog. The fact that elog has access to the file on startup, but not later, is somehow strange. Maybe you lock this file with an editor, or it is on a network drive which gets disconnected, or the permission changed after the startup. Something in that direction. |
|
short/long_name should point the same user, posted by Emiliano Gabrielli on Thu Jul 14 12:47:06 2005
|
.. I mean that if I use:
Restrict edit = 1
; preset author and email
Preset Author = $short_name
Preset Author Email = $user_email
Preset on reply Author = $short_name
Preset on reply Author Email = $user_email
Subst on reply subject = Re: $subject
; these attributes cannot be changed
Locked Attributes = Author, Author Email
and then I change Preset Author to be "$long_name" Elog does not permit the autor to edit an old post of its own ...
It is not able to argue that short and long name are the same person..
Yes I know, you'll ask me why I should change it .. the anwer is.. I don't have to, but (as I could do it logically) I'd like to be able to do..
In my case I changed it by error, people inserted entries and now I restored the correct one .. so now I have to unlock the attribute and change every Author by hand as admin
|
|
Re: short/long_name should point the same user, posted by Emiliano Gabrielli on Thu Jul 14 13:05:33 2005
|
| Emiliano Gabrielli wrote: | .. I mean that if I use:
Restrict edit = 1
; preset author and email
Preset Author = $short_name
Preset Author Email = $user_email
Preset on reply Author = $short_name
Preset on reply Author Email = $user_email
Subst on reply subject = Re: $subject
; these attributes cannot be changed
Locked Attributes = Author, Author Email
and then I change Preset Author to be "$long_name" Elog does not permit the autor to edit an old post of its own ...
It is not able to argue that short and long name are the same person..
Yes I know, you'll ask me why I should change it .. the anwer is.. I don't have to, but (as I could do it logically) I'd like to be able to do..
In my case I changed it by error, people inserted entries and now I restored the correct one .. so now I have to unlock the attribute and change every Author by hand as admin
|
a problem related to this issue is that an attribute of userlist type automatically sets the user to be in the long form..
My proposal is to alwais store users in the long form and anly give the possibility to use the short or long form in displaing time.. |
|
Re: short/long_name should point the same user, posted by Stefan Ritt on Thu Jul 14 17:34:12 2005
|
| Emiliano Gabrielli wrote: | In my case I changed it by error, people inserted entries and now I restored the correct one .. so now I have to unlock the attribute and change every Author by hand as admin
|
Well, that teaches you not to do this error again  |
|
Re: short/long_name should point the same user, posted by Emiliano Gabrielli on Thu Jul 14 19:11:54 2005
|
| Stefan Ritt wrote: |
| Emiliano Gabrielli wrote: | In my case I changed it by error, people inserted entries and now I restored the correct one .. so now I have to unlock the attribute and change every Author by hand as admin
|
Well, that teaches you not to do this error again |
uhm.. I think the confusion intrinsict in elog between long and short name is something to be solved ..
an attribute of type "userlist" fills always with the long_name .. but if I would to insert it as short ?
the users shown in the users admin dropdown menu is short .. why? .. may be I didnt understood the way this issue works ..  |
|
Re: short/long_name should point the same user, posted by Stefan Ritt on Thu Jul 14 20:24:07 2005
|
| Emiliano Gabrielli wrote: | uhm.. I think the confusion intrinsict in elog between long and short name is something to be solved ..
an attribute of type "userlist" fills always with the long_name .. but if I would to insert it as short ?
the users shown in the users admin dropdown menu is short .. why? .. may be I didnt understood the way this issue works .. |
The "short name" is the equivalent to the unix login name. Under /etc/passwd, you have a login (short) name and a "full" (long) name. The first may not contain blanks, must be unique, while the second is more like a "real" name. This concept has been adapted in elog. While many people use cryptic or abbreviated login names, it's still nice know the real name, like if you get an email notification from someone. The userlist fills with the long_name because people refer to other people in the logbook usually with the real name (sometimes they even don't know the people's login name). The admin dropdown menu uses the short names because you look at the user database more from an administration point of view. Like if you edit /etc/passwd, you first look at the login name, not the full one. Maybe what one could add is to make the full name in the admin page a dropdown list as well, so the admin can either select the short or the long name. Another item for the wishlist |
|
Re: short/long_name should point the same user, posted by Emiliano Gabrielli on Fri Jul 15 15:03:01 2005
|
| Stefan Ritt wrote: |
| Emiliano Gabrielli wrote: | uhm.. I think the confusion intrinsict in elog between long and short name is something to be solved ..
an attribute of type "userlist" fills always with the long_name .. but if I would to insert it as short ?
the users shown in the users admin dropdown menu is short .. why? .. may be I didnt understood the way this issue works .. |
The "short name" is the equivalent to the unix login name. Under /etc/passwd, you have a login (short) name and a "full" (long) name. The first may not contain blanks, must be unique, while the second is more like a "real" name. This concept has been adapted in elog. While many people use cryptic or abbreviated login names, it's still nice know the real name, like if you get an email notification from someone. The userlist fills with the long_name because people refer to other people in the logbook usually with the real name (sometimes they even don't know the people's login name). The admin dropdown menu uses the short names because you look at the user database more from an administration point of view. Like if you edit /etc/passwd, you first look at the login name, not the full one. Maybe what one could add is to make the full name in the admin page a dropdown list as well, so the admin can either select the short or the long name. Another item for the wishlist |
uhmm .. what I am talking about is something simpler ... It seems to me that elog does not use always the "login name" but somethins refers to the "gecos" ... What I'm askinf for is to separe the login name (to which elog has to refer for everything internally) and the long/short_name mechanism that should be a mere display issue ...
May be that it is the same to ask for the introdution of a "user_id" or to treat the login name as the uid, .. the "Author" field should be filled both with the long and the short name (and it is so now!) but, when checking the original author on a Edit action, aelog as to check always the actual logged *short* name against the original Author *short* name .. becoise is only the short name that should have a sense for messages .. the long one is only a nice reminder
Hope my english makes me to be understod now |
|