Joe D'Souza wrote:
**
Yes I would correct it directly at DB level since its not a really
critical error and only a data issue... since that date field is not a
part of the user_cache, it doesn't matter if you correct it from the
DB level as you do not have to modify the corresponding entry in the
user_cache table to sync the information from the user schema to its
cache..
Thanks Joe. Though I'll need to read some more before I really
understand that.
That leaves me with two problems in Remedy:
1) the date field is not set correctly, but set to epoch-zero, when a
password is changed.
2) Remedy is generating an error from a perfectly valid date.
To debug, I edited the User form to make that Last-Password-Change date
field read/write and show date and time (don't hide time).
Surprisingly, this was enough to stop the error message, without
changing any data.
The date now reads "1/01/1970 8:00:00 AM" (ie midnight GMT) , which is
accepted, where "1/01/1970" is not.
It seems that remedy is getting rather confused over the use of dates vs
date/time-stamp.
For some reason (seems odd to me), it is parsing the displayed (rather
than full underlying) value of the read-only date field "1/01/1970" in
my local time zone, and converting it to a POSIX timestamp, which fails
(or yields a negative number?).
i.e. inconsist (and unnecessary?) forward and back-conversion, turns a
'zero' date into a negative one.
This bug will not show up for those of you behind GMT.
Now I just have to figure out #1) above. Why is the date field being set
wrongly?
At first glance the workflow is just setting the field to $DATE$ - how
can that go wrong?
I've just been told that all this is new in 7.1, and I should go look
for the latest patch.
Whats the chances that this is related to date-format in locale?
regards, Mike
Cheers
Joe
-----Original Message-----
From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] Behalf Of Mike
Sent: Tuesday, December 18, 2007 11:09 PM
To: [email protected]
Subject: ARS7.1 User Form, "Last Password change for policy" date
"1/01/1970" invalid and read-only.
Hi, newbie here,
I have installed the 7.1 server on Win32 with MS-SQL and midtier.
When I tried to make a change to the 'Demo' user in the User form of the
admin console, I get an error:
"Format of date or time value is not recognized. : Last Password Change
For Policy (ARERR 9376)"
The value is "1/01/1970", possibly an integer 0 or 1 in the database?
While wrong, it hardly seems invalid. But I'm not allowed to make any
changes to the request.
I was able to create a new user, and that field was blank. But after I
set a password for the new user (login and password link from home
page), the user also has a "1/01/1970" value in that field, so the
record cannot be edited.
1) Why is the date not being set correctly (to today)? or how would i
try to find out?
2) Why is that date invalid? Maybe I'm not seeing the real bad value. Is
it that string that is bad, or an ARS bug that shows that date for
invalid values? (same problem in midtier and ARS_User.)
3) How do you generally deal with read-only invalid fields? Must I talk
SQL direct to the database?
regards, Mike
__20060125_______________________This posting was submitted with HTML
in it___
_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
