Re: Password setting having somewhat bizarre results. - Mailing list pgadmin-support

From Dave Page
Subject Re: Password setting having somewhat bizarre results.
Date
Msg-id CA+OCxoxq7P3a5zoMMHxUC_qbV3eNee=-B-6pFd0S30wB30e+-A@mail.gmail.com
Whole thread Raw
In response to Re: Password setting having somewhat bizarre results.  (Dinesh Kumar <dinesh.kumar@enterprisedb.com>)
Responses Re: Password setting having somewhat bizarre results.  (Dinesh Kumar <dinesh.kumar@enterprisedb.com>)
Re: Password setting having somewhat bizarre results.  ("Jan-Peter Seifert" <Jan-Peter.Seifert@gmx.de>)
List pgadmin-support
On Fri, Aug 30, 2013 at 4:33 PM, Dinesh Kumar
<dinesh.kumar@enterprisedb.com> wrote:
> H
> i Dave,
>
>
> On Fri, Aug 30, 2013 at 8:58 PM, Dave Page <dpage@pgadmin.org> wrote:
>>
>> Hi
>>
>>
>> On Fri, Aug 30, 2013 at 4:18 PM, Dinesh Kumar
>> <dinesh.kumar@enterprisedb.com> wrote:
>>>>
>>>>
>>>>
>>>> - Changing the time, but not the date, on an existing expiration
>>>> datetime, doesn't generate SQL and enable the OK button. Changing just the
>>>> date does.
>>>
>>>
>>> Apologies Dave. I am not able to explain you the problem properly. But
>>> below are my findings.
>>>
>>> Further to my observation, it's not generating the event of
>>>
>>> EVT_SPIN(XRCID("timValidUntil"), dlgRole::OnChangeSpin)
>>>
>>> which is in pg_Roles.cpp. If the spin event occurs on spin button, then
>>> it's directly going to
>>> "EVT_SPIN_x" in timespin.cpp. And also, i have observed that
>>> wxTimeSpinCtrl is our custom data type which we have been derived from the
>>> wxControl class. That may be the reason the spin control event is directly
>>> refering  to  timespin.cpp's EVT_SPIN_x functions. I have fixed this issue
>>> by appending an dlgRole's event to timespin.cpp's event and it is working
>>> fine.
>>>
>>> Kindly let me know if anything is unclear.
>>
>>
>> OK, that seems reasonable. Did you check if it breaks any other usage of
>> that control?
>>
>
> Thanks Dave. I will verify this.
>
>> I wonder if, for 1.20, we should think about adding a 3rd party (or
>> creating a new) datetime control that we can use universally.
>>
>
>
> Yes true.
>
>>>
>>>>
>>>>
>>>> - If I clear the date and time, SQL is not generated to reset the valid
>>>> until time to infinity.
>>>>
>>>
>>> If the role's "rolvaliduntil" property is NULL or infinity then there is
>>> no password expiration for that user/role. I believe, in your case the
>>> "rolvaliduntil" might be the NULL. Hence, it's not generating any "VALID
>>> UNTIL 'infinity'" since, NULL ~ infinity and also we haven't changed
>>> anything. In the rest of the cases, i believe it will generate as you
>>> suggested.
>>>
>>> Kindly let me know if i miss anything here.
>>
>>
>> Yeah, I think you misunderstood me:
>>
>
>
>>
>> 1) Create a new role, and set VALID UNTIL to some value. Close the
>> dialogue.
>>
>> 2) Open the properties dialogue, then clear the date/time fields. That
>> should cause the dialogue to attempt to set VALID UNTIL to infinity, but
>> doesn't.
>>
>
> Sorry Dave. :(
>
> I am not able to re-produce the above case in windows/Linux. I don't have
> mac setup to test this. :(

Hmm, OK - it seems it does work on Windows. Well, maybe this is a good
time for you to setup a Mac build environment :-).


-- 
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgadmin-support by date:

Previous
From: Dinesh Kumar
Date:
Subject: Re: Password setting having somewhat bizarre results.
Next
From: arthur.tomica@tomicasoft.de
Date:
Subject: PgAdmin Guru Hints on Windows blank