Re: [pgadmin][patch] [GreenPlum] When user press Explain Plan and Explain analyze plan an error is displayed

[Akshay Joshi]

Hi Victoria,

In "is_new_transaction_required.js" file I have modified the code and
handled both "responseJSON" and "axios" responses, but in your patch you
have removed "responseJSON" part which is required because "i
*s_new_transaction_required*()" function is also called from sqleditor.js
with normal javascript response.

I have re-added that code and also found one issue where "from
pgadmin.utils.exception
import ConnectionLost" statement is missing from "web/pgadmin/utils
/driver/psycopg2/server_manager.py" file, so I added that too.

Attached is the modified patch.

On Wed, Mar 21, 2018 at 2:09 AM, Victoria Henry  wrote:

> Hi Hackers,
>
> We fixed the tests and refactored some of the code.  All tests pass now.
> Attached is the reviewed patch.
>
> Sincerely,
>
> Joao and Victoria
>
> On Tue, Mar 20, 2018 at 10:05 AM, Dave Page 
> wrote:
>
>> Hi
>>
>> This doesn't pass the Javascript tests for me. Please investigate ASAP:
>>
>> webpack: Compiled successfully.
>> HeadlessChrome 0.0.0 (Mac OS X 10.12.6): Executed 152 of 486 SUCCESS (0
>> secs / 0 secs)
>> HeadlessChrome 0.0.0 (Mac OS X 10.12.6): Executed 153 of 486 SUCCESS (0
>> secs / 0 secs)
>> HeadlessChrome 0.0.0 (Mac OS X 10.12.6): Executed 154 of 486 SUCCESS (0
>> secs / 0 secs)
>> HeadlessChrome 0.0.0 (Mac OS X 10.12.6): Executed 155 of 486 SUCCESS (0
>> secs / 0 secs)
>> HeadlessChrome 0.0.0 (Mac OS X 10.12.6): Executed 156 of 486 SUCCESS (0
>> secs / 0 secs)
>> HeadlessChrome 0.0.0 (Mac OS X 10.12.6): Executed 157 of 486 SUCCESS (0
>> secs / 0 secs)
>> HeadlessChrome 0.0.0 (Mac OS X 10.12.6): Executed 158 of 486 SUCCESS (0
>> secs / 0 secs)
>> HeadlessChrome 0.0.0 (Mac OS X 10.12.6) ExecuteQuery #poll when SQLEditor
>> is the query tool when an error occur when the connection to the server was
>> lost when JSON response is available when login is not required should
>> highlight the error in the SQL panel FAILED
>> Expected spy SqlEditor._highlight_error to have been called with [ 'Some
>> error in JSON' ] but it was never called.
>> at regression/javascript/sqleditor/execute_query_spec.js:11753:58
>> HeadlessChrome 0.0.0 (Mac OS X 10.12.6): Executed 285 of 486 (1 FAILED)
>> (0 secs / 0 secs)
>> HeadlessChrome 0.0.0 (Mac OS X 10.12.6) ExecuteQuery #poll when SQLEditor
>> is the query tool when an error occur when the connection to the server was
>> lost when JSON response is available when login is not required should
>> highlight the error in the SQL panel FAILED
>> Expected spy SqlEditor._highlight_error to have been called with [ 'Some
>> error in JSON' ] but it was never called.
>> HeadlessChrome 0.0.0 (Mac OS X 10.12.6) ExecuteQuery #poll when SQLEditor
>> is the query tool when an error occur when the connection to the server was
>> lost when JSON response is available when login is not required should add
>> new entry to history and update the Messages tab FAILED
>> Expected spy SqlEditor.update_msg_history to have been called with [
>> false, 'Some error in JSON' ] but it was never called.
>> at regression/javascript/sqleditor/execute_query_spec.js:11760:60
>> HeadlessChrome 0.0.0 (Mac OS X 10.12.6): Executed 286 of 486 (2 FAILED)
>> (0 secs / 0 secs)
>> HeadlessChrome 0.0.0 (Mac OS X 10.12.6) ExecuteQuery #poll when SQLEditor
>> is the query tool when an error occur when the connection to the server was
>> lost when JSON response is available when login is not required should add
>> new entry to history and update the Messages tab FAILED
>> Expected spy SqlEditor.update_msg_history to have been called with [
>> false, 'Some error in JSON' ] but it was never called.
>> HeadlessChrome 0.0.0 (Mac OS X 10.12.6) ExecuteQuery #poll when SQLEditor
>> is the query tool when an error occur when the connection to the server was
>> lost when JSON response is available when login is required should login is
>> displayed FAILED
>> Expected spy UserManagement.pga_login to have been called.
>> at regression/javascript/sqleditor/execute_query_spec.js:11840:56
>> HeadlessChrome 0.0.0 (Mac OS X 10.12.6): Executed 296 of 486 (3 FAILED)
>> (0 secs / 0 secs)
>> HeadlessChrome 0.0.0 (Mac OS X 10.12.6) ExecuteQuery #poll when SQLEditor
>> is the query tool when an error occur when the connection to the server was
>> lost when JSON response is available when login is required should login is
>> displayed FAILED
>> Expected spy UserManagement.pga_login to have been called.
>> HeadlessChrome 0.0.0 (Mac OS X 10.12.6) ExecuteQuery #poll when SQLEditor
>> is the query tool when an error occur when the connection to the server was
>> lost when no JSON response is available when login is not required should
>> highlight the error in the SQL panel FAILED
>> Expected spy SqlEditor._highlight_error to have been called with [ 'Some
>> plain text error' ] but it was never called.
>> at regression/javascript/sqleditor/execute_query_spec.js:11875:58
>> HeadlessChrome 0.0.0 (Mac OS X 10.12.6): Executed 299 of 486 (4 FAILED)
>> (0 secs / 0 secs)
>> HeadlessC

pgAdmin 4 commit: Fix a number of broken connection detection scenarios

[Dave Page]

Fix a number of broken connection detection scenarios.

Branch
--
master

Details
---
https://git.postgresql.org/gitweb?p=pgadmin4.git;a=commitdiff;h=637f3b9d1a54df8b9a1bfad9e26f27fdea407683
Author: Akshay Joshi 

Modified Files
--
web/pgadmin/dashboard/static/js/dashboard.js   | 58 
web/pgadmin/static/js/sqleditor/execute_query.js   | 62 +++--
.../js/sqleditor/is_new_transaction_required.js|  9 
web/pgadmin/tools/sqleditor/__init__.py|  4 +-
web/pgadmin/tools/sqleditor/static/js/sqleditor.js | 20 ---
.../tools/sqleditor/tests/test_start_query_tool.py |  2 +-
.../tools/sqleditor/utils/start_running_query.py   | 63 ++
.../utils/tests/test_start_running_query.py| 15 +-
.../user_management/static/js/user_management.js   | 13 -
.../utils/driver/psycopg2/server_manager.py|  1 +
.../javascript/sqleditor/execute_query_spec.js | 48 -
.../sqleditor/is_new_transaction_required_spec.js  | 14 ++---
12 files changed, 195 insertions(+), 114 deletions(-)

Re: [pgadmin][patch] [GreenPlum] When user press Explain Plan and Explain analyze plan an error is displayed

[Dave Page]

Thanks, applied. All tests pass on my machine, now waiting for Jenkins to
run. Assuming all is good, I'll build the release packages.



On Wed, Mar 21, 2018 at 7:27 AM, Akshay Joshi  wrote:

> Hi Victoria,
>
> In "is_new_transaction_required.js" file I have modified the code and
> handled both "responseJSON" and "axios" responses, but in your patch you
> have removed "responseJSON" part which is required because "i
> *s_new_transaction_required*()" function is also called from sqleditor.js
> with normal javascript response.
>
> I have re-added that code and also found one issue where "from pgadmin.
> utils.exception import ConnectionLost" statement is missing from "web/
> pgadmin/utils/driver/psycopg2/server_manager.py" file, so I added that
> too.
>
> Attached is the modified patch.
>
> On Wed, Mar 21, 2018 at 2:09 AM, Victoria Henry  wrote:
>
>> Hi Hackers,
>>
>> We fixed the tests and refactored some of the code.  All tests pass now.
>> Attached is the reviewed patch.
>>
>> Sincerely,
>>
>> Joao and Victoria
>>
>> On Tue, Mar 20, 2018 at 10:05 AM, Dave Page 
>> wrote:
>>
>>> Hi
>>>
>>> This doesn't pass the Javascript tests for me. Please investigate ASAP:
>>>
>>> webpack: Compiled successfully.
>>> HeadlessChrome 0.0.0 (Mac OS X 10.12.6): Executed 152 of 486 SUCCESS (0
>>> secs / 0 secs)
>>> HeadlessChrome 0.0.0 (Mac OS X 10.12.6): Executed 153 of 486 SUCCESS (0
>>> secs / 0 secs)
>>> HeadlessChrome 0.0.0 (Mac OS X 10.12.6): Executed 154 of 486 SUCCESS (0
>>> secs / 0 secs)
>>> HeadlessChrome 0.0.0 (Mac OS X 10.12.6): Executed 155 of 486 SUCCESS (0
>>> secs / 0 secs)
>>> HeadlessChrome 0.0.0 (Mac OS X 10.12.6): Executed 156 of 486 SUCCESS (0
>>> secs / 0 secs)
>>> HeadlessChrome 0.0.0 (Mac OS X 10.12.6): Executed 157 of 486 SUCCESS (0
>>> secs / 0 secs)
>>> HeadlessChrome 0.0.0 (Mac OS X 10.12.6): Executed 158 of 486 SUCCESS (0
>>> secs / 0 secs)
>>> HeadlessChrome 0.0.0 (Mac OS X 10.12.6) ExecuteQuery #poll when
>>> SQLEditor is the query tool when an error occur when the connection to the
>>> server was lost when JSON response is available when login is not required
>>> should highlight the error in the SQL panel FAILED
>>> Expected spy SqlEditor._highlight_error to have been called with [ 'Some
>>> error in JSON' ] but it was never called.
>>> at regression/javascript/sqleditor/execute_query_spec.js:11753:58
>>> HeadlessChrome 0.0.0 (Mac OS X 10.12.6): Executed 285 of 486 (1 FAILED)
>>> (0 secs / 0 secs)
>>> HeadlessChrome 0.0.0 (Mac OS X 10.12.6) ExecuteQuery #poll when
>>> SQLEditor is the query tool when an error occur when the connection to the
>>> server was lost when JSON response is available when login is not required
>>> should highlight the error in the SQL panel FAILED
>>> Expected spy SqlEditor._highlight_error to have been called with [ 'Some
>>> error in JSON' ] but it was never called.
>>> HeadlessChrome 0.0.0 (Mac OS X 10.12.6) ExecuteQuery #poll when
>>> SQLEditor is the query tool when an error occur when the connection to the
>>> server was lost when JSON response is available when login is not required
>>> should add new entry to history and update the Messages tab FAILED
>>> Expected spy SqlEditor.update_msg_history to have been called with [
>>> false, 'Some error in JSON' ] but it was never called.
>>> at regression/javascript/sqleditor/execute_query_spec.js:11760:60
>>> HeadlessChrome 0.0.0 (Mac OS X 10.12.6): Executed 286 of 486 (2 FAILED)
>>> (0 secs / 0 secs)
>>> HeadlessChrome 0.0.0 (Mac OS X 10.12.6) ExecuteQuery #poll when
>>> SQLEditor is the query tool when an error occur when the connection to the
>>> server was lost when JSON response is available when login is not required
>>> should add new entry to history and update the Messages tab FAILED
>>> Expected spy SqlEditor.update_msg_history to have been called with [
>>> false, 'Some error in JSON' ] but it was never called.
>>> HeadlessChrome 0.0.0 (Mac OS X 10.12.6) ExecuteQuery #poll when
>>> SQLEditor is the query tool when an error occur when the connection to the
>>> server was lost when JSON response is available when login is required
>>> should login is displayed FAILED
>>> Expected spy UserManagement.pga_login to have been called.
>>> at regression/javascript/sqleditor/execute_query_spec.js:11840:56
>>> HeadlessChrome 0.0.0 (Mac OS X 10.12.6): Executed 296 of 486 (3 FAILED)
>>> (0 secs / 0 secs)
>>> HeadlessChrome 0.0.0 (Mac OS X 10.12.6) ExecuteQuery #poll when
>>> SQLEditor is the query tool when an error occur when the connection to the
>>> server was lost when JSON response is available when login is required
>>> should login is displayed FAILED
>>> Expected spy UserManagement.pga_login to have been called.
>>> HeadlessChrome 0.0.0 (Mac OS X 10.12.6) ExecuteQuery #poll when
>>> SQLEditor is the query tool when an error occur when the connection to the
>>> server was lost when no JSON response is available when login is not
>>> required should highlight the error in the SQL panel FAILED
>>> E

Jenkins build is back to normal : pgadmin4-master-python35 #543

[pgAdmin 4 Jenkins]

See 

pgAdmin4 form control error icon position change

[Aditya Toshniwal]

*Hi Team,*

This is regarding the position of error icon of a pgAdmin form control.
Below are the screenshots. As we can see, the error icon is overlapping the
control buttons like the drop down button, spinner up down buttons, etc.




We propose that we can move the error icon to the front of the label of the
form control. Below are screenshots.




Attached is the patch for the above changes.
Kindly review.
-- 
Thanks and Regards,
Aditya Toshniwal
Software Engineer | EnterpriseDB Software Solutions
Pune | Mob - 8055837949
diff --git a/web/pgadmin/static/css/bootstrap.overrides.css b/web/pgadmin/static/css/bootstrap.overrides.css
index d2936a7..2ab44f0 100755
--- a/web/pgadmin/static/css/bootstrap.overrides.css
+++ b/web/pgadmin/static/css/bootstrap.overrides.css
@@ -269,7 +269,7 @@ iframe {
 
 .control-label {
 margin: 0px;
-padding: 5px;
+padding: 5px 25px 5px 5px;
 display: inline-block;
 vertical-align: middle;
 }
diff --git a/web/pgadmin/static/css/pgadmin.css b/web/pgadmin/static/css/pgadmin.css
index 6c1002c..666140e 100644
--- a/web/pgadmin/static/css/pgadmin.css
+++ b/web/pgadmin/static/css/pgadmin.css
@@ -732,7 +732,7 @@ lgg-el-container[el=md] .pg-el-lg-8,
   padding-top: 6px;
   padding-bottom: 6px;
   padding-left: 5px;
-  padding-right: 5px;
+  padding-right: 25px;
   display: inline-block;
   vertical-align: middle;
   min-height: 28px;
diff --git a/web/pgadmin/static/scss/_backform.overrides.scss b/web/pgadmin/static/scss/_backform.overrides.scss
index 2aa9460..b22c55a 100644
--- a/web/pgadmin/static/scss/_backform.overrides.scss
+++ b/web/pgadmin/static/scss/_backform.overrides.scss
@@ -8,14 +8,14 @@
 color: #d0021b;
   }
 
-  .pgadmin-controls:before {
+  .control-label:before {
 font: normal normal normal 16px/1 FontAwesome;
 content: "\f071";
 text-decoration: inherit;
 position: absolute;
 color: #d0021b;
-right: 15px;
-padding-top: 10px;
+right: 6px;
+padding-top: 6px;
 z-index: 1;
   }
 }

Jenkins build is back to normal : pgadmin4-master-python27 #544

[pgAdmin 4 Jenkins]

See 

Jenkins build is back to normal : pgadmin4-master-python26 #671

[pgAdmin 4 Jenkins]

See 

Re: pgAdmin4 form control error icon position change

[Murtuza Zabuawala]

Hello Aditya,

Could you please create new RM
 for the issue, so that
we can keep track of changes, It will be difficult for us to keep track of
email for the details.

--
Regards,
Murtuza Zabuawala
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


On Wed, Mar 21, 2018 at 2:28 PM, Aditya Toshniwal <
aditya.toshni...@enterprisedb.com> wrote:

>
> *Hi Team,*
>
> This is regarding the position of error icon of a pgAdmin form control.
> Below are the screenshots. As we can see, the error icon is overlapping the
> control buttons like the drop down button, spinner up down buttons, etc.
>
>
>
>
> We propose that we can move the error icon to the front of the label of
> the form control. Below are screenshots.
>
>
>
>
> Attached is the patch for the above changes.
> Kindly review.
> --
> Thanks and Regards,
> Aditya Toshniwal
> Software Engineer | EnterpriseDB Software Solutions
> Pune | Mob - 8055837949
>

Re: pgAdmin4 form control error icon position change

[Aditya Toshniwal]

Created - https://redmine.postgresql.org/issues/3226

On Wed, Mar 21, 2018 at 2:51 PM, Murtuza Zabuawala <
murtuza.zabuaw...@enterprisedb.com> wrote:

> Hello Aditya,
>
> Could you please create new RM
>  for the issue, so that
> we can keep track of changes, It will be difficult for us to keep track
> of email for the details.
>
> --
> Regards,
> Murtuza Zabuawala
> EnterpriseDB: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
>
>
> On Wed, Mar 21, 2018 at 2:28 PM, Aditya Toshniwal  enterprisedb.com> wrote:
>
>>
>> *Hi Team,*
>>
>> This is regarding the position of error icon of a pgAdmin form control.
>> Below are the screenshots. As we can see, the error icon is overlapping the
>> control buttons like the drop down button, spinner up down buttons, etc.
>>
>>
>>
>>
>> We propose that we can move the error icon to the front of the label of
>> the form control. Below are screenshots.
>>
>>
>>
>>
>> Attached is the patch for the above changes.
>> Kindly review.
>> --
>> Thanks and Regards,
>> Aditya Toshniwal
>> Software Engineer | EnterpriseDB Software Solutions
>> Pune | Mob - 8055837949
>>
>
>


-- 
Thanks and Regards,
Aditya Toshniwal
Software Engineer | EnterpriseDB Software Solutions
Pune | Mob - 8055837949

Jenkins build is back to normal : pgadmin4-master-python36 #535

[pgAdmin 4 Jenkins]

See 

Jenkins build is back to normal : pgadmin4-master-python33 #542

[pgAdmin 4 Jenkins]

See 

pgAdmin 4 commit: Bump version for release.

[Dave Page]

Bump version for release.

Branch
--
master

Details
---
https://git.postgresql.org/gitweb?p=pgadmin4.git;a=commitdiff;h=6668d5eb9399303d7a27de2e66fcd00a325c049e

Modified Files
--
web/config.py | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

pgAdmin 4 commit: Secure runtime temp files.

[Dave Page]

Secure runtime temp files.

Branch
--
master

Details
---
https://git.postgresql.org/gitweb?p=pgadmin4.git;a=commitdiff;h=80b29a85cc98effde6c4f919cf90d9aababd22ad

Modified Files
--
runtime/Server.cpp   | 2 ++
runtime/pgAdmin4.cpp | 1 +
2 files changed, 3 insertions(+)

Re: [pgadmin][patch] [GreenPlum] When user press Explain Plan and Explain analyze plan an error is displayed

[Joao De Almeida Pereira]

Hello Akshay,

Thanks for double checking the patch, clearly the things that we missing
are asking for some tests to ensure that mistakes like this do not happen
again. Specially in scenarios where the we have strange behaviors, like
loosing connection to the python server and so on.

Thanks
Joao

On Wed, Mar 21, 2018 at 4:39 AM Dave Page 
wrote:

> Thanks, applied. All tests pass on my machine, now waiting for Jenkins to
> run. Assuming all is good, I'll build the release packages.
>
>
>
> On Wed, Mar 21, 2018 at 7:27 AM, Akshay Joshi <
> akshay.jo...@enterprisedb.com> wrote:
>
>> Hi Victoria,
>>
>> In "is_new_transaction_required.js" file I have modified the code and
>> handled both "responseJSON" and "axios" responses, but in your patch you
>> have removed "responseJSON" part which is required because "i
>> *s_new_transaction_required*()" function is also called from sqleditor.js
>> with normal javascript response.
>>
>> I have re-added that code and also found one issue where "from pgadmin.
>> utils.exception import ConnectionLost" statement is missing from "web/
>> pgadmin/utils/driver/psycopg2/server_manager.py" file, so I added that
>> too.
>>
>> Attached is the modified patch.
>>
>> On Wed, Mar 21, 2018 at 2:09 AM, Victoria Henry 
>> wrote:
>>
>>> Hi Hackers,
>>>
>>> We fixed the tests and refactored some of the code.  All tests pass
>>> now.  Attached is the reviewed patch.
>>>
>>> Sincerely,
>>>
>>> Joao and Victoria
>>>
>>> On Tue, Mar 20, 2018 at 10:05 AM, Dave Page 
>>> wrote:
>>>
 Hi

 This doesn't pass the Javascript tests for me. Please investigate ASAP:

 webpack: Compiled successfully.
 HeadlessChrome 0.0.0 (Mac OS X 10.12.6): Executed 152 of 486 SUCCESS (0
 secs / 0 secs)
 HeadlessChrome 0.0.0 (Mac OS X 10.12.6): Executed 153 of 486 SUCCESS (0
 secs / 0 secs)
 HeadlessChrome 0.0.0 (Mac OS X 10.12.6): Executed 154 of 486 SUCCESS (0
 secs / 0 secs)
 HeadlessChrome 0.0.0 (Mac OS X 10.12.6): Executed 155 of 486 SUCCESS (0
 secs / 0 secs)
 HeadlessChrome 0.0.0 (Mac OS X 10.12.6): Executed 156 of 486 SUCCESS (0
 secs / 0 secs)
 HeadlessChrome 0.0.0 (Mac OS X 10.12.6): Executed 157 of 486 SUCCESS (0
 secs / 0 secs)
 HeadlessChrome 0.0.0 (Mac OS X 10.12.6): Executed 158 of 486 SUCCESS (0
 secs / 0 secs)
 HeadlessChrome 0.0.0 (Mac OS X 10.12.6) ExecuteQuery #poll when
 SQLEditor is the query tool when an error occur when the connection to the
 server was lost when JSON response is available when login is not required
 should highlight the error in the SQL panel FAILED
 Expected spy SqlEditor._highlight_error to have been called with [
 'Some error in JSON' ] but it was never called.
 at regression/javascript/sqleditor/execute_query_spec.js:11753:58
 HeadlessChrome 0.0.0 (Mac OS X 10.12.6): Executed 285 of 486 (1 FAILED)
 (0 secs / 0 secs)
 HeadlessChrome 0.0.0 (Mac OS X 10.12.6) ExecuteQuery #poll when
 SQLEditor is the query tool when an error occur when the connection to the
 server was lost when JSON response is available when login is not required
 should highlight the error in the SQL panel FAILED
 Expected spy SqlEditor._highlight_error to have been called with [
 'Some error in JSON' ] but it was never called.
 HeadlessChrome 0.0.0 (Mac OS X 10.12.6) ExecuteQuery #poll when
 SQLEditor is the query tool when an error occur when the connection to the
 server was lost when JSON response is available when login is not required
 should add new entry to history and update the Messages tab FAILED
 Expected spy SqlEditor.update_msg_history to have been called with [
 false, 'Some error in JSON' ] but it was never called.
 at regression/javascript/sqleditor/execute_query_spec.js:11760:60
 HeadlessChrome 0.0.0 (Mac OS X 10.12.6): Executed 286 of 486 (2 FAILED)
 (0 secs / 0 secs)
 HeadlessChrome 0.0.0 (Mac OS X 10.12.6) ExecuteQuery #poll when
 SQLEditor is the query tool when an error occur when the connection to the
 server was lost when JSON response is available when login is not required
 should add new entry to history and update the Messages tab FAILED
 Expected spy SqlEditor.update_msg_history to have been called with [
 false, 'Some error in JSON' ] but it was never called.
 HeadlessChrome 0.0.0 (Mac OS X 10.12.6) ExecuteQuery #poll when
 SQLEditor is the query tool when an error occur when the connection to the
 server was lost when JSON response is available when login is required
 should login is displayed FAILED
 Expected spy UserManagement.pga_login to have been called.
 at regression/javascript/sqleditor/execute_query_spec.js:11840:56
 HeadlessChrome 0.0.0 (Mac OS X 10.12.6): Executed 296 of 486 (3 FAILED)
 (0 secs / 0 secs)
 HeadlessChrome 0.0.0 (Mac OS X 10.12.6) ExecuteQuery #poll when
 SQLEditor is the query tool when an error occur when 

Experiencing issues

[Joao De Almeida Pereira]

Hello Hackers,
Can anyone use the current master branch?
When I try to open a server I get a 428. Is that only me?

Thanks
Joao

Re: Experiencing issues

[Dave Page]

On Wed, Mar 21, 2018 at 2:11 PM, Joao De Almeida Pereira <
jdealmeidapere...@pivotal.io> wrote:

> Hello Hackers,
> Can anyone use the current master branch?
> When I try to open a server I get a 428. Is that only me?
>

Both ssh and https seem to be working fine for me.

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

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

Re: Experiencing issues

[Khushboo Vashi]

On 21 Mar 2018 19:41, "Joao De Almeida Pereira" <
jdealmeidapere...@pivotal.io> wrote:

Hello Hackers,
Can anyone use the current master branch?
When I try to open a server I get a 428. Is that only me?

May be because of cookie changes.
Check your config.py and config_local.py if you have done changes related
to DEFAULT_SERVER in your config_local.py then you need to change other 2
cookie related variables also.

Thanks
Joao

Re: Experiencing issues

[Joao De Almeida Pereira]

Where can I find information about that?

On Wed, Mar 21, 2018 at 10:16 AM Khushboo Vashi <
khushboo.va...@enterprisedb.com> wrote:

>
>
> On 21 Mar 2018 19:41, "Joao De Almeida Pereira" <
> jdealmeidapere...@pivotal.io> wrote:
>
> Hello Hackers,
> Can anyone use the current master branch?
> When I try to open a server I get a 428. Is that only me?
>
> May be because of cookie changes.
> Check your config.py and config_local.py if you have done changes related
> to DEFAULT_SERVER in your config_local.py then you need to change other 2
> cookie related variables also.
>
> Thanks
> Joao
>
>
>

Re: Experiencing issues

[Dave Page]

On Wed, Mar 21, 2018 at 2:16 PM, Khushboo Vashi <
khushboo.va...@enterprisedb.com> wrote:

>
>
> On 21 Mar 2018 19:41, "Joao De Almeida Pereira" <
> jdealmeidapere...@pivotal.io> wrote:
>
> Hello Hackers,
> Can anyone use the current master branch?
> When I try to open a server I get a 428. Is that only me?
>
> May be because of cookie changes.
> Check your config.py and config_local.py if you have done changes related
> to DEFAULT_SERVER in your config_local.py then you need to change other 2
> cookie related variables also.
>

Oh, I thought Joao meant he was having problems using the master branch on
the git server :-)



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

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

Re: Experiencing issues

[Murtuza Zabuawala]

Yes, that's cookie related issue (RM#3197), To fix that I added below in my
config_local.py and it started working again,

DEFAULT_SERVER = '0.0.0.0'
COOKIE_DEFAULT_DOMAIN = SESSION_COOKIE_DOMAIN = DEFAULT_SERVER

Clear your browser cookies and server side sessions.


--
Regards,
Murtuza Zabuawala
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


On Wed, Mar 21, 2018 at 7:55 PM, Joao De Almeida Pereira <
jdealmeidapere...@pivotal.io> wrote:

> Where can I find information about that?
>
> On Wed, Mar 21, 2018 at 10:16 AM Khushboo Vashi <
> khushboo.va...@enterprisedb.com> wrote:
>
>>
>>
>> On 21 Mar 2018 19:41, "Joao De Almeida Pereira" <
>> jdealmeidapere...@pivotal.io> wrote:
>>
>> Hello Hackers,
>> Can anyone use the current master branch?
>> When I try to open a server I get a 428. Is that only me?
>>
>> May be because of cookie changes.
>> Check your config.py and config_local.py if you have done changes related
>> to DEFAULT_SERVER in your config_local.py then you need to change other 2
>> cookie related variables also.
>>
>> Thanks
>> Joao
>>
>>
>>

Re: Experiencing issues

[Joao De Almeida Pereira]

I tried that but still nothing. When i check in the inspector for cookies I
have none

On Wed, Mar 21, 2018 at 10:30 AM Murtuza Zabuawala <
murtuza.zabuaw...@enterprisedb.com> wrote:

> Yes, that's cookie related issue (RM#3197), To fix that I added below in
> my config_local.py and it started working again,
>
> DEFAULT_SERVER = '0.0.0.0'
> COOKIE_DEFAULT_DOMAIN = SESSION_COOKIE_DOMAIN = DEFAULT_SERVER
>
> Clear your browser cookies and server side sessions.
>
>
> --
> Regards,
> Murtuza Zabuawala
> EnterpriseDB: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
>
>
> On Wed, Mar 21, 2018 at 7:55 PM, Joao De Almeida Pereira <
> jdealmeidapere...@pivotal.io> wrote:
>
>> Where can I find information about that?
>>
>> On Wed, Mar 21, 2018 at 10:16 AM Khushboo Vashi <
>> khushboo.va...@enterprisedb.com> wrote:
>>
>>>
>>>
>>> On 21 Mar 2018 19:41, "Joao De Almeida Pereira" <
>>> jdealmeidapere...@pivotal.io> wrote:
>>>
>>> Hello Hackers,
>>> Can anyone use the current master branch?
>>> When I try to open a server I get a 428. Is that only me?
>>>
>>> May be because of cookie changes.
>>> Check your config.py and config_local.py if you have done changes
>>> related to DEFAULT_SERVER in your config_local.py then you need to change
>>> other 2 cookie related variables also.
>>>
>>> Thanks
>>> Joao
>>>
>>>
>>>
>

Re: Experiencing issues

[Dave Page]

On Wed, Mar 21, 2018 at 2:29 PM, Murtuza Zabuawala <
murtuza.zabuaw...@enterprisedb.com> wrote:

> Yes, that's cookie related issue (RM#3197), To fix that I added below in
> my config_local.py and it started working again,
>
> DEFAULT_SERVER = '0.0.0.0'
> COOKIE_DEFAULT_DOMAIN = SESSION_COOKIE_DOMAIN = DEFAULT_SERVER
>

I haven't had to do that - and the 3.0 packages I just built for Windows
and Mac worked fine on fresh VMs without anything like that being needed.

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

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

Re: Experiencing issues

[Khushboo Vashi]

On 21 Mar 2018 20:02, "Dave Page"  wrote:



On Wed, Mar 21, 2018 at 2:29 PM, Murtuza Zabuawala  wrote:

> Yes, that's cookie related issue (RM#3197), To fix that I added below in
> my config_local.py and it started working again,
>
> DEFAULT_SERVER = '0.0.0.0'
> COOKIE_DEFAULT_DOMAIN = SESSION_COOKIE_DOMAIN = DEFAULT_SERVER
>

I haven't had to do that - and the 3.0 packages I just built for Windows
and Mac worked fine on fresh VMs without anything like that being needed.

These changes required when you change DEFAULT_SERVER in config_local.py

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

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

Re: Experiencing issues

[Murtuza Zabuawala]

Have you cleared server side sessions?
rm -rf ~/.pgadmin/sessions/

Make sure to access it with same name as mentioned via DEFAULT_SERVER.

if you have DEFAULT_SERVER = '0.0.0.0'
then http://0.0.0.0:5050

and if you have DEFAULT_SERVER = '127.0.0.1'
then http://127.0.0.1:5050



--
Regards,
Murtuza Zabuawala
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


On Wed, Mar 21, 2018 at 8:01 PM, Joao De Almeida Pereira <
jdealmeidapere...@pivotal.io> wrote:

> I tried that but still nothing. When i check in the inspector for cookies
> I have none
>
> On Wed, Mar 21, 2018 at 10:30 AM Murtuza Zabuawala  enterprisedb.com> wrote:
>
>> Yes, that's cookie related issue (RM#3197), To fix that I added below in
>> my config_local.py and it started working again,
>>
>> DEFAULT_SERVER = '0.0.0.0'
>> COOKIE_DEFAULT_DOMAIN = SESSION_COOKIE_DOMAIN = DEFAULT_SERVER
>>
>> Clear your browser cookies and server side sessions.
>>
>>
>> --
>> Regards,
>> Murtuza Zabuawala
>> EnterpriseDB: http://www.enterprisedb.com
>> The Enterprise PostgreSQL Company
>>
>>
>> On Wed, Mar 21, 2018 at 7:55 PM, Joao De Almeida Pereira <
>> jdealmeidapere...@pivotal.io> wrote:
>>
>>> Where can I find information about that?
>>>
>>> On Wed, Mar 21, 2018 at 10:16 AM Khushboo Vashi <
>>> khushboo.va...@enterprisedb.com> wrote:
>>>


 On 21 Mar 2018 19:41, "Joao De Almeida Pereira" <
 jdealmeidapere...@pivotal.io> wrote:

 Hello Hackers,
 Can anyone use the current master branch?
 When I try to open a server I get a 428. Is that only me?

 May be because of cookie changes.
 Check your config.py and config_local.py if you have done changes
 related to DEFAULT_SERVER in your config_local.py then you need to change
 other 2 cookie related variables also.

 Thanks
 Joao



>>

Re: Experiencing issues

[Khushboo Vashi]

On 21 Mar 2018 20:01, "Joao De Almeida Pereira" <
jdealmeidapere...@pivotal.io> wrote:

I tried that but still nothing. When i check in the inspector for cookies I
have none

Share your config_local file.

On Wed, Mar 21, 2018 at 10:30 AM Murtuza Zabuawala  wrote:

> Yes, that's cookie related issue (RM#3197), To fix that I added below in
> my config_local.py and it started working again,
>
> DEFAULT_SERVER = '0.0.0.0'
> COOKIE_DEFAULT_DOMAIN = SESSION_COOKIE_DOMAIN = DEFAULT_SERVER
>
> Clear your browser cookies and server side sessions.
>
>
> --
> Regards,
> Murtuza Zabuawala
> EnterpriseDB: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
>
>
> On Wed, Mar 21, 2018 at 7:55 PM, Joao De Almeida Pereira <
> jdealmeidapere...@pivotal.io> wrote:
>
>> Where can I find information about that?
>>
>> On Wed, Mar 21, 2018 at 10:16 AM Khushboo Vashi <
>> khushboo.va...@enterprisedb.com> wrote:
>>
>>>
>>>
>>> On 21 Mar 2018 19:41, "Joao De Almeida Pereira" <
>>> jdealmeidapere...@pivotal.io> wrote:
>>>
>>> Hello Hackers,
>>> Can anyone use the current master branch?
>>> When I try to open a server I get a 428. Is that only me?
>>>
>>> May be because of cookie changes.
>>> Check your config.py and config_local.py if you have done changes
>>> related to DEFAULT_SERVER in your config_local.py then you need to change
>>> other 2 cookie related variables also.
>>>
>>> Thanks
>>> Joao
>>>
>>>
>>>
>

Re: Experiencing issues

[Joao De Almeida Pereira]

Ok Murtuza you are right,
Now my question is I have the default server to 127.0.0.1 and I want to
access it using localhost as well. How can I do this?

On Wed, Mar 21, 2018 at 10:39 AM Khushboo Vashi <
khushboo.va...@enterprisedb.com> wrote:

>
>
> On 21 Mar 2018 20:01, "Joao De Almeida Pereira" <
> jdealmeidapere...@pivotal.io> wrote:
>
> I tried that but still nothing. When i check in the inspector for cookies
> I have none
>
> Share your config_local file.
>
> On Wed, Mar 21, 2018 at 10:30 AM Murtuza Zabuawala <
> murtuza.zabuaw...@enterprisedb.com> wrote:
>
>> Yes, that's cookie related issue (RM#3197), To fix that I added below in
>> my config_local.py and it started working again,
>>
>> DEFAULT_SERVER = '0.0.0.0'
>> COOKIE_DEFAULT_DOMAIN = SESSION_COOKIE_DOMAIN = DEFAULT_SERVER
>>
>> Clear your browser cookies and server side sessions.
>>
>>
>> --
>> Regards,
>> Murtuza Zabuawala
>> EnterpriseDB: http://www.enterprisedb.com
>> The Enterprise PostgreSQL Company
>>
>>
>> On Wed, Mar 21, 2018 at 7:55 PM, Joao De Almeida Pereira <
>> jdealmeidapere...@pivotal.io> wrote:
>>
>>> Where can I find information about that?
>>>
>>> On Wed, Mar 21, 2018 at 10:16 AM Khushboo Vashi <
>>> khushboo.va...@enterprisedb.com> wrote:
>>>


 On 21 Mar 2018 19:41, "Joao De Almeida Pereira" <
 jdealmeidapere...@pivotal.io> wrote:

 Hello Hackers,
 Can anyone use the current master branch?
 When I try to open a server I get a 428. Is that only me?

 May be because of cookie changes.
 Check your config.py and config_local.py if you have done changes
 related to DEFAULT_SERVER in your config_local.py then you need to change
 other 2 cookie related variables also.

 Thanks
 Joao



>>
>

pgAdmin 4 commit: Fix issue seen with older versions of GCC.

[Dave Page]

Fix issue seen with older versions of GCC.

Branch
--
master

Details
---
https://git.postgresql.org/gitweb?p=pgadmin4.git;a=commitdiff;h=60c44e8f7966fbf62fcedd1d11e783d507e10ca4

Modified Files
--
runtime/LogWindow.cpp | 1 +
1 file changed, 1 insertion(+)

Re: Experiencing issues

[Khushboo Vashi]

On Wed, Mar 21, 2018 at 8:10 PM, Joao De Almeida Pereira <
jdealmeidapere...@pivotal.io> wrote:

> Ok Murtuza you are right,
> Now my question is I have the default server to 127.0.0.1 and I want to
> access it using localhost as well. How can I do this?
>
> No, you can't.
Domain based cookie will work for that domain and it's sub-domains.

> On Wed, Mar 21, 2018 at 10:39 AM Khushboo Vashi <
> khushboo.va...@enterprisedb.com> wrote:
>
>>
>>
>> On 21 Mar 2018 20:01, "Joao De Almeida Pereira" <
>> jdealmeidapere...@pivotal.io> wrote:
>>
>> I tried that but still nothing. When i check in the inspector for cookies
>> I have none
>>
>> Share your config_local file.
>>
>> On Wed, Mar 21, 2018 at 10:30 AM Murtuza Zabuawala > enterprisedb.com> wrote:
>>
>>> Yes, that's cookie related issue (RM#3197), To fix that I added below in
>>> my config_local.py and it started working again,
>>>
>>> DEFAULT_SERVER = '0.0.0.0'
>>> COOKIE_DEFAULT_DOMAIN = SESSION_COOKIE_DOMAIN = DEFAULT_SERVER
>>>
>>> Clear your browser cookies and server side sessions.
>>>
>>>
>>> --
>>> Regards,
>>> Murtuza Zabuawala
>>> EnterpriseDB: http://www.enterprisedb.com
>>> The Enterprise PostgreSQL Company
>>>
>>>
>>> On Wed, Mar 21, 2018 at 7:55 PM, Joao De Almeida Pereira <
>>> jdealmeidapere...@pivotal.io> wrote:
>>>
 Where can I find information about that?

 On Wed, Mar 21, 2018 at 10:16 AM Khushboo Vashi <
 khushboo.va...@enterprisedb.com> wrote:

>
>
> On 21 Mar 2018 19:41, "Joao De Almeida Pereira" <
> jdealmeidapere...@pivotal.io> wrote:
>
> Hello Hackers,
> Can anyone use the current master branch?
> When I try to open a server I get a 428. Is that only me?
>
> May be because of cookie changes.
> Check your config.py and config_local.py if you have done changes
> related to DEFAULT_SERVER in your config_local.py then you need to change
> other 2 cookie related variables also.
>
> Thanks
> Joao
>
>
>
>>>
>>

Re: Experiencing issues

[Joao De Almeida Pereira]

So what you are saying is that if I have a server, I need to do
DEFAULT_SERVER=0.0.0.0 and then set the real domain on the COOKIE domain?

On Wed, Mar 21, 2018 at 10:55 AM Khushboo Vashi <
khushboo.va...@enterprisedb.com> wrote:

> On Wed, Mar 21, 2018 at 8:10 PM, Joao De Almeida Pereira <
> jdealmeidapere...@pivotal.io> wrote:
>
>> Ok Murtuza you are right,
>> Now my question is I have the default server to 127.0.0.1 and I want to
>> access it using localhost as well. How can I do this?
>>
>> No, you can't.
> Domain based cookie will work for that domain and it's sub-domains.
>
>> On Wed, Mar 21, 2018 at 10:39 AM Khushboo Vashi <
>> khushboo.va...@enterprisedb.com> wrote:
>>
>>>
>>>
>>> On 21 Mar 2018 20:01, "Joao De Almeida Pereira" <
>>> jdealmeidapere...@pivotal.io> wrote:
>>>
>>> I tried that but still nothing. When i check in the inspector for
>>> cookies I have none
>>>
>>> Share your config_local file.
>>>
>>> On Wed, Mar 21, 2018 at 10:30 AM Murtuza Zabuawala <
>>> murtuza.zabuaw...@enterprisedb.com> wrote:
>>>
 Yes, that's cookie related issue (RM#3197), To fix that I added below
 in my config_local.py and it started working again,

 DEFAULT_SERVER = '0.0.0.0'
 COOKIE_DEFAULT_DOMAIN = SESSION_COOKIE_DOMAIN = DEFAULT_SERVER

 Clear your browser cookies and server side sessions.


 --
 Regards,
 Murtuza Zabuawala
 EnterpriseDB: http://www.enterprisedb.com
 The Enterprise PostgreSQL Company


 On Wed, Mar 21, 2018 at 7:55 PM, Joao De Almeida Pereira <
 jdealmeidapere...@pivotal.io> wrote:

> Where can I find information about that?
>
> On Wed, Mar 21, 2018 at 10:16 AM Khushboo Vashi <
> khushboo.va...@enterprisedb.com> wrote:
>
>>
>>
>> On 21 Mar 2018 19:41, "Joao De Almeida Pereira" <
>> jdealmeidapere...@pivotal.io> wrote:
>>
>> Hello Hackers,
>> Can anyone use the current master branch?
>> When I try to open a server I get a 428. Is that only me?
>>
>> May be because of cookie changes.
>> Check your config.py and config_local.py if you have done changes
>> related to DEFAULT_SERVER in your config_local.py then you need to change
>> other 2 cookie related variables also.
>>
>> Thanks
>> Joao
>>
>>
>>

>>>

Re: Experiencing issues

[Khushboo Vashi]

On Wed, Mar 21, 2018 at 8:27 PM, Joao De Almeida Pereira <
jdealmeidapere...@pivotal.io> wrote:

> So what you are saying is that if I have a server, I need to do
> DEFAULT_SERVER=0.0.0.0 and then set the real domain on the COOKIE domain?
>
> No I am saying, whatever you set as a DEFAULT_SERVER,  the app can be
accessible with that server.
As, we have explicitly set  DOMAIN in the cookie setting.

> On Wed, Mar 21, 2018 at 10:55 AM Khushboo Vashi <
> khushboo.va...@enterprisedb.com> wrote:
>
>> On Wed, Mar 21, 2018 at 8:10 PM, Joao De Almeida Pereira <
>> jdealmeidapere...@pivotal.io> wrote:
>>
>>> Ok Murtuza you are right,
>>> Now my question is I have the default server to 127.0.0.1 and I want to
>>> access it using localhost as well. How can I do this?
>>>
>>> No, you can't.
>> Domain based cookie will work for that domain and it's sub-domains.
>>
>>> On Wed, Mar 21, 2018 at 10:39 AM Khushboo Vashi <
>>> khushboo.va...@enterprisedb.com> wrote:
>>>


 On 21 Mar 2018 20:01, "Joao De Almeida Pereira" <
 jdealmeidapere...@pivotal.io> wrote:

 I tried that but still nothing. When i check in the inspector for
 cookies I have none

 Share your config_local file.

 On Wed, Mar 21, 2018 at 10:30 AM Murtuza Zabuawala >>> enterprisedb.com> wrote:

> Yes, that's cookie related issue (RM#3197), To fix that I added below
> in my config_local.py and it started working again,
>
> DEFAULT_SERVER = '0.0.0.0'
> COOKIE_DEFAULT_DOMAIN = SESSION_COOKIE_DOMAIN = DEFAULT_SERVER
>
> Clear your browser cookies and server side sessions.
>
>
> --
> Regards,
> Murtuza Zabuawala
> EnterpriseDB: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
>
>
> On Wed, Mar 21, 2018 at 7:55 PM, Joao De Almeida Pereira <
> jdealmeidapere...@pivotal.io> wrote:
>
>> Where can I find information about that?
>>
>> On Wed, Mar 21, 2018 at 10:16 AM Khushboo Vashi <
>> khushboo.va...@enterprisedb.com> wrote:
>>
>>>
>>>
>>> On 21 Mar 2018 19:41, "Joao De Almeida Pereira" <
>>> jdealmeidapere...@pivotal.io> wrote:
>>>
>>> Hello Hackers,
>>> Can anyone use the current master branch?
>>> When I try to open a server I get a 428. Is that only me?
>>>
>>> May be because of cookie changes.
>>> Check your config.py and config_local.py if you have done changes
>>> related to DEFAULT_SERVER in your config_local.py then you need to 
>>> change
>>> other 2 cookie related variables also.
>>>
>>> Thanks
>>> Joao
>>>
>>>
>>>
>

v3.0 release on hold

[Dave Page]

We've run into a number of unexpected issues with the v3.0 release that I
think we need to resolve before moving forwards. For the time being, only
patches critical to fix these issues should be committed.

I'll try to look at 1, though I do have another deadline I need to meet.
Akshay, can you look at 2 please?
Fahar is already looking at 3.
Khushboo, can you look at 4 please?

Thanks all.

1) There is no longer a system tray in Gnome 3.26 and later, and thus the
runtime won't initialise in Fedora 27 and later. We need an alternative for
this, either a tray replacement that the RPM can depend on, or better yet,
support whatever it is Gnome expect such apps to use these days.

2) Starting a second instance of the app bundle on Mac doesn't always open
a new pgAdmin window as it should. It works fine in the debugger, or if you
start the app with a command like: "/Applications/pgAdmin\
4.app/Contents/MacOS/pgAdmin4". It doesn't work if you double-click the
appbundle or use a command like "open /Applications/pgAdmin\ 4.app"

3) Fahar saw a crash on Windows 7. I couldn't reproduce this on my copy,
but apparently his is a fresh installation.

4) On my Windows 7 machine, after running a backup I get no status window,
and see the following in the logs:

Traceback (most recent call last):
  File "C:\Program Files (x86)\pgAdmin
4\v3\venv\Lib\site-packages\werkzeug\serving.py", line 209, in run_wsgi
execute(self.server.app)
  File "C:\Program Files (x86)\pgAdmin
4\v3\venv\Lib\site-packages\werkzeug\serving.py", line 197, in execute
application_iter = app(environ, start_response)
  File "C:\Program Files (x86)\pgAdmin
4\v3\venv\Lib\site-packages\flask\app.py", line 1997, in __call__
return self.wsgi_app(environ, start_response)
  File "C:\Program Files (x86)\pgAdmin
4\v3\venv\Lib\site-packages\flask\app.py", line 1985, in wsgi_app
response = self.handle_exception(e)
  File "C:\Program Files (x86)\pgAdmin
4\v3\venv\Lib\site-packages\flask\app.py", line 1540, in handle_exception
reraise(exc_type, exc_value, tb)
  File "C:\Program Files (x86)\pgAdmin
4\v3\venv\Lib\site-packages\flask\app.py", line 1982, in wsgi_app
response = self.full_dispatch_request()
  File "C:\Program Files (x86)\pgAdmin
4\v3\venv\Lib\site-packages\flask\app.py", line 1614, in
full_dispatch_request
rv = self.handle_user_exception(e)
  File "C:\Program Files (x86)\pgAdmin
4\v3\venv\Lib\site-packages\flask\app.py", line 1517, in
handle_user_exception
reraise(exc_type, exc_value, tb)
  File "C:\Program Files (x86)\pgAdmin
4\v3\venv\Lib\site-packages\flask\app.py", line 1612, in
full_dispatch_request
rv = self.dispatch_request()
  File "C:\Program Files (x86)\pgAdmin
4\v3\venv\Lib\site-packages\flask\app.py", line 1598, in dispatch_request
return self.view_functions[rule.endpoint](**req.view_args)
  File "C:\Program Files (x86)\pgAdmin
4\v3\venv\Lib\site-packages\flask_login.py", line 792, in decorated_view
return func(*args, **kwargs)
  File "C:\Program Files (x86)\pgAdmin
4\v3\web\pgadmin\misc\bgprocess\__init__.py", line 62, in index
return make_response(response=BatchProcess.list())
  File "C:\Program Files (x86)\pgAdmin
4\v3\web\pgadmin\misc\bgprocess\processes.py", line 584, in list
details = desc.details(p.command, args)
  File "C:\Program Files (x86)\pgAdmin
4\v3\web\pgadmin\tools\backup\__init__.py", line 190, in details
res += html.safe_str(cmd + self.cmd)
AttributeError: 'BackupMessage' object has no attribute 'cmd'



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

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

Re: v3.0 release on hold

[Khushboo Vashi]

On 21 Mar 2018 21:05, "Dave Page"  wrote:

We've run into a number of unexpected issues with the v3.0 release that I
think we need to resolve before moving forwards. For the time being, only
patches critical to fix these issues should be committed.

I'll try to look at 1, though I do have another deadline I need to meet.
Akshay, can you look at 2 please?
Fahar is already looking at 3.
Khushboo, can you look at 4 please?

Sure.


Thanks all.

1) There is no longer a system tray in Gnome 3.26 and later, and thus the
runtime won't initialise in Fedora 27 and later. We need an alternative for
this, either a tray replacement that the RPM can depend on, or better yet,
support whatever it is Gnome expect such apps to use these days.

2) Starting a second instance of the app bundle on Mac doesn't always open
a new pgAdmin window as it should. It works fine in the debugger, or if you
start the app with a command like: "/Applications/pgAdmin\
4.app/Contents/MacOS/pgAdmin4". It doesn't work if you double-click the
appbundle or use a command like "open /Applications/pgAdmin\ 4.app"

3) Fahar saw a crash on Windows 7. I couldn't reproduce this on my copy,
but apparently his is a fresh installation.

4) On my Windows 7 machine, after running a backup I get no status window,
and see the following in the logs:

Traceback (most recent call last):
  File "C:\Program Files (x86)\pgAdmin
4\v3\venv\Lib\site-packages\werkzeug\serving.py",
line 209, in run_wsgi
execute(self.server.app)
  File "C:\Program Files (x86)\pgAdmin
4\v3\venv\Lib\site-packages\werkzeug\serving.py",
line 197, in execute
application_iter = app(environ, start_response)
  File "C:\Program Files (x86)\pgAdmin
4\v3\venv\Lib\site-packages\flask\app.py",
line 1997, in __call__
return self.wsgi_app(environ, start_response)
  File "C:\Program Files (x86)\pgAdmin
4\v3\venv\Lib\site-packages\flask\app.py",
line 1985, in wsgi_app
response = self.handle_exception(e)
  File "C:\Program Files (x86)\pgAdmin
4\v3\venv\Lib\site-packages\flask\app.py",
line 1540, in handle_exception
reraise(exc_type, exc_value, tb)
  File "C:\Program Files (x86)\pgAdmin
4\v3\venv\Lib\site-packages\flask\app.py",
line 1982, in wsgi_app
response = self.full_dispatch_request()
  File "C:\Program Files (x86)\pgAdmin
4\v3\venv\Lib\site-packages\flask\app.py",
line 1614, in full_dispatch_request
rv = self.handle_user_exception(e)
  File "C:\Program Files (x86)\pgAdmin
4\v3\venv\Lib\site-packages\flask\app.py",
line 1517, in handle_user_exception
reraise(exc_type, exc_value, tb)
  File "C:\Program Files (x86)\pgAdmin
4\v3\venv\Lib\site-packages\flask\app.py",
line 1612, in full_dispatch_request
rv = self.dispatch_request()
  File "C:\Program Files (x86)\pgAdmin
4\v3\venv\Lib\site-packages\flask\app.py",
line 1598, in dispatch_request
return self.view_functions[rule.endpoint](**req.view_args)
  File "C:\Program Files (x86)\pgAdmin
4\v3\venv\Lib\site-packages\flask_login.py",
line 792, in decorated_view
return func(*args, **kwargs)
  File "C:\Program Files (x86)\pgAdmin
4\v3\web\pgadmin\misc\bgprocess\__init__.py",
line 62, in index
return make_response(response=BatchProcess.list())
  File "C:\Program Files (x86)\pgAdmin
4\v3\web\pgadmin\misc\bgprocess\processes.py",
line 584, in list
details = desc.details(p.command, args)
  File "C:\Program Files (x86)\pgAdmin
4\v3\web\pgadmin\tools\backup\__init__.py",
line 190, in details
res += html.safe_str(cmd + self.cmd)
AttributeError: 'BackupMessage' object has no attribute 'cmd'



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

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

Re: Experiencing issues

[Joao De Almeida Pereira]

Sorry I did not understand what you said.
This configuration:

DEFAULT_SERVER = '0.0.0.0'
SESSION_COOKIE_DOMAIN = DEFAULT_SERVER
COOKIE_DEFAULT_DOMAIN = DEFAULT_SERVER

If the application lives in the domain pgadmin.somedomain.com do I need to
have in config_local:
DEFAULT_SERVER = '0.0.0.0'
SESSION_COOKIE_DOMAIN = 'pgadmin.somedomain.com'
COOKIE_DEFAULT_DOMAIN = 'pgadmin.somedomain.com'
?

Does this mean that if for some reason I have a second domain like
pgadmin.somedomain2.com that I want to use I cannot?

The issue of 127.0.0.1 to localhost is very cumbersome, and somehow we
should be able to disable this, because when we are developing doesn't make
sense to not being able to use localhost and 127.0.0.1

Thanks
Joao
On Wed, Mar 21, 2018 at 11:01 AM Khushboo Vashi <
khushboo.va...@enterprisedb.com> wrote:

> On Wed, Mar 21, 2018 at 8:27 PM, Joao De Almeida Pereira <
> jdealmeidapere...@pivotal.io> wrote:
>
>> So what you are saying is that if I have a server, I need to do
>> DEFAULT_SERVER=0.0.0.0 and then set the real domain on the COOKIE domain?
>>
>> No I am saying, whatever you set as a DEFAULT_SERVER,  the app can be
> accessible with that server.
> As, we have explicitly set  DOMAIN in the cookie setting.
>
>> On Wed, Mar 21, 2018 at 10:55 AM Khushboo Vashi <
>> khushboo.va...@enterprisedb.com> wrote:
>>
>>> On Wed, Mar 21, 2018 at 8:10 PM, Joao De Almeida Pereira <
>>> jdealmeidapere...@pivotal.io> wrote:
>>>
 Ok Murtuza you are right,
 Now my question is I have the default server to 127.0.0.1 and I want to
 access it using localhost as well. How can I do this?

 No, you can't.
>>> Domain based cookie will work for that domain and it's sub-domains.
>>>
 On Wed, Mar 21, 2018 at 10:39 AM Khushboo Vashi <
 khushboo.va...@enterprisedb.com> wrote:

>
>
> On 21 Mar 2018 20:01, "Joao De Almeida Pereira" <
> jdealmeidapere...@pivotal.io> wrote:
>
> I tried that but still nothing. When i check in the inspector for
> cookies I have none
>
> Share your config_local file.
>
> On Wed, Mar 21, 2018 at 10:30 AM Murtuza Zabuawala <
> murtuza.zabuaw...@enterprisedb.com> wrote:
>
>> Yes, that's cookie related issue (RM#3197), To fix that I added below
>> in my config_local.py and it started working again,
>>
>> DEFAULT_SERVER = '0.0.0.0'
>> COOKIE_DEFAULT_DOMAIN = SESSION_COOKIE_DOMAIN = DEFAULT_SERVER
>>
>> Clear your browser cookies and server side sessions.
>>
>>
>> --
>> Regards,
>> Murtuza Zabuawala
>> EnterpriseDB: http://www.enterprisedb.com
>> The Enterprise PostgreSQL Company
>>
>>
>> On Wed, Mar 21, 2018 at 7:55 PM, Joao De Almeida Pereira <
>> jdealmeidapere...@pivotal.io> wrote:
>>
>>> Where can I find information about that?
>>>
>>> On Wed, Mar 21, 2018 at 10:16 AM Khushboo Vashi <
>>> khushboo.va...@enterprisedb.com> wrote:
>>>


 On 21 Mar 2018 19:41, "Joao De Almeida Pereira" <
 jdealmeidapere...@pivotal.io> wrote:

 Hello Hackers,
 Can anyone use the current master branch?
 When I try to open a server I get a 428. Is that only me?

 May be because of cookie changes.
 Check your config.py and config_local.py if you have done changes
 related to DEFAULT_SERVER in your config_local.py then you need to 
 change
 other 2 cookie related variables also.

 Thanks
 Joao



>>
>

Re: Experiencing issues

[Dave Page]

On Wed, Mar 21, 2018 at 3:57 PM, Joao De Almeida Pereira <
jdealmeidapere...@pivotal.io> wrote:

> Sorry I did not understand what you said.
> This configuration:
>
> DEFAULT_SERVER = '0.0.0.0'
> SESSION_COOKIE_DOMAIN = DEFAULT_SERVER
> COOKIE_DEFAULT_DOMAIN = DEFAULT_SERVER
>
> If the application lives in the domain pgadmin.somedomain.com do I need
> to have in config_local:
> DEFAULT_SERVER = '0.0.0.0'
> SESSION_COOKIE_DOMAIN = 'pgadmin.somedomain.com'
> COOKIE_DEFAULT_DOMAIN = 'pgadmin.somedomain.com'
> ?
>
> Does this mean that if for some reason I have a second domain like
> pgadmin.somedomain2.com that I want to use I cannot?
>
> The issue of 127.0.0.1 to localhost is very cumbersome, and somehow we
> should be able to disable this, because when we are developing doesn't make
> sense to not being able to use localhost and 127.0.0.1
>

+1. I didn't realise we'd added this restriction when I tested the patch.

Perhaps a better approach would be to leave the default cookie handling as
it was, and just expose the domain and path via config options that the
user can set if appropriate for their installation.



>
> Thanks
> Joao
>
> On Wed, Mar 21, 2018 at 11:01 AM Khushboo Vashi <
> khushboo.va...@enterprisedb.com> wrote:
>
>> On Wed, Mar 21, 2018 at 8:27 PM, Joao De Almeida Pereira <
>> jdealmeidapere...@pivotal.io> wrote:
>>
>>> So what you are saying is that if I have a server, I need to do
>>> DEFAULT_SERVER=0.0.0.0 and then set the real domain on the COOKIE domain?
>>>
>>> No I am saying, whatever you set as a DEFAULT_SERVER,  the app can be
>> accessible with that server.
>> As, we have explicitly set  DOMAIN in the cookie setting.
>>
>>> On Wed, Mar 21, 2018 at 10:55 AM Khushboo Vashi <
>>> khushboo.va...@enterprisedb.com> wrote:
>>>
 On Wed, Mar 21, 2018 at 8:10 PM, Joao De Almeida Pereira <
 jdealmeidapere...@pivotal.io> wrote:

> Ok Murtuza you are right,
> Now my question is I have the default server to 127.0.0.1 and I want
> to access it using localhost as well. How can I do this?
>
> No, you can't.
 Domain based cookie will work for that domain and it's sub-domains.

> On Wed, Mar 21, 2018 at 10:39 AM Khushboo Vashi <
> khushboo.va...@enterprisedb.com> wrote:
>
>>
>>
>> On 21 Mar 2018 20:01, "Joao De Almeida Pereira" <
>> jdealmeidapere...@pivotal.io> wrote:
>>
>> I tried that but still nothing. When i check in the inspector for
>> cookies I have none
>>
>> Share your config_local file.
>>
>> On Wed, Mar 21, 2018 at 10:30 AM Murtuza Zabuawala <
>> murtuza.zabuaw...@enterprisedb.com> wrote:
>>
>>> Yes, that's cookie related issue (RM#3197), To fix that I added
>>> below in my config_local.py and it started working again,
>>>
>>> DEFAULT_SERVER = '0.0.0.0'
>>> COOKIE_DEFAULT_DOMAIN = SESSION_COOKIE_DOMAIN = DEFAULT_SERVER
>>>
>>> Clear your browser cookies and server side sessions.
>>>
>>>
>>> --
>>> Regards,
>>> Murtuza Zabuawala
>>> EnterpriseDB: http://www.enterprisedb.com
>>> The Enterprise PostgreSQL Company
>>>
>>>
>>> On Wed, Mar 21, 2018 at 7:55 PM, Joao De Almeida Pereira <
>>> jdealmeidapere...@pivotal.io> wrote:
>>>
 Where can I find information about that?

 On Wed, Mar 21, 2018 at 10:16 AM Khushboo Vashi <
 khushboo.va...@enterprisedb.com> wrote:

>
>
> On 21 Mar 2018 19:41, "Joao De Almeida Pereira" <
> jdealmeidapere...@pivotal.io> wrote:
>
> Hello Hackers,
> Can anyone use the current master branch?
> When I try to open a server I get a 428. Is that only me?
>
> May be because of cookie changes.
> Check your config.py and config_local.py if you have done changes
> related to DEFAULT_SERVER in your config_local.py then you need to 
> change
> other 2 cookie related variables also.
>
> Thanks
> Joao
>
>
>
>>>
>>


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

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

Re: v3.0 release on hold

[Joao De Almeida Pereira]

Hello Dave,
For number 1:
https://blogs.gnome.org/aday/2017/08/31/status-icons-and-gnome/
We might need to build something like:
https://itsfoss.com/best-indicator-applets-ubuntu/
Not sure if it is wise to do it in such a short notice.

Thanks
Joao

On Wed, Mar 21, 2018 at 11:38 AM Khushboo Vashi <
khushboo.va...@enterprisedb.com> wrote:

>
>
> On 21 Mar 2018 21:05, "Dave Page"  wrote:
>
> We've run into a number of unexpected issues with the v3.0 release that I
> think we need to resolve before moving forwards. For the time being, only
> patches critical to fix these issues should be committed.
>
> I'll try to look at 1, though I do have another deadline I need to meet.
> Akshay, can you look at 2 please?
> Fahar is already looking at 3.
> Khushboo, can you look at 4 please?
>
> Sure.
>
>
> Thanks all.
>
> 1) There is no longer a system tray in Gnome 3.26 and later, and thus the
> runtime won't initialise in Fedora 27 and later. We need an alternative for
> this, either a tray replacement that the RPM can depend on, or better yet,
> support whatever it is Gnome expect such apps to use these days.
>
> 2) Starting a second instance of the app bundle on Mac doesn't always open
> a new pgAdmin window as it should. It works fine in the debugger, or if you
> start the app with a command like: "/Applications/pgAdmin\
> 4.app/Contents/MacOS/pgAdmin4". It doesn't work if you double-click the
> appbundle or use a command like "open /Applications/pgAdmin\ 4.app"
>
> 3) Fahar saw a crash on Windows 7. I couldn't reproduce this on my copy,
> but apparently his is a fresh installation.
>
> 4) On my Windows 7 machine, after running a backup I get no status window,
> and see the following in the logs:
>
> Traceback (most recent call last):
>   File "C:\Program Files (x86)\pgAdmin
> 4\v3\venv\Lib\site-packages\werkzeug\serving.py", line 209, in run_wsgi
> execute(self.server.app)
>   File "C:\Program Files (x86)\pgAdmin
> 4\v3\venv\Lib\site-packages\werkzeug\serving.py", line 197, in execute
> application_iter = app(environ, start_response)
>   File "C:\Program Files (x86)\pgAdmin
> 4\v3\venv\Lib\site-packages\flask\app.py", line 1997, in __call__
> return self.wsgi_app(environ, start_response)
>   File "C:\Program Files (x86)\pgAdmin
> 4\v3\venv\Lib\site-packages\flask\app.py", line 1985, in wsgi_app
> response = self.handle_exception(e)
>   File "C:\Program Files (x86)\pgAdmin
> 4\v3\venv\Lib\site-packages\flask\app.py", line 1540, in handle_exception
> reraise(exc_type, exc_value, tb)
>   File "C:\Program Files (x86)\pgAdmin
> 4\v3\venv\Lib\site-packages\flask\app.py", line 1982, in wsgi_app
> response = self.full_dispatch_request()
>   File "C:\Program Files (x86)\pgAdmin
> 4\v3\venv\Lib\site-packages\flask\app.py", line 1614, in
> full_dispatch_request
> rv = self.handle_user_exception(e)
>   File "C:\Program Files (x86)\pgAdmin
> 4\v3\venv\Lib\site-packages\flask\app.py", line 1517, in
> handle_user_exception
> reraise(exc_type, exc_value, tb)
>   File "C:\Program Files (x86)\pgAdmin
> 4\v3\venv\Lib\site-packages\flask\app.py", line 1612, in
> full_dispatch_request
> rv = self.dispatch_request()
>   File "C:\Program Files (x86)\pgAdmin
> 4\v3\venv\Lib\site-packages\flask\app.py", line 1598, in dispatch_request
> return self.view_functions[rule.endpoint](**req.view_args)
>   File "C:\Program Files (x86)\pgAdmin
> 4\v3\venv\Lib\site-packages\flask_login.py", line 792, in decorated_view
> return func(*args, **kwargs)
>   File "C:\Program Files (x86)\pgAdmin
> 4\v3\web\pgadmin\misc\bgprocess\__init__.py", line 62, in index
> return make_response(response=BatchProcess.list())
>   File "C:\Program Files (x86)\pgAdmin
> 4\v3\web\pgadmin\misc\bgprocess\processes.py", line 584, in list
> details = desc.details(p.command, args)
>   File "C:\Program Files (x86)\pgAdmin
> 4\v3\web\pgadmin\tools\backup\__init__.py", line 190, in details
> res += html.safe_str(cmd + self.cmd)
> AttributeError: 'BackupMessage' object has no attribute 'cmd'
>
>
>
> --
> Dave Page
> Blog: http://pgsnake.blogspot.com
> Twitter: @pgsnake
>
> EnterpriseDB UK: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
>
>
>

Re: Experiencing issues

[Joao De Almeida Pereira]

Another thing when I do this configuration:

DEFAULT_SERVER = '127.0.0.1'
SESSION_COOKIE_DOMAIN = 'localhost'
COOKIE_DEFAULT_DOMAIN = 'localhost'

I get the following exception:
builtins.ValueError

ValueError: Setting 'domain' for a cookie on a server running localy (ex:
localhost) is not supportted by complying browsers. You should have
something like: '127.0.0.1 localhost dev.localhost' on your hosts file and
then point your server to run on 'dev.localhost' and also set 'domain' for
'dev.localhost'
And if you follow the instructions and change the hosts file it allows you
to start the application but when you try to open a database server you
will get the 428 error
Thanks
Joao


On Wed, Mar 21, 2018 at 12:01 PM Dave Page  wrote:

> On Wed, Mar 21, 2018 at 3:57 PM, Joao De Almeida Pereira <
> jdealmeidapere...@pivotal.io> wrote:
>
>> Sorry I did not understand what you said.
>> This configuration:
>>
>> DEFAULT_SERVER = '0.0.0.0'
>> SESSION_COOKIE_DOMAIN = DEFAULT_SERVER
>> COOKIE_DEFAULT_DOMAIN = DEFAULT_SERVER
>>
>> If the application lives in the domain pgadmin.somedomain.com do I need
>> to have in config_local:
>> DEFAULT_SERVER = '0.0.0.0'
>> SESSION_COOKIE_DOMAIN = 'pgadmin.somedomain.com'
>> COOKIE_DEFAULT_DOMAIN = 'pgadmin.somedomain.com'
>> ?
>>
>> Does this mean that if for some reason I have a second domain like
>> pgadmin.somedomain2.com that I want to use I cannot?
>>
>> The issue of 127.0.0.1 to localhost is very cumbersome, and somehow we
>> should be able to disable this, because when we are developing doesn't make
>> sense to not being able to use localhost and 127.0.0.1
>>
>
> +1. I didn't realise we'd added this restriction when I tested the patch.
>
> Perhaps a better approach would be to leave the default cookie handling as
> it was, and just expose the domain and path via config options that the
> user can set if appropriate for their installation.
>
>
>
>>
>> Thanks
>> Joao
>>
>> On Wed, Mar 21, 2018 at 11:01 AM Khushboo Vashi <
>> khushboo.va...@enterprisedb.com> wrote:
>>
>>> On Wed, Mar 21, 2018 at 8:27 PM, Joao De Almeida Pereira <
>>> jdealmeidapere...@pivotal.io> wrote:
>>>
 So what you are saying is that if I have a server, I need to do
 DEFAULT_SERVER=0.0.0.0 and then set the real domain on the COOKIE domain?

 No I am saying, whatever you set as a DEFAULT_SERVER,  the app can be
>>> accessible with that server.
>>> As, we have explicitly set  DOMAIN in the cookie setting.
>>>
 On Wed, Mar 21, 2018 at 10:55 AM Khushboo Vashi <
 khushboo.va...@enterprisedb.com> wrote:

> On Wed, Mar 21, 2018 at 8:10 PM, Joao De Almeida Pereira <
> jdealmeidapere...@pivotal.io> wrote:
>
>> Ok Murtuza you are right,
>> Now my question is I have the default server to 127.0.0.1 and I want
>> to access it using localhost as well. How can I do this?
>>
>> No, you can't.
> Domain based cookie will work for that domain and it's sub-domains.
>
>> On Wed, Mar 21, 2018 at 10:39 AM Khushboo Vashi <
>> khushboo.va...@enterprisedb.com> wrote:
>>
>>>
>>>
>>> On 21 Mar 2018 20:01, "Joao De Almeida Pereira" <
>>> jdealmeidapere...@pivotal.io> wrote:
>>>
>>> I tried that but still nothing. When i check in the inspector for
>>> cookies I have none
>>>
>>> Share your config_local file.
>>>
>>> On Wed, Mar 21, 2018 at 10:30 AM Murtuza Zabuawala <
>>> murtuza.zabuaw...@enterprisedb.com> wrote:
>>>
 Yes, that's cookie related issue (RM#3197), To fix that I added
 below in my config_local.py and it started working again,

 DEFAULT_SERVER = '0.0.0.0'
 COOKIE_DEFAULT_DOMAIN = SESSION_COOKIE_DOMAIN = DEFAULT_SERVER

 Clear your browser cookies and server side sessions.


 --
 Regards,
 Murtuza Zabuawala
 EnterpriseDB: http://www.enterprisedb.com
 The Enterprise PostgreSQL Company


 On Wed, Mar 21, 2018 at 7:55 PM, Joao De Almeida Pereira <
 jdealmeidapere...@pivotal.io> wrote:

> Where can I find information about that?
>
> On Wed, Mar 21, 2018 at 10:16 AM Khushboo Vashi <
> khushboo.va...@enterprisedb.com> wrote:
>
>>
>>
>> On 21 Mar 2018 19:41, "Joao De Almeida Pereira" <
>> jdealmeidapere...@pivotal.io> wrote:
>>
>> Hello Hackers,
>> Can anyone use the current master branch?
>> When I try to open a server I get a 428. Is that only me?
>>
>> May be because of cookie changes.
>> Check your config.py and config_local.py if you have done changes
>> related to DEFAULT_SERVER in your config_local.py then you need to 
>> change
>> other 2 cookie related variables also.
>>
>> Thanks
>> Joao
>>
>>
>>

>>>
>
>
> --
> Dave Page
> Blog: h

Re: v3.0 release on hold

[Dave Page]

Hi

On Wed, Mar 21, 2018 at 4:22 PM, Joao De Almeida Pereira <
jdealmeidapere...@pivotal.io> wrote:

> Hello Dave,
> For number 1: https://blogs.gnome.org/aday/2017/08/31/status-icons-
> and-gnome/
> We might need to build something like: https://itsfoss.com/
> best-indicator-applets-ubuntu/
> Not sure if it is wise to do it in such a short notice.
>

Yeah, the problem with the suggested solutions is that they rely on 3rd
party extensions that aren't "real" packages for the OS, so we can't just
add a dependency on them. Unfortunately I think this is going to cause
quite a bit of work to get 3.0 back on track.


>
> Thanks
> Joao
>
> On Wed, Mar 21, 2018 at 11:38 AM Khushboo Vashi <
> khushboo.va...@enterprisedb.com> wrote:
>
>>
>>
>> On 21 Mar 2018 21:05, "Dave Page"  wrote:
>>
>> We've run into a number of unexpected issues with the v3.0 release that I
>> think we need to resolve before moving forwards. For the time being, only
>> patches critical to fix these issues should be committed.
>>
>> I'll try to look at 1, though I do have another deadline I need to meet.
>> Akshay, can you look at 2 please?
>> Fahar is already looking at 3.
>> Khushboo, can you look at 4 please?
>>
>> Sure.
>>
>>
>> Thanks all.
>>
>> 1) There is no longer a system tray in Gnome 3.26 and later, and thus the
>> runtime won't initialise in Fedora 27 and later. We need an alternative for
>> this, either a tray replacement that the RPM can depend on, or better yet,
>> support whatever it is Gnome expect such apps to use these days.
>>
>> 2) Starting a second instance of the app bundle on Mac doesn't always
>> open a new pgAdmin window as it should. It works fine in the debugger, or
>> if you start the app with a command like: "/Applications/pgAdmin\
>> 4.app/Contents/MacOS/pgAdmin4". It doesn't work if you double-click the
>> appbundle or use a command like "open /Applications/pgAdmin\ 4.app"
>>
>> 3) Fahar saw a crash on Windows 7. I couldn't reproduce this on my copy,
>> but apparently his is a fresh installation.
>>
>> 4) On my Windows 7 machine, after running a backup I get no status
>> window, and see the following in the logs:
>>
>> Traceback (most recent call last):
>>   File "C:\Program Files (x86)\pgAdmin 
>> 4\v3\venv\Lib\site-packages\werkzeug\serving.py",
>> line 209, in run_wsgi
>> execute(self.server.app)
>>   File "C:\Program Files (x86)\pgAdmin 
>> 4\v3\venv\Lib\site-packages\werkzeug\serving.py",
>> line 197, in execute
>> application_iter = app(environ, start_response)
>>   File "C:\Program Files (x86)\pgAdmin 
>> 4\v3\venv\Lib\site-packages\flask\app.py",
>> line 1997, in __call__
>> return self.wsgi_app(environ, start_response)
>>   File "C:\Program Files (x86)\pgAdmin 
>> 4\v3\venv\Lib\site-packages\flask\app.py",
>> line 1985, in wsgi_app
>> response = self.handle_exception(e)
>>   File "C:\Program Files (x86)\pgAdmin 
>> 4\v3\venv\Lib\site-packages\flask\app.py",
>> line 1540, in handle_exception
>> reraise(exc_type, exc_value, tb)
>>   File "C:\Program Files (x86)\pgAdmin 
>> 4\v3\venv\Lib\site-packages\flask\app.py",
>> line 1982, in wsgi_app
>> response = self.full_dispatch_request()
>>   File "C:\Program Files (x86)\pgAdmin 
>> 4\v3\venv\Lib\site-packages\flask\app.py",
>> line 1614, in full_dispatch_request
>> rv = self.handle_user_exception(e)
>>   File "C:\Program Files (x86)\pgAdmin 
>> 4\v3\venv\Lib\site-packages\flask\app.py",
>> line 1517, in handle_user_exception
>> reraise(exc_type, exc_value, tb)
>>   File "C:\Program Files (x86)\pgAdmin 
>> 4\v3\venv\Lib\site-packages\flask\app.py",
>> line 1612, in full_dispatch_request
>> rv = self.dispatch_request()
>>   File "C:\Program Files (x86)\pgAdmin 
>> 4\v3\venv\Lib\site-packages\flask\app.py",
>> line 1598, in dispatch_request
>> return self.view_functions[rule.endpoint](**req.view_args)
>>   File "C:\Program Files (x86)\pgAdmin 
>> 4\v3\venv\Lib\site-packages\flask_login.py",
>> line 792, in decorated_view
>> return func(*args, **kwargs)
>>   File "C:\Program Files (x86)\pgAdmin 
>> 4\v3\web\pgadmin\misc\bgprocess\__init__.py",
>> line 62, in index
>> return make_response(response=BatchProcess.list())
>>   File "C:\Program Files (x86)\pgAdmin 
>> 4\v3\web\pgadmin\misc\bgprocess\processes.py",
>> line 584, in list
>> details = desc.details(p.command, args)
>>   File "C:\Program Files (x86)\pgAdmin 
>> 4\v3\web\pgadmin\tools\backup\__init__.py",
>> line 190, in details
>> res += html.safe_str(cmd + self.cmd)
>> AttributeError: 'BackupMessage' object has no attribute 'cmd'
>>
>>
>>
>> --
>> 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

Re: v3.0 release on hold

[Joao De Almeida Pereira]

Hi Dave,
I think that this Gnome issue should be addressed after the release of 3.0.
We should create a bug and see the best way to address it after. This is my
proposal, because I am not 100% sure where this application indicator
should live.
If we search the web for application indicators we can see that usually
these are developed by 3rd parties and is are present at the applications
repository, so this might be a side project that need to be undertaken, by
someone in the community or not, but it is not something that should live
inside our repository as it is not really part of the code source and it is
more like a Hack for Gnome.

The other issues I believe need to be addressed, specially if they are
crippling to the application like when you click it does not start, but if
they are edge cases, we can always release this week and have a new release
in 2 weeks or something with more fixes to these edge case problems.

I understand that the process of release at this point is a bit cumbersome
and take a lot of time, but  if we can get more tests around the new and
old feature we can have more confidence in our code and as a result of that
we can automate some of the steps in order to generate binaries more
frequently.

Thanks
Joao

On Wed, Mar 21, 2018 at 12:54 PM Dave Page  wrote:

> Hi
>
> On Wed, Mar 21, 2018 at 4:22 PM, Joao De Almeida Pereira <
> jdealmeidapere...@pivotal.io> wrote:
>
>> Hello Dave,
>> For number 1:
>> https://blogs.gnome.org/aday/2017/08/31/status-icons-and-gnome/
>> We might need to build something like:
>> https://itsfoss.com/best-indicator-applets-ubuntu/
>> Not sure if it is wise to do it in such a short notice.
>>
>
> Yeah, the problem with the suggested solutions is that they rely on 3rd
> party extensions that aren't "real" packages for the OS, so we can't just
> add a dependency on them. Unfortunately I think this is going to cause
> quite a bit of work to get 3.0 back on track.
>
>
>>
>> Thanks
>> Joao
>>
>> On Wed, Mar 21, 2018 at 11:38 AM Khushboo Vashi <
>> khushboo.va...@enterprisedb.com> wrote:
>>
>>>
>>>
>>> On 21 Mar 2018 21:05, "Dave Page"  wrote:
>>>
>>> We've run into a number of unexpected issues with the v3.0 release that
>>> I think we need to resolve before moving forwards. For the time being, only
>>> patches critical to fix these issues should be committed.
>>>
>>> I'll try to look at 1, though I do have another deadline I need to meet.
>>> Akshay, can you look at 2 please?
>>> Fahar is already looking at 3.
>>> Khushboo, can you look at 4 please?
>>>
>>> Sure.
>>>
>>>
>>> Thanks all.
>>>
>>> 1) There is no longer a system tray in Gnome 3.26 and later, and thus
>>> the runtime won't initialise in Fedora 27 and later. We need an alternative
>>> for this, either a tray replacement that the RPM can depend on, or better
>>> yet, support whatever it is Gnome expect such apps to use these days.
>>>
>>> 2) Starting a second instance of the app bundle on Mac doesn't always
>>> open a new pgAdmin window as it should. It works fine in the debugger, or
>>> if you start the app with a command like: "/Applications/pgAdmin\
>>> 4.app/Contents/MacOS/pgAdmin4". It doesn't work if you double-click the
>>> appbundle or use a command like "open /Applications/pgAdmin\ 4.app"
>>>
>>> 3) Fahar saw a crash on Windows 7. I couldn't reproduce this on my copy,
>>> but apparently his is a fresh installation.
>>>
>>> 4) On my Windows 7 machine, after running a backup I get no status
>>> window, and see the following in the logs:
>>>
>>> Traceback (most recent call last):
>>>   File "C:\Program Files (x86)\pgAdmin
>>> 4\v3\venv\Lib\site-packages\werkzeug\serving.py", line 209, in run_wsgi
>>> execute(self.server.app)
>>>   File "C:\Program Files (x86)\pgAdmin
>>> 4\v3\venv\Lib\site-packages\werkzeug\serving.py", line 197, in execute
>>> application_iter = app(environ, start_response)
>>>   File "C:\Program Files (x86)\pgAdmin
>>> 4\v3\venv\Lib\site-packages\flask\app.py", line 1997, in __call__
>>> return self.wsgi_app(environ, start_response)
>>>   File "C:\Program Files (x86)\pgAdmin
>>> 4\v3\venv\Lib\site-packages\flask\app.py", line 1985, in wsgi_app
>>> response = self.handle_exception(e)
>>>   File "C:\Program Files (x86)\pgAdmin
>>> 4\v3\venv\Lib\site-packages\flask\app.py", line 1540, in handle_exception
>>> reraise(exc_type, exc_value, tb)
>>>   File "C:\Program Files (x86)\pgAdmin
>>> 4\v3\venv\Lib\site-packages\flask\app.py", line 1982, in wsgi_app
>>> response = self.full_dispatch_request()
>>>   File "C:\Program Files (x86)\pgAdmin
>>> 4\v3\venv\Lib\site-packages\flask\app.py", line 1614, in
>>> full_dispatch_request
>>> rv = self.handle_user_exception(e)
>>>   File "C:\Program Files (x86)\pgAdmin
>>> 4\v3\venv\Lib\site-packages\flask\app.py", line 1517, in
>>> handle_user_exception
>>> reraise(exc_type, exc_value, tb)
>>>   File "C:\Program Files (x86)\pgAdmin
>>> 4\v3\venv\Lib\site-packages\flask\app.py", line 1612, in
>>> full_dispatch_r

Re: Connection Refused Error

[Joao De Almeida Pereira]

Hello Rahul,
Did you change the /etc/postgresql/10/main/pg_hba.conf  file configuration
to allow connections? if not take a look at
https://www.thegeekstuff.com/2014/02/enable-remote-postgresql-connection/ this
should guide you but basically you need to change the METHOD to `trust` on
the 127.0.0.1 address and eventually of the ::1 as well.
If that didn't help let us know

Thanks
Joao

On Wed, Mar 21, 2018 at 3:35 PM Rahul Soshte 
wrote:

> I had installed pgadmin4 from git Source repo.The First time I Installed I
> was able to create a Server.But when I restarted my PC.I got this error.
>
> Unable to connect to server:
>
> could not connect to server: Connection refused
> Is the server running on host "127.0.0.1" and accepting
> TCP/IP connections on port 5432?
>
> I tried Installing everthing Again but got the same error.I also changed
> postgresql.conf file from
> listen_address="localhost"
> to listen_address="*"
> but it still didnt work.
>
> What do I do?
>

Re: Connection Refused Error

[Rahul Soshte]

Hi,
I solved the bug,actually what I had done was I had installed postgresql
without the version number i.e using this command

sudo apt-get install postgresql

I uninstalled postgresql using this command

sudo apt-get remove --purge postgresql-9.6


and reinstalled with the version number i.e

sudo apt-get install postgresql-9.6


I was actually facing this issue

https://askubuntu.com/questions/50621/cannot-connect-to-postgresql-on-port-5432

On Thu, Mar 22, 2018 at 1:23 AM, Joao De Almeida Pereira <
jdealmeidapere...@pivotal.io> wrote:

> Hello Rahul,
> Did you change the /etc/postgresql/10/main/pg_hba.conf  file
> configuration to allow connections? if not take a look at
> https://www.thegeekstuff.com/2014/02/enable-remote-postgresql-connection/ this
> should guide you but basically you need to change the METHOD to `trust` on
> the 127.0.0.1 address and eventually of the ::1 as well.
> If that didn't help let us know
>
> Thanks
> Joao
>
> On Wed, Mar 21, 2018 at 3:35 PM Rahul Soshte 
> wrote:
>
>> I had installed pgadmin4 from git Source repo.The First time I Installed
>> I was able to create a Server.But when I restarted my PC.I got this error.
>>
>> Unable to connect to server:
>>
>> could not connect to server: Connection refused
>> Is the server running on host "127.0.0.1" and accepting
>> TCP/IP connections on port 5432?
>>
>> I tried Installing everthing Again but got the same error.I also changed
>> postgresql.conf file from
>> listen_address="localhost"
>> to listen_address="*"
>> but it still didnt work.
>>
>> What do I do?
>>
>

Re: Experiencing issues

[Khushboo Vashi]

On Wed, Mar 21, 2018 at 10:00 PM, Joao De Almeida Pereira <
jdealmeidapere...@pivotal.io> wrote:

> Another thing when I do this configuration:
>
> DEFAULT_SERVER = '127.0.0.1'
> SESSION_COOKIE_DOMAIN = 'localhost'
> COOKIE_DEFAULT_DOMAIN = 'localhost'
>
> I get the following exception:
> builtins.ValueError
>
> ValueError: Setting 'domain' for a cookie on a server running localy (ex:
> localhost) is not supportted by complying browsers. You should have
> something like: '127.0.0.1 localhost dev.localhost' on your hosts file and
> then point your server to run on 'dev.localhost' and also set 'domain' for
> 'dev.localhost'
> And if you follow the instructions and change the hosts file it allows you
> to start the application but when you try to open a database server you
> will get the 428 error
> Thanks
> Joao
>
> Right, many browser doesn't support localhost as a cookie domain.
The settings you did is not correct, your cookie will be stored as a
'localhost' domain and you trying to run the app as 127.0.0.1.
If we set a domain for the cookie than either that domain or sub-domains
can access that cookie.

In regards to your question of 2 domain names, this type of situation
arrives when any site is configured explicitly to divide the load. In case
of pgAdmin 4, this is not going to happen :).
It is always recommend to use cookie with domain settings, but as Dave
suggested we can leave that upto user. So, we will make it configurable and
user will decide to have it or not.


>
> On Wed, Mar 21, 2018 at 12:01 PM Dave Page  wrote:
>
>> On Wed, Mar 21, 2018 at 3:57 PM, Joao De Almeida Pereira <
>> jdealmeidapere...@pivotal.io> wrote:
>>
>>> Sorry I did not understand what you said.
>>> This configuration:
>>>
>>> DEFAULT_SERVER = '0.0.0.0'
>>> SESSION_COOKIE_DOMAIN = DEFAULT_SERVER
>>> COOKIE_DEFAULT_DOMAIN = DEFAULT_SERVER
>>>
>>> If the application lives in the domain pgadmin.somedomain.com do I need
>>> to have in config_local:
>>> DEFAULT_SERVER = '0.0.0.0'
>>> SESSION_COOKIE_DOMAIN = 'pgadmin.somedomain.com'
>>> COOKIE_DEFAULT_DOMAIN = 'pgadmin.somedomain.com'
>>> ?
>>>
>>> Does this mean that if for some reason I have a second domain like
>>> pgadmin.somedomain2.com that I want to use I cannot?
>>>
>>> The issue of 127.0.0.1 to localhost is very cumbersome, and somehow we
>>> should be able to disable this, because when we are developing doesn't make
>>> sense to not being able to use localhost and 127.0.0.1
>>>
>>
>> +1. I didn't realise we'd added this restriction when I tested the patch.
>>
>> Perhaps a better approach would be to leave the default cookie handling
>> as it was, and just expose the domain and path via config options that the
>> user can set if appropriate for their installation.
>>
>>
>>
>>>
>>> Thanks
>>> Joao
>>>
>>> On Wed, Mar 21, 2018 at 11:01 AM Khushboo Vashi <
>>> khushboo.va...@enterprisedb.com> wrote:
>>>
 On Wed, Mar 21, 2018 at 8:27 PM, Joao De Almeida Pereira <
 jdealmeidapere...@pivotal.io> wrote:

> So what you are saying is that if I have a server, I need to do
> DEFAULT_SERVER=0.0.0.0 and then set the real domain on the COOKIE domain?
>
> No I am saying, whatever you set as a DEFAULT_SERVER,  the app can be
 accessible with that server.
 As, we have explicitly set  DOMAIN in the cookie setting.

> On Wed, Mar 21, 2018 at 10:55 AM Khushboo Vashi <
> khushboo.va...@enterprisedb.com> wrote:
>
>> On Wed, Mar 21, 2018 at 8:10 PM, Joao De Almeida Pereira <
>> jdealmeidapere...@pivotal.io> wrote:
>>
>>> Ok Murtuza you are right,
>>> Now my question is I have the default server to 127.0.0.1 and I want
>>> to access it using localhost as well. How can I do this?
>>>
>>> No, you can't.
>> Domain based cookie will work for that domain and it's sub-domains.
>>
>>> On Wed, Mar 21, 2018 at 10:39 AM Khushboo Vashi <
>>> khushboo.va...@enterprisedb.com> wrote:
>>>


 On 21 Mar 2018 20:01, "Joao De Almeida Pereira" <
 jdealmeidapere...@pivotal.io> wrote:

 I tried that but still nothing. When i check in the inspector for
 cookies I have none

 Share your config_local file.

 On Wed, Mar 21, 2018 at 10:30 AM Murtuza Zabuawala <
 murtuza.zabuaw...@enterprisedb.com> wrote:

> Yes, that's cookie related issue (RM#3197), To fix that I added
> below in my config_local.py and it started working again,
>
> DEFAULT_SERVER = '0.0.0.0'
> COOKIE_DEFAULT_DOMAIN = SESSION_COOKIE_DOMAIN = DEFAULT_SERVER
>
> Clear your browser cookies and server side sessions.
>
>
> --
> Regards,
> Murtuza Zabuawala
> EnterpriseDB: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
>
>
> On Wed, Mar 21, 2018 at 7:55 PM, Joao De Almeida Pereira <
> jdealmeidaper

Re: v3.0 release on hold

[Akshay Joshi]

On 21 Mar 2018 21:05, "Dave Page"  wrote:

We've run into a number of unexpected issues with the v3.0 release that I
think we need to resolve before moving forwards. For the time being, only
patches critical to fix these issues should be committed.

I'll try to look at 1, though I do have another deadline I need to meet.
Akshay, can you look at 2 please?


Sure. I'll

Fahar is already looking at 3.
Khushboo, can you look at 4 please?

Thanks all.

1) There is no longer a system tray in Gnome 3.26 and later, and thus the
runtime won't initialise in Fedora 27 and later. We need an alternative for
this, either a tray replacement that the RPM can depend on, or better yet,
support whatever it is Gnome expect such apps to use these days.

2) Starting a second instance of the app bundle on Mac doesn't always open
a new pgAdmin window as it should. It works fine in the debugger, or if you
start the app with a command like: "/Applications/pgAdmin\
4.app/Contents/MacOS/pgAdmin4". It doesn't work if you double-click the
appbundle or use a command like "open /Applications/pgAdmin\ 4.app"

3) Fahar saw a crash on Windows 7. I couldn't reproduce this on my copy,
but apparently his is a fresh installation.

4) On my Windows 7 machine, after running a backup I get no status window,
and see the following in the logs:

Traceback (most recent call last):
  File "C:\Program Files (x86)\pgAdmin
4\v3\venv\Lib\site-packages\werkzeug\serving.py",
line 209, in run_wsgi
execute(self.server.app)
  File "C:\Program Files (x86)\pgAdmin
4\v3\venv\Lib\site-packages\werkzeug\serving.py",
line 197, in execute
application_iter = app(environ, start_response)
  File "C:\Program Files (x86)\pgAdmin
4\v3\venv\Lib\site-packages\flask\app.py",
line 1997, in __call__
return self.wsgi_app(environ, start_response)
  File "C:\Program Files (x86)\pgAdmin
4\v3\venv\Lib\site-packages\flask\app.py",
line 1985, in wsgi_app
response = self.handle_exception(e)
  File "C:\Program Files (x86)\pgAdmin
4\v3\venv\Lib\site-packages\flask\app.py",
line 1540, in handle_exception
reraise(exc_type, exc_value, tb)
  File "C:\Program Files (x86)\pgAdmin
4\v3\venv\Lib\site-packages\flask\app.py",
line 1982, in wsgi_app
response = self.full_dispatch_request()
  File "C:\Program Files (x86)\pgAdmin
4\v3\venv\Lib\site-packages\flask\app.py",
line 1614, in full_dispatch_request
rv = self.handle_user_exception(e)
  File "C:\Program Files (x86)\pgAdmin
4\v3\venv\Lib\site-packages\flask\app.py",
line 1517, in handle_user_exception
reraise(exc_type, exc_value, tb)
  File "C:\Program Files (x86)\pgAdmin
4\v3\venv\Lib\site-packages\flask\app.py",
line 1612, in full_dispatch_request
rv = self.dispatch_request()
  File "C:\Program Files (x86)\pgAdmin
4\v3\venv\Lib\site-packages\flask\app.py",
line 1598, in dispatch_request
return self.view_functions[rule.endpoint](**req.view_args)
  File "C:\Program Files (x86)\pgAdmin
4\v3\venv\Lib\site-packages\flask_login.py",
line 792, in decorated_view
return func(*args, **kwargs)
  File "C:\Program Files (x86)\pgAdmin
4\v3\web\pgadmin\misc\bgprocess\__init__.py",
line 62, in index
return make_response(response=BatchProcess.list())
  File "C:\Program Files (x86)\pgAdmin
4\v3\web\pgadmin\misc\bgprocess\processes.py",
line 584, in list
details = desc.details(p.command, args)
  File "C:\Program Files (x86)\pgAdmin
4\v3\web\pgadmin\tools\backup\__init__.py",
line 190, in details
res += html.safe_str(cmd + self.cmd)
AttributeError: 'BackupMessage' object has no attribute 'cmd'



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

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