Re: Password setting having somewhat bizarre results.

From: Dinesh Kumar <dinesh(dot)kumar(at)enterprisedb(dot)com>
To: Dave Page <dpage(at)pgadmin(dot)org>
Cc: "pgadmin-support(at)postgresql(dot)org" <pgadmin-support(at)postgresql(dot)org>, John Foelster <johnfoelster(at)comcast(dot)net>
Subject: Re: Password setting having somewhat bizarre results.
Date: 2013-08-30 15:33:01
Message-ID: CAKWsr7gMC5tw-9_VBJEAe=Cq_8Saiw19HtTjznfGbpqO+qqsmA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgadmin-support

H
i Dave,

On Fri, Aug 30, 2013 at 8:58 PM, Dave Page <dpage(at)pgadmin(dot)org> wrote:

> Hi
>
>
> On Fri, Aug 30, 2013 at 4:18 PM, Dinesh Kumar <
> dinesh(dot)kumar(at)enterprisedb(dot)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. :(

> Thanks.
>
> --
> Dave Page
> Blog: http://pgsnake.blogspot.com
> Twitter: @pgsnake
>
> EnterpriseDB UK: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
>

In response to

Responses

Browse pgadmin-support by date

  From Date Subject
Next Message Dave Page 2013-08-30 15:38:34 Re: Password setting having somewhat bizarre results.
Previous Message Dave Page 2013-08-30 15:28:18 Re: Password setting having somewhat bizarre results.