Thread: Password setting having somewhat bizarre results.

OK. I have done a quick test in my local windows 7.

1. I have logged into PG 9.2 as a super user("postgres").
2. Created new login role by performing right click on "Login Role" - > "Create New Login".

3. Entered the new login name and password.

4. Disconnected from pgAdmin and re-logged in the pgAdmin using above created logins, and i am able to connect.

Kindly let me know, if this approach what i have followed is improper.

 

This is exactly the method I followed.  We are talking about Windows 8 on my end, so that may throw a monkey wrench in the works.  I think I had the new OS option “cause confusing errors with non MS products” set to no.  Then and again, they somehow thought this iPad emulation nonsense was a good thing in a desktop OS, so…  (I’m actually considering using Valve’s Steam to emulate the programs menu…)

 

I am now using trusted connection, with the following being the relevant lines in the pg_hba.conf:

# Trusted IPv4 local connections:

host    all             postgres             127.0.0.1/32            trust

# Trusted IPv6 local connections:

host    all             postgres             ::1/128                 trust

# IPv4 local connections:

#host    all             all             127.0.0.1/32            md5

# IPv6 local connections:

#host    all             all             ::1/128                 md5

 

I can login with postgres with any old password.  Swapping back to MD5 and using the original password or what I thought I replaced it with both don’t work.  So I’m deducing that the password reset functionality is working, it’s just setting it to something other than the string I expected.  Hence my suspicion of the MD5 encryption, specifically that working with Microsoft too long has left me with little idea what it’s doing.

 

As a test I used the steps you outline above to create user dkumar with the password “swordfish”.  I grabbed the SQL command pgAdmin generated and it is as follows:

CREATE ROLE dkumar LOGIN ENCRYPTED PASSWORD 'md5efa0693f2cdca3392667d2961c3e2412'

   VALID UNTIL 'infinity';

 

Switching out to md5 authentication again, the following happens when I login via these credentials.

 

SUCCESS???

 

OK, now that’s weird.  It’s always the non-reproducible errors that are the most annoying.  You get no functionality and look like a hallucinating idiot.

 

Let’s see if we can fix postgres with the same extremely questionable password.  dkumar was made as punyuser, so I have to go back to trusted for a second.

 

ALTER ROLE postgres ENCRYPTED PASSWORD 'md5397e0cb3e3821859b1e9cb12438f3778';

 

The password authentication failed on login.

 

Let’s try that again on the off chance that I’ve gone stark raving mad and can’t spell “swordfish” consistently.

 

ALTER ROLE postgres ENCRYPTED PASSWORD 'md5397e0cb3e3821859b1e9cb12438f3778';

 

Just for kicks let’s try altering dkumar to “swordfish”, just because I’m curious as to what the hash will look like…

 

ALTER ROLE dkumar ENCRYPTED PASSWORD 'md5efa0693f2cdca3392667d2961c3e2412'

   VALID UNTIL '1969-12-31 00:00:00';

 

OK then… 

 

There was a superuser I made for myself, let’s see if the hash is consistent between users or usertypes…

 

ALTER ROLE jfoelster ENCRYPTED PASSWORD 'md534dce0915caecb1ff675ec5648f39a6e';

 

OK then.  The hash must come from the combination of user and password.

 

Let’s turn md5 back on and see who we can log in with now…

 

Now all three fail out on password authentication…

 

I think that merits a good healthy bit of puzzlement from my end.  It seems to like CREATE ROLE and hate ALTER ROLE, maybe?  Or perhaps it’s some kind of gypsy curse?

Not being quite sure how to get jpegs into my Comcast space, it’s been a while since I had to share a screen cap, I just sent seven to you and the list as an attachment.  The message bounced back from the list… are you, Dinesh, in receipt?

Hi John,

Thank you very much for sharing the details. Yes i got the screen shots.

Let me summarize the problem and will try to find the proper fix for this issue after discussing this with our senior team members.

Thank you once again, have a great day.

Dinesh

-- 
Dinesh Kumar

Software Engineer

Ph: +918087463317

Skype ID: dinesh.kumar432

www.enterprisedb.com

Follow us on Twitter
@EnterpriseDB 

Visit EnterpriseDB for tutorials, webinars, whitepapers and more

On Tue, Aug 13, 2013 at 4:28 PM, John Foelster <johnfoelster@comcast.net> wrote:

Not being quite sure how to get jpegs into my Comcast space, it’s been a while since I had to share a screen cap, I just sent seven to you and the list as an attachment.  The message bounced back from the list… are you, Dinesh, in receipt?

Hi Dave,

Further to my analysis on this issue, it's only get re-produced on the installed pgAdmin. Where as in the local debug mode, it's working as expected.

Actual Issue
-----------------

When the role's authentication timeout is "infinity", then as per the logic we don't set any value to the "Account Expires" calendar box. If we have only the valid date/time, then only we do set this box with proper values. This is working fine as expected in the debug mode of pgAdmin.

Where as in the installed pgAdmin, when the authentication timeout is "infinity" then it's setting the "Account Expires" calendar box with the Unix Epoch time in Windows 7 and (Unix Epoch time -1) in Windows 8.

I have verified the code for the any variables those have not been initialized properly. Unfortunately, i am not able to find  of those. I believe, the following value "wxInvalidDateTime.m_time" from datetime.h is giving different value in the installed pgAdmin.

inline bool IsValid() const { return m_time != wxInvalidDateTime.m_time; }

Hence, i have added one more condition in the dlgRole.cpp file to avoid this case. Please find the fix for this issue.

And also, looking forward for your suggestions and inputs.

Thanks in advance.

Dinesh

-- 
Dinesh Kumar

Software Engineer

Ph: +918087463317

Skype ID: dinesh.kumar432

www.enterprisedb.com

Follow us on Twitter
@EnterpriseDB 

Visit EnterpriseDB for tutorials, webinars, whitepapers and more

On Tue, Aug 13, 2013 at 4:58 PM, Dinesh Kumar <dinesh.kumar@enterprisedb.com> wrote:

Hi John,

Thank you very much for sharing the details. Yes i got the screen shots.

Let me summarize the problem and will try to find the proper fix for this issue after discussing this with our senior team members.

Thank you once again, have a great day.

Dinesh

-- 
Dinesh Kumar

Software Engineer

Ph: +918087463317

Skype ID: dinesh.kumar432

www.enterprisedb.com

Follow us on Twitter
@EnterpriseDB 

Visit EnterpriseDB for tutorials, webinars, whitepapers and more

On Tue, Aug 13, 2013 at 4:28 PM, John Foelster <johnfoelster@comcast.net> wrote:

Not being quite sure how to get jpegs into my Comcast space, it’s been a while since I had to share a screen cap, I just sent seven to you and the list as an attachment.  The message bounced back from the list… are you, Dinesh, in receipt?

Hello,

 

Gesendet: Dienstag, 20. August 2013 um 09:32 Uhr
Von: "Dave Page" <dpage@pgadmin.org>
An: "Dinesh Kumar" <dinesh.kumar@enterprisedb.com>
Cc: "pgadmin-support@postgresql.org" <pgadmin-support@postgresql.org>, "John Foelster" <johnfoelster@comcast.net>, "Dhiraj Chawla" <dhiraj.chawla@enterprisedb.com>
Betreff: Re: [pgadmin-support] Password setting having somewhat bizarre results.

Thanks Dinesh - patch applied.

 

I noticed one other issue in the role dialogue that I'd like you or Dhiraj to look at please. On my Mac, if I open the properties for a role with no VALID UNTIL date set, it's setting the date in the dialogue to the current date and generating the SQL to make that change. It should leave the date empty of course, and not generate any SQL until the user actually changes something.

 

it's the very same on Windows.

 

Best regards,

 

Peter

Hi Dave/Jan-Peter,

Could you confirm that, are you facing the issue with the debug version of pgAdmin. With the installed pgAdmin, i too facing the problem but the date is setting to 1970. But the debug pgAdmin is doing fine in my windows 7.

Looking forward for your inputs.

Thanks in advance.

Dinesh

-- 
Dinesh Kumar

Software Engineer

Ph: +918087463317

Skype ID: dinesh.kumar432

www.enterprisedb.com

Follow us on Twitter
@EnterpriseDB 

Visit EnterpriseDB for tutorials, webinars, whitepapers and more

On Mon, Aug 26, 2013 at 5:28 PM, Jan-Peter Seifert <Jan-Peter.Seifert@gmx.de> wrote:

Hello,

 

Gesendet: Dienstag, 20. August 2013 um 09:32 Uhr
Von: "Dave Page" <dpage@pgadmin.org>
An: "Dinesh Kumar" <dinesh.kumar@enterprisedb.com>
Cc: "pgadmin-support@postgresql.org" <pgadmin-support@postgresql.org>, "John Foelster" <johnfoelster@comcast.net>, "Dhiraj Chawla" <dhiraj.chawla@enterprisedb.com>
Betreff: Re: [pgadmin-support] Password setting having somewhat bizarre results.

Thanks Dinesh - patch applied.

 

I noticed one other issue in the role dialogue that I'd like you or Dhiraj to look at please. On my Mac, if I open the properties for a role with no VALID UNTIL date set, it's setting the date in the dialogue to the current date and generating the SQL to make that change. It should leave the date empty of course, and not generate any SQL until the user actually changes something.

 

it's the very same on Windows.

 

Best regards,

 

Peter

Hi

On Thu, Aug 29, 2013 at 1:01 PM, Dinesh Kumar <dinesh.kumar@enterprisedb.com> wrote:

Hi Dave,

Sorry for the delay on this issue.

Yes, i am able to reproduce the problem in Linux but not in windows. I am attaching the fix for this issue. After applying this fix, the behaviour in windows and linux are same.

Kindly let me know if i miss anything here.

Still not quite right I'm afraid. If I open a user account with no pre-existing expiry, then the dialogue will try to execute:

ALTER ROLE rolename

   VALID UNTIL 'infinity';

 As I haven't changed anything on the dialogue, it shouldn't try to make any changes (or, enable the OK button). Also, the dialogue itself shows the current date - it should be blank. If I choose a date - then it still tries to set the expiry to infinity!

Tested on Mac. 

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

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

On Thu, Aug 29, 2013 at 4:28 PM, Dinesh Kumar <dinesh.kumar@enterprisedb.com> wrote:

H

i Dave,

On Thu, Aug 29, 2013 at 7:29 AM, Dave Page <dpage@pgadmin.org> wrote:

Hi

On Thu, Aug 29, 2013 at 1:01 PM, Dinesh Kumar <dinesh.kumar@enterprisedb.com> wrote:

Hi Dave,

Sorry for the delay on this issue.

Yes, i am able to reproduce the problem in Linux but not in windows. I am attaching the fix for this issue. After applying this fix, the behaviour in windows and linux are same.

Kindly let me know if i miss anything here.

Still not quite right I'm afraid. If I open a user account with no pre-existing expiry, then the dialogue will try to execute:

ALTER ROLE rolename

   VALID UNTIL 'infinity';

 As I haven't changed anything on the dialogue, it shouldn't try to make any changes (or, enable the OK button). Also, the dialogue itself shows the current date - it should be blank. If I choose a date - then it still tries to set the expiry to infinity!

Tested on Mac.

 

 Thanks for your inputs. In the current implementation, if the "calender control" doesn't have a proper value, then we do add "infinity" to the sql statement. It's the same case, in the edit/creating a role.

I am not sure, whether we need to follow this implementation or not. I mean, adding "infinity" to the end of sql statement if the calender control value is an empty.

But, i have removed this "infinity" condition and attaching the patch.

Infinity is correct, but:

- The SQL to set it should only be generated if the user has opened the dialogue and removed any existing value. If the role is already set to infinite expiration, then it shouldn't be set again.

- Obviously this requires the ability to clear that value, and to display is as a blank value in the event that you create a new role (it should default to infinity) or if opening an existing role that is already set that way.

If the control doesn't allow you to clear the value, then maybe we need to add a checkbox for infinite, and when un-checked, the user is able to select a date and time, otherwise not. 

Thanks.

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

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

Hi

On Thu, Aug 29, 2013 at 6:07 PM, Dinesh Kumar <dinesh.kumar@enterprisedb.com> wrote:

H

i Dave,

On Thu, Aug 29, 2013 at 8:32 AM, Dave Page <dpage@pgadmin.org> wrote:

On Thu, Aug 29, 2013 at 4:28 PM, Dinesh Kumar <dinesh.kumar@enterprisedb.com> wrote:

H

i Dave,

On Thu, Aug 29, 2013 at 7:29 AM, Dave Page <dpage@pgadmin.org> wrote:

Hi

On Thu, Aug 29, 2013 at 1:01 PM, Dinesh Kumar <dinesh.kumar@enterprisedb.com> wrote:

Hi Dave,

Sorry for the delay on this issue.

Yes, i am able to reproduce the problem in Linux but not in windows. I am attaching the fix for this issue. After applying this fix, the behaviour in windows and linux are same.

Kindly let me know if i miss anything here.

Still not quite right I'm afraid. If I open a user account with no pre-existing expiry, then the dialogue will try to execute:

ALTER ROLE rolename

   VALID UNTIL 'infinity';

 As I haven't changed anything on the dialogue, it shouldn't try to make any changes (or, enable the OK button). Also, the dialogue itself shows the current date - it should be blank. If I choose a date - then it still tries to set the expiry to infinity!

Tested on Mac.

 

 Thanks for your inputs. In the current implementation, if the "calender control" doesn't have a proper value, then we do add "infinity" to the sql statement. It's the same case, in the edit/creating a role.

I am not sure, whether we need to follow this implementation or not. I mean, adding "infinity" to the end of sql statement if the calender control value is an empty.

But, i have removed this "infinity" condition and attaching the patch.

Infinity is correct, but:

- The SQL to set it should only be generated if the user has opened the dialogue and removed any existing value. If the role is already set to infinite expiration, then it shouldn't be set again.

- Obviously this requires the ability to clear that value, and to display is as a blank value in the event that you create a new role (it should default to infinity) or if opening an existing role that is already set that way.

If the control doesn't allow you to clear the value, then maybe we need to add a checkbox for infinite, and when un-checked, the user is able to select a date and time, otherwise not. 

Thanks.

Thanks for the suggestions. Please find the attached the patch for the same.

Let me know if i miss anything here.

Thanks in advance.

OK, that seems much better, but unfortunately still not quite perfect. I spot two issues:

- 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.

- If I clear the date and time, SQL is not generated to reset the valid until time to infinity.

Thanks. 

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

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

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

Hi Dave,

I have setup the mac build for testing this case.

Further to my observation, if we perform the multiple "delete operations" like 2 to 3 on the same date control, then it's behaving as expected. I have tried a lot to figure out the cause why it's not raising an Event of EVT_CALANDER_SEL_CHANGED, EVT_DATE_CHANGED on mac for the single "delete operation", but unable to find out the reason.

I will work on this parallel and will update you the status very soon.

Thanks for your time.
 

Dinesh

-- 
Dinesh Kumar

Software Engineer

Ph: +918087463317

Skype ID: dinesh.kumar432

www.enterprisedb.com

Follow us on Twitter
@EnterpriseDB 

Visit EnterpriseDB for tutorials, webinars, whitepapers and more

On Fri, Aug 30, 2013 at 9:08 PM, Dave Page <dpage@pgadmin.org> wrote:

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

Hi Dave,

Today, i have spend some time on this issue. But not able to figure out why the event is not raising on single "delete" operation on the data control combo box. I have tried to debug the wxMac's "src/generic/datectlg.cpp", "OnText" method which is working fine in Linux but not in mac. But no luck.

Hence, like to request you to share your valuable suggestions.

Thanks in advance.

Dinesh

-- 
Dinesh Kumar

Software Engineer

Ph: +918087463317

Skype ID: dinesh.kumar432

www.enterprisedb.com

Follow us on Twitter
@EnterpriseDB 

Visit EnterpriseDB for tutorials, webinars, whitepapers and more

On Sat, Sep 7, 2013 at 12:09 AM, Dinesh Kumar <dinesh.kumar@enterprisedb.com> wrote:

Hi Dave,

I have setup the mac build for testing this case.

Further to my observation, if we perform the multiple "delete operations" like 2 to 3 on the same date control, then it's behaving as expected. I have tried a lot to figure out the cause why it's not raising an Event of EVT_CALANDER_SEL_CHANGED, EVT_DATE_CHANGED on mac for the single "delete operation", but unable to find out the reason.

I will work on this parallel and will update you the status very soon.

Thanks for your time.
 

Dinesh

-- 
Dinesh Kumar

Software Engineer

Ph: +918087463317

Skype ID: dinesh.kumar432

www.enterprisedb.com

Follow us on Twitter
@EnterpriseDB 

Visit EnterpriseDB for tutorials, webinars, whitepapers and more

On Fri, Aug 30, 2013 at 9:08 PM, Dave Page <dpage@pgadmin.org> wrote:

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

FYI, I've asked Dinesh to confer with one of the other devs at EDB on this for now, as I'm not sure when I'm likely to be able to look in more depth myself due to other commitments.

On Tue, Sep 24, 2013 at 7:21 PM, Dinesh Kumar <dinesh.kumar@enterprisedb.com> wrote:

Hi Dave,

Today, i have spend some time on this issue. But not able to figure out why the event is not raising on single "delete" operation on the data control combo box. I have tried to debug the wxMac's "src/generic/datectlg.cpp", "OnText" method which is working fine in Linux but not in mac. But no luck.

Hence, like to request you to share your valuable suggestions.

Thanks in advance.

Dinesh

-- 
Dinesh Kumar

Software Engineer

Ph: +918087463317

Skype ID: dinesh.kumar432

www.enterprisedb.com

Follow us on Twitter
@EnterpriseDB 

Visit EnterpriseDB for tutorials, webinars, whitepapers and more

On Sat, Sep 7, 2013 at 12:09 AM, Dinesh Kumar <dinesh.kumar@enterprisedb.com> wrote:

Hi Dave,

I have setup the mac build for testing this case.

Further to my observation, if we perform the multiple "delete operations" like 2 to 3 on the same date control, then it's behaving as expected. I have tried a lot to figure out the cause why it's not raising an Event of EVT_CALANDER_SEL_CHANGED, EVT_DATE_CHANGED on mac for the single "delete operation", but unable to find out the reason.

I will work on this parallel and will update you the status very soon.

Thanks for your time.
 

Dinesh

-- 
Dinesh Kumar

Software Engineer

Ph: +918087463317

Skype ID: dinesh.kumar432

www.enterprisedb.com

Follow us on Twitter
@EnterpriseDB 

Visit EnterpriseDB for tutorials, webinars, whitepapers and more

On Fri, Aug 30, 2013 at 9:08 PM, Dave Page <dpage@pgadmin.org> wrote:

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

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

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

HI Dave,

Sorry for the delay on this issue.

Further to my investigation, it's a kind of BUG with "datoepickerctrl" in wxMac. When we do the below steps

1. Select all the contents in "Account Expire Text Box".

2. Press "Delete", then it's not raising any of the EVENT. It's not raising EVT_TEXT also.

3. If we press "Delete" again, then it's raising the "EVT_CAL_SELCHANGED", "EVT_DATE_CHANGED".

It's the strange behavior i observed in wxMac.

To overcome this issue in wxMac, i have added two more CHILD_FOCUS events, which is working fine.

Please find the updated patch for this issue, and let me know your inputs.

I have tested this in all windows, linux, and Mac.

Thanks in advance.

Dinesh

-- 
Dinesh Kumar

Software Engineer

Ph: +918087463317

Skype ID: dinesh.kumar432

www.enterprisedb.com

Follow us on Twitter
@EnterpriseDB 

Visit EnterpriseDB for tutorials, webinars, whitepapers and more

On Wed, Sep 25, 2013 at 7:14 PM, Dave Page <dpage@pgadmin.org> wrote:

FYI, I've asked Dinesh to confer with one of the other devs at EDB on this for now, as I'm not sure when I'm likely to be able to look in more depth myself due to other commitments.

On Tue, Sep 24, 2013 at 7:21 PM, Dinesh Kumar <dinesh.kumar@enterprisedb.com> wrote:

Hi Dave,

Today, i have spend some time on this issue. But not able to figure out why the event is not raising on single "delete" operation on the data control combo box. I have tried to debug the wxMac's "src/generic/datectlg.cpp", "OnText" method which is working fine in Linux but not in mac. But no luck.

Hence, like to request you to share your valuable suggestions.

Thanks in advance.

Dinesh

-- 
Dinesh Kumar

Software Engineer

Ph: +918087463317

Skype ID: dinesh.kumar432

www.enterprisedb.com

Follow us on Twitter
@EnterpriseDB 

Visit EnterpriseDB for tutorials, webinars, whitepapers and more

On Sat, Sep 7, 2013 at 12:09 AM, Dinesh Kumar <dinesh.kumar@enterprisedb.com> wrote:

Hi Dave,

I have setup the mac build for testing this case.

Further to my observation, if we perform the multiple "delete operations" like 2 to 3 on the same date control, then it's behaving as expected. I have tried a lot to figure out the cause why it's not raising an Event of EVT_CALANDER_SEL_CHANGED, EVT_DATE_CHANGED on mac for the single "delete operation", but unable to find out the reason.

I will work on this parallel and will update you the status very soon.

Thanks for your time.
 

Dinesh

-- 
Dinesh Kumar

Software Engineer

Ph: +918087463317

Skype ID: dinesh.kumar432

www.enterprisedb.com

Follow us on Twitter
@EnterpriseDB 

Visit EnterpriseDB for tutorials, webinars, whitepapers and more

On Fri, Aug 30, 2013 at 9:08 PM, Dave Page <dpage@pgadmin.org> wrote:

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

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

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