Re: [pgadmin-hackers] First time launch as simple user (improvement needed)
Hi
On Mon, Jan 16, 2017 at 5:20 PM, Bruno Friedmann wrote:
> In packaged world, the user will have a pgAdmin4.desktop file to be able to
> run it from normal menus.
Yes.
> I've just tested a full fresh install on user system, and if it is run from
> graphical environnement, nobody will see the console output
> The configuration database - '/ioda/home/bruno/.pgadmin/pgadmin4.db' does not
> exist.
> Entering initial setup mode...
> NOTE: Configuring authentication for SERVER mode.
> Enter the email address and password to use for the initial pgAdmin user
> account:
Right - but why would you run it in server mode under a graphical
environment? Server mode is intended for people running in multi-user
mode behind a webserver - in which case the docs are pretty clear that
the user should manually run setup.py from the command line.
If you're in graphical mode (what we call desktop mode), then there
are no prompts.
> The console is "polluated" by the graphical engine, leading to a confused
> user.
>
> What or how can the situation be improved to be able to send pgAdmin4 to
> "dumb" end-users ?
>
> Who can I blame for having a setup for font size (in editor super) and not the
> rest of the interface ... see attachment on my external hidpi (192dpi) screen.
> I can't imagine the hassle to live with so small fonts on the internal laptop
> screen at 288dpi :-)))
I'm not sure why you've got such differences in font size, unless
you've changed your config (the query tool/SQL box font size is
specified in em units in File -> Preferences -> SQL Editor -> Options.
On my retina display, the defaults seem to work nicely. I haven't
heard of anyone else experiencing a mismatch.
The zoom level might be an issue under some OSs. macOS handles it just
fine, but I know on some Windows setups the default is unusably small.
We probably need some code in the runtime to auto-adjust the zoom
level in such cases.
> Last things I found strange is the connection to
> CLOSE-WAIT 1 0 10.26.8.2:43718 192.0.73.2:443
> users:(("pgAdmin4",pid=11818,fd=109))
> the ip point to automattic inc (automattic.com)
>
> I don't know what it does, nor the purpose for that, but I'm afraid to have to
> give an anwser to openSUSE security team if they digg in, and also to
> suspicious users.
I have no idea what that is, and can't find any reference to either
the IP or domain in the code. I also cannot reproduce it on my
machine.
I wonder if it could be Qt Web Engine loading some plugin you have for
Chrome or something like that?
Can you reproduce it outside of the pgAdmin runtime?
--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake
EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgadmin-hackers
Re: [pgadmin-hackers] [pgAdmin4][Patch]: RM1840 - cannot create gist index due to enforced ASC, DESC options in generated SQL
Hi On Fri, Jan 13, 2017 at 6:50 AM, Surinder Kumar wrote: > Hi > > Please find updated patch following changes: > 1) Keep field 'opclass' combo box enabled. That doesn't seem to be working. > 2) Keep ASC/DESC and NULLs FIRST/LAST options disable for access methods > other than 'btree'. > 3) Add validation for name field. Those bits do though :-) Please fix 1). Thanks! > On Fri, Nov 25, 2016 at 5:16 PM, Dave Page wrote: >> >> On Thu, Nov 24, 2016 at 12:13 PM, Surinder Kumar >> wrote: >> > Hi >> > >> > Please find updated patch with change. >> > >> > On Fri, Oct 21, 2016 at 9:16 PM, Dave Page wrote: >> >> >> >> On Fri, Oct 21, 2016 at 4:42 PM, Surinder Kumar >> >> wrote: >> >> > On Fri, Oct 21, 2016 at 8:52 PM, Dave Page wrote: >> >> >> >> >> >> Hi >> >> >> >> >> >> On Fri, Oct 21, 2016 at 4:16 PM, Surinder Kumar >> >> >> wrote: >> >> >> > Hi >> >> >> > >> >> >> > This fix is for exclusion constraint. >> >> >> > The options like "order" and "nulls" must be conditional. i.e. >> >> >> > include >> >> >> > only >> >> >> > when access method type is other than "gist". >> >> >> >> >> >> When creating an index, the asc/desc options are disabled if >> >> >> gist/gin >> >> >> used. I think they also should be here. >> >> >> >> >> >> Also, what about gin indexes in this case? >> >> > >> >> > As per documentation, >> >> > The access method must support amgettuple (see Chapter 52); at >> >> > present >> >> > this >> >> > means GIN cannot be used >> >> >> >> OK, but this patch (unlike the last one) only seems to check for gist. >> > >> > I have modified the code so It will check for 'gist' and 'spgist' >> >> Hi, >> >> This still doesn't seem right to me. For example, if I choose an >> access method that doesn't have a default operator class for the >> selected data type, Postgres asks me to explicitly choose one, which I >> now can't because the combo box is disabled. Conversely, whilst the >> opclass should probably not be disabled, the ASC/DESC and NULLs >> FIRST/LAST options probably should be disabled (right now, they're >> just ignored). >> >> Thoughts? >> >> -- >> 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 -- Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgadmin-hackers
[pgadmin-hackers] Re: PATCH: RM# 1679 - Background process for "restore" not reporting status back to pgAdmin
Thanks. What log output do you get?
On Tue, Jan 17, 2017 at 9:44 AM, Fahar Abbas
wrote:
> Hi Dave.
>
> After applying this patch on Windows 2012 server 64 with Python 2.7.11 on
> EPAS-9.6 server, Maintenance DB and Backup database failed.
>
> Please find attached the snapshot.
>
> Kind Regards,
>
> On Wed, Jan 11, 2017 at 6:19 PM, Dave Page wrote:
>
>> Hi
>>
>> On Wed, Jan 11, 2017 at 12:28 PM, Ashesh Vashi <
>> ashesh.va...@enterprisedb.com> wrote:
>>
>>> Hi Dave,
>>>
>>> On Wed, Jan 11, 2017 at 12:03 PM, Dave Page wrote:
>>>
KeyError: u'end_time'
The status file contains:
{"start_time": "2017-01-11 06:27:20.939703 +", "pid": 49363,
"exit_code": 0, "end_time": "2017-01-11 06:27:28.613456 +"}
>>>
>>> Thanks for reviewing the patch.
>>> Please find the updated patch.
>>>
>>> Changes:
>>> - Using now ValueError instead of json.JSONDecodeError, which is
>>> subclass of ValueError, to allow to it to work with 2.6+ python.
>>> - Checking the existence of value in dict before accessing it.
>>>
>>>
>>>
>> That seems to work for me in a brief test on my Mac. :-)
>>
>> Fahar; are you able to apply and test this patch on Windows and Linux, in
>> server and desktop modes? Basically all the external processes should be
>> tested - backup, restore & maintenance (vacuum) etc). I don't have any VMs
>> available at the moment due to travel.
>>
>>
>> --
>> Dave Page
>> Blog: http://pgsnake.blogspot.com
>> Twitter: @pgsnake
>>
>> EnterpriseDB UK: http://www.enterprisedb.com
>> The Enterprise PostgreSQL Company
>>
>
>
>
> --
> Syed Fahar Abbas
> Quality Management Group
>
> EnterpriseDB Corporation
> Phone Office: +92-51-835-8874
> Phone Direct: +92-51-8466803 <+92%2051%208466803>
> Mobile: +92-333-5409707 <+92%20333%205409707>
> Skype ID: syed.fahar.abbas
> Website: www.enterprisedb.com
>
--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake
EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
Re: [pgadmin-hackers] [pgAdmin4][Patch]: RM1840 - cannot create gist index due to enforced ASC, DESC options in generated SQL
Hi On Tue, Jan 17, 2017 at 3:08 PM, Dave Page wrote: > Hi > > On Fri, Jan 13, 2017 at 6:50 AM, Surinder Kumar > wrote: > > Hi > > > > Please find updated patch following changes: > > 1) Keep field 'opclass' combo box enabled. > > That doesn't seem to be working. Is the field 'opclass' is not enabled for you?. Can you please tell in which scenario it doesn't gets enabled? so that I can fix it. > > > 2) Keep ASC/DESC and NULLs FIRST/LAST options disable for access methods > > other than 'btree'. > > 3) Add validation for name field. > > Those bits do though :-) > > Please fix 1). > > Thanks! > > > On Fri, Nov 25, 2016 at 5:16 PM, Dave Page wrote: > >> > >> On Thu, Nov 24, 2016 at 12:13 PM, Surinder Kumar > >> wrote: > >> > Hi > >> > > >> > Please find updated patch with change. > >> > > >> > On Fri, Oct 21, 2016 at 9:16 PM, Dave Page wrote: > >> >> > >> >> On Fri, Oct 21, 2016 at 4:42 PM, Surinder Kumar > >> >> wrote: > >> >> > On Fri, Oct 21, 2016 at 8:52 PM, Dave Page > wrote: > >> >> >> > >> >> >> Hi > >> >> >> > >> >> >> On Fri, Oct 21, 2016 at 4:16 PM, Surinder Kumar > >> >> >> wrote: > >> >> >> > Hi > >> >> >> > > >> >> >> > This fix is for exclusion constraint. > >> >> >> > The options like "order" and "nulls" must be conditional. i.e. > >> >> >> > include > >> >> >> > only > >> >> >> > when access method type is other than "gist". > >> >> >> > >> >> >> When creating an index, the asc/desc options are disabled if > >> >> >> gist/gin > >> >> >> used. I think they also should be here. > >> >> >> > >> >> >> Also, what about gin indexes in this case? > >> >> > > >> >> > As per documentation, > >> >> > The access method must support amgettuple (see Chapter 52); at > >> >> > present > >> >> > this > >> >> > means GIN cannot be used > >> >> > >> >> OK, but this patch (unlike the last one) only seems to check for > gist. > >> > > >> > I have modified the code so It will check for 'gist' and 'spgist' > >> > >> Hi, > >> > >> This still doesn't seem right to me. For example, if I choose an > >> access method that doesn't have a default operator class for the > >> selected data type, Postgres asks me to explicitly choose one, which I > >> now can't because the combo box is disabled. Conversely, whilst the > >> opclass should probably not be disabled, the ASC/DESC and NULLs > >> FIRST/LAST options probably should be disabled (right now, they're > >> just ignored). > >> > >> Thoughts? > >> > >> -- > >> 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 >
[pgadmin-hackers] Re: PATCH: RM# 1679 - Background process for "restore" not reporting status back to pgAdmin
Issue is also reproducible with PG-9.6 server.
Regards,
On Tue, Jan 17, 2017 at 2:55 PM, Fahar Abbas
wrote:
> Please attached the log files output from the terminal and pgAdmin4.log.
>
> Kind Regards,
>
>
> On Tue, Jan 17, 2017 at 2:46 PM, Dave Page wrote:
>
>> Thanks. What log output do you get?
>>
>> On Tue, Jan 17, 2017 at 9:44 AM, Fahar Abbas <
>> fahar.ab...@enterprisedb.com> wrote:
>>
>>> Hi Dave.
>>>
>>> After applying this patch on Windows 2012 server 64 with Python 2.7.11
>>> on EPAS-9.6 server, Maintenance DB and Backup database failed.
>>>
>>> Please find attached the snapshot.
>>>
>>> Kind Regards,
>>>
>>> On Wed, Jan 11, 2017 at 6:19 PM, Dave Page wrote:
>>>
Hi
On Wed, Jan 11, 2017 at 12:28 PM, Ashesh Vashi <
ashesh.va...@enterprisedb.com> wrote:
> Hi Dave,
>
> On Wed, Jan 11, 2017 at 12:03 PM, Dave Page wrote:
>
>>
>> KeyError: u'end_time'
>>
>> The status file contains:
>>
>> {"start_time": "2017-01-11 06:27:20.939703 +", "pid": 49363,
>> "exit_code": 0, "end_time": "2017-01-11 06:27:28.613456 +"}
>>
>
> Thanks for reviewing the patch.
> Please find the updated patch.
>
> Changes:
> - Using now ValueError instead of json.JSONDecodeError, which is
> subclass of ValueError, to allow to it to work with 2.6+ python.
> - Checking the existence of value in dict before accessing it.
>
>
>
That seems to work for me in a brief test on my Mac. :-)
Fahar; are you able to apply and test this patch on Windows and Linux,
in server and desktop modes? Basically all the external processes should be
tested - backup, restore & maintenance (vacuum) etc). I don't have any VMs
available at the moment due to travel.
--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake
EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
>>>
>>>
>>>
>>> --
>>> Syed Fahar Abbas
>>> Quality Management Group
>>>
>>> EnterpriseDB Corporation
>>> Phone Office: +92-51-835-8874
>>> Phone Direct: +92-51-8466803 <+92%2051%208466803>
>>> Mobile: +92-333-5409707 <+92%20333%205409707>
>>> Skype ID: syed.fahar.abbas
>>> Website: www.enterprisedb.com
>>>
>>
>>
>>
>> --
>> Dave Page
>> Blog: http://pgsnake.blogspot.com
>> Twitter: @pgsnake
>>
>> EnterpriseDB UK: http://www.enterprisedb.com
>> The Enterprise PostgreSQL Company
>>
>
>
>
> --
> Syed Fahar Abbas
> Quality Management Group
>
> EnterpriseDB Corporation
> Phone Office: +92-51-835-8874
> Phone Direct: +92-51-8466803 <(051)%208466803>
> Mobile: +92-333-5409707 <0333%205409707>
> Skype ID: syed.fahar.abbas
> Website: www.enterprisedb.com
>
--
Syed Fahar Abbas
Quality Management Group
EnterpriseDB Corporation
Phone Office: +92-51-835-8874
Phone Direct: +92-51-8466803
Mobile: +92-333-5409707
Skype ID: syed.fahar.abbas
Website: www.enterprisedb.com
[pgadmin-hackers] Re: PATCH: RM# 1679 - Background process for "restore" not reporting status back to pgAdmin
Not surprising. Don't bother testing that any more for now thanks. I
suspect it's a simple bug that Ashesh can fix pronto.
On Tue, Jan 17, 2017 at 10:02 AM, Fahar Abbas
wrote:
> Issue is also reproducible with PG-9.6 server.
>
> Regards,
>
>
> On Tue, Jan 17, 2017 at 2:55 PM, Fahar Abbas > wrote:
>
>> Please attached the log files output from the terminal and pgAdmin4.log.
>>
>> Kind Regards,
>>
>>
>> On Tue, Jan 17, 2017 at 2:46 PM, Dave Page wrote:
>>
>>> Thanks. What log output do you get?
>>>
>>> On Tue, Jan 17, 2017 at 9:44 AM, Fahar Abbas <
>>> fahar.ab...@enterprisedb.com> wrote:
>>>
Hi Dave.
After applying this patch on Windows 2012 server 64 with Python 2.7.11
on EPAS-9.6 server, Maintenance DB and Backup database failed.
Please find attached the snapshot.
Kind Regards,
On Wed, Jan 11, 2017 at 6:19 PM, Dave Page wrote:
> Hi
>
> On Wed, Jan 11, 2017 at 12:28 PM, Ashesh Vashi <
> ashesh.va...@enterprisedb.com> wrote:
>
>> Hi Dave,
>>
>> On Wed, Jan 11, 2017 at 12:03 PM, Dave Page
>> wrote:
>>
>>>
>>> KeyError: u'end_time'
>>>
>>> The status file contains:
>>>
>>> {"start_time": "2017-01-11 06:27:20.939703 +", "pid": 49363,
>>> "exit_code": 0, "end_time": "2017-01-11 06:27:28.613456 +"}
>>>
>>
>> Thanks for reviewing the patch.
>> Please find the updated patch.
>>
>> Changes:
>> - Using now ValueError instead of json.JSONDecodeError, which is
>> subclass of ValueError, to allow to it to work with 2.6+ python.
>> - Checking the existence of value in dict before accessing it.
>>
>>
>>
> That seems to work for me in a brief test on my Mac. :-)
>
> Fahar; are you able to apply and test this patch on Windows and Linux,
> in server and desktop modes? Basically all the external processes should
> be
> tested - backup, restore & maintenance (vacuum) etc). I don't have any VMs
> available at the moment due to travel.
>
>
> --
> Dave Page
> Blog: http://pgsnake.blogspot.com
> Twitter: @pgsnake
>
> EnterpriseDB UK: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
>
--
Syed Fahar Abbas
Quality Management Group
EnterpriseDB Corporation
Phone Office: +92-51-835-8874
Phone Direct: +92-51-8466803 <+92%2051%208466803>
Mobile: +92-333-5409707 <+92%20333%205409707>
Skype ID: syed.fahar.abbas
Website: www.enterprisedb.com
>>>
>>>
>>>
>>> --
>>> Dave Page
>>> Blog: http://pgsnake.blogspot.com
>>> Twitter: @pgsnake
>>>
>>> EnterpriseDB UK: http://www.enterprisedb.com
>>> The Enterprise PostgreSQL Company
>>>
>>
>>
>>
>> --
>> Syed Fahar Abbas
>> Quality Management Group
>>
>> EnterpriseDB Corporation
>> Phone Office: +92-51-835-8874
>> Phone Direct: +92-51-8466803 <(051)%208466803>
>> Mobile: +92-333-5409707 <0333%205409707>
>> Skype ID: syed.fahar.abbas
>> Website: www.enterprisedb.com
>>
>
>
>
> --
> Syed Fahar Abbas
> Quality Management Group
>
> EnterpriseDB Corporation
> Phone Office: +92-51-835-8874
> Phone Direct: +92-51-8466803 <+92%2051%208466803>
> Mobile: +92-333-5409707 <+92%20333%205409707>
> Skype ID: syed.fahar.abbas
> Website: www.enterprisedb.com
>
--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake
EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
Re: [pgadmin-hackers] [pgAdmin4][Patch]: RM1840 - cannot create gist index due to enforced ASC, DESC options in generated SQL
Hi On Tue, Jan 17, 2017 at 9:52 AM, Surinder Kumar wrote: > Hi > On Tue, Jan 17, 2017 at 3:08 PM, Dave Page wrote: >> >> Hi >> >> On Fri, Jan 13, 2017 at 6:50 AM, Surinder Kumar >> wrote: >> > Hi >> > >> > Please find updated patch following changes: >> > 1) Keep field 'opclass' combo box enabled. >> >> That doesn't seem to be working. > > Is the field 'opclass' is not enabled for you?. No. > Can you please tell in which scenario it doesn't gets enabled? so that I can > fix it. PostgreSQL 9.4, table: CREATE TABLE public.foo ( id text COLLATE pg_catalog."default" NOT NULL, data1 text COLLATE pg_catalog."default", CONSTRAINT foo_pkey1 PRIMARY KEY (id), CONSTRAINT gerp1 UNIQUE (id, data1) ) 1) Right-click, Create index 2) Name: 3) Access method: gist 4) Add column. Select id (note the opclass field is not enabled) 5) Add column. Select data1 (note the opclass field is not enabled). 6) Click save, and behold the following error in all it's glory :-) ERROR: data type text has no default operator class for access method "gist" HINT: You must specify an operator class for the index or define a default operator class for the data type. -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgadmin-hackers
[pgadmin-hackers] Re: PATCH: RM# 1679 - Background process for "restore" not reporting status back to pgAdmin
Thanks Dave.
On Tue, Jan 17, 2017 at 3:07 PM, Dave Page wrote:
> Not surprising. Don't bother testing that any more for now thanks. I
> suspect it's a simple bug that Ashesh can fix pronto.
>
> On Tue, Jan 17, 2017 at 10:02 AM, Fahar Abbas <
> fahar.ab...@enterprisedb.com> wrote:
>
>> Issue is also reproducible with PG-9.6 server.
>>
>> Regards,
>>
>>
>> On Tue, Jan 17, 2017 at 2:55 PM, Fahar Abbas <
>> fahar.ab...@enterprisedb.com> wrote:
>>
>>> Please attached the log files output from the terminal and pgAdmin4.log.
>>>
>>> Kind Regards,
>>>
>>>
>>> On Tue, Jan 17, 2017 at 2:46 PM, Dave Page wrote:
>>>
Thanks. What log output do you get?
On Tue, Jan 17, 2017 at 9:44 AM, Fahar Abbas <
fahar.ab...@enterprisedb.com> wrote:
> Hi Dave.
>
> After applying this patch on Windows 2012 server 64 with Python 2.7.11
> on EPAS-9.6 server, Maintenance DB and Backup database failed.
>
> Please find attached the snapshot.
>
> Kind Regards,
>
> On Wed, Jan 11, 2017 at 6:19 PM, Dave Page wrote:
>
>> Hi
>>
>> On Wed, Jan 11, 2017 at 12:28 PM, Ashesh Vashi <
>> ashesh.va...@enterprisedb.com> wrote:
>>
>>> Hi Dave,
>>>
>>> On Wed, Jan 11, 2017 at 12:03 PM, Dave Page
>>> wrote:
>>>
KeyError: u'end_time'
The status file contains:
{"start_time": "2017-01-11 06:27:20.939703 +", "pid": 49363,
"exit_code": 0, "end_time": "2017-01-11 06:27:28.613456 +"}
>>>
>>> Thanks for reviewing the patch.
>>> Please find the updated patch.
>>>
>>> Changes:
>>> - Using now ValueError instead of json.JSONDecodeError, which is
>>> subclass of ValueError, to allow to it to work with 2.6+ python.
>>> - Checking the existence of value in dict before accessing it.
>>>
>>>
>>>
>> That seems to work for me in a brief test on my Mac. :-)
>>
>> Fahar; are you able to apply and test this patch on Windows and
>> Linux, in server and desktop modes? Basically all the external processes
>> should be tested - backup, restore & maintenance (vacuum) etc). I don't
>> have any VMs available at the moment due to travel.
>>
>>
>> --
>> Dave Page
>> Blog: http://pgsnake.blogspot.com
>> Twitter: @pgsnake
>>
>> EnterpriseDB UK: http://www.enterprisedb.com
>> The Enterprise PostgreSQL Company
>>
>
>
>
> --
> Syed Fahar Abbas
> Quality Management Group
>
> EnterpriseDB Corporation
> Phone Office: +92-51-835-8874
> Phone Direct: +92-51-8466803 <+92%2051%208466803>
> Mobile: +92-333-5409707 <+92%20333%205409707>
> Skype ID: syed.fahar.abbas
> Website: www.enterprisedb.com
>
--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake
EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
>>>
>>>
>>>
>>> --
>>> Syed Fahar Abbas
>>> Quality Management Group
>>>
>>> EnterpriseDB Corporation
>>> Phone Office: +92-51-835-8874
>>> Phone Direct: +92-51-8466803 <(051)%208466803>
>>> Mobile: +92-333-5409707 <0333%205409707>
>>> Skype ID: syed.fahar.abbas
>>> Website: www.enterprisedb.com
>>>
>>
>>
>>
>> --
>> Syed Fahar Abbas
>> Quality Management Group
>>
>> EnterpriseDB Corporation
>> Phone Office: +92-51-835-8874
>> Phone Direct: +92-51-8466803 <+92%2051%208466803>
>> Mobile: +92-333-5409707 <+92%20333%205409707>
>> Skype ID: syed.fahar.abbas
>> Website: www.enterprisedb.com
>>
>
>
>
> --
> Dave Page
> Blog: http://pgsnake.blogspot.com
> Twitter: @pgsnake
>
> EnterpriseDB UK: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
>
--
Syed Fahar Abbas
Quality Management Group
EnterpriseDB Corporation
Phone Office: +92-51-835-8874
Phone Direct: +92-51-8466803
Mobile: +92-333-5409707
Skype ID: syed.fahar.abbas
Website: www.enterprisedb.com
[pgadmin-hackers] pgAdmin 4 commit: Improve display of columns of exclusion contraints an
Improve display of columns of exclusion contraints and foreign keys in the properties lists. Fixes #2065 Branch -- master Details --- http://git.postgresql.org/gitweb?p=pgadmin4.git;a=commitdiff;h=28621999f22805852cd19ad7dca2a72cfb676e7e Author: Murtuza Zabuawala Modified Files -- .../exclusion_constraint/js/exclusion_constraint.js | 12 .../foreign_key/templates/foreign_key/js/foreign_key.js | 9 +++-- web/pgadmin/static/js/backform.pgadmin.js| 5 + web/pgadmin/static/js/backgrid/backgrid.pgadmin.js | 5 + 4 files changed, 25 insertions(+), 6 deletions(-) -- Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgadmin-hackers
Re: [pgadmin-hackers] PATCH: To display column information properly in Properties Panel (pgAdmin4)
Hi On Fri, Jan 13, 2017 at 9:31 AM, Murtuza Zabuawala wrote: > Hi, > > PFA patch to display columns in Properties panel for exclusion constraint > node, and in addition to that I found similar issue with foreign key node. > > We will also remove placeholder from Select2 control if it's in Properties > panel or disabled, it will be generic change in Select2 control in Backform > as well as in Backgrid. > RM#2065 A further improvement would be to omit the control entirely in the properties list, so we just display the text. That's for another day though :-). Thanks - patch applied. -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgadmin-hackers
Re: [pgadmin-hackers] PATCH: To fix the issue in Variable control (pgAdmin4)
Thanks, patch applied. On Fri, Jan 13, 2017 at 12:29 PM, Murtuza Zabuawala wrote: > Hi, > > PFA patch to fix the issue where variable control was not displaying values > properly in edit mode. > This issue was due to wrong value set in model. > RM#2067 > > -- > Regards, > Murtuza Zabuawala > EnterpriseDB: http://www.enterprisedb.com > The Enterprise PostgreSQL Company > > > -- > Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgadmin-hackers > -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgadmin-hackers
[pgadmin-hackers] pgAdmin 4 commit: Fix display of enum GUCs on users/databases etc. Fixe
Fix display of enum GUCs on users/databases etc. Fixes #2067 Branch -- master Details --- http://git.postgresql.org/gitweb?p=pgadmin4.git;a=commitdiff;h=6557433061a471262e05080d16b2c6b34edc5aa2 Author: Murtuza Zabuawala Modified Files -- web/pgadmin/browser/server_groups/servers/static/js/variable.js | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) -- Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgadmin-hackers
Re: [pgadmin-hackers] Acceptance Tests against a browser (WIP)
Thanks for your feedback, Dave!
We can put the tests under the regression directory. I think that makes
sense.
I'm not picturing these tests being module specific, but we may want to
enable running it as a separate suite of tests.
Thanks for the callout about the port and title. We'll make sure those are
pulled from config or that the pgAdmin server is spun up by the test with
specific values.
I have a couple ideas about why the test might not have been running for
you. I think the patch we attached didn't spin up its own pgAdmin yet and
it definitely doesn't fill in username/password if your app is running that
way. That's part of the WIP-ness :-P
-Tira
Hi
On Thu, Jan 12, 2017 at 10:41 PM, George Gelashvili
wrote:
> here's the patch we forgot to attach. Also, you can see work on our branch
> at:
> https://github.com/pivotalsoftware/pgadmin4/tree/pivotal/acceptance-tests
>
> On Thu, Jan 12, 2017 at 5:26 PM, George Gelashvili
>
> wrote:
>>
>> Hi there,
>>
>> We are working on browser-automation-based acceptance tests that exercise
>> pgAdmin4 the way a user might.
Nice!
>> The first "connect to database" test works, but at the moment depends on
>> Chrome and chromedriver. We would appreciate feedback on any possible
>> license or code style issues at this point, as well as any thoughts on
>> adding this sort of test to the codebase.
A few thoughts:
- If these tests are to run as part of the regression suite, the
framework for them should live under that directory.
- Are any of the tests likely to be module-specific? If so, they
should really be part of the relevant module as the regression tests
are. If they're more general/less tightly coupled, then I don't see a
problem with them residing where they are.
- Please take care not to include changes to .gitgnore files that
aren't relevant to the rest of us.
- The port number is hard-coded in the test.
- You've hard-coded the string "pgAdmin 4". We've tried to keep that
title as a config option in config.py, so you should pull the string
from there rather than hard-coding it.
- The connect test fails for me (Mac, Python 2.7). I have a suspicion
that this may be because when the test starts chromedriver, OS X
prompts the user about whether a listening port should be opened, but
the tests don't wait (though, I tested with 3 servers configured and
it failed with the same error on the second and third as well, long
after I clicked OK on the prompt):
Traceback (most recent call last):
File "/Users/dpage/git/pgadmin4/web/acceptance/test_connects_to_database.py",
line 32, in runTest
self.assertEqual("pgAdmin 4", self.driver.title)
AssertionError: 'pgAdmin 4' != u'localhost'
- Please keep tests in the pgadmin. namespace (pgadmin.acceptance.??).
- It looks like running a single test won't work yet (because of
TestsGeneratorRegistry.load_generators('pgadmin.%s.tests' %
arguments['pkg']))
Thanks!
--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake
EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
Re: [pgadmin-hackers] First time launch as simple user (improvement needed)
On mardi, 17 janvier 2017 09.23:49 h CET Dave Page wrote:
> Hi
>
> On Mon, Jan 16, 2017 at 5:20 PM, Bruno Friedmann wrote:
> > In packaged world, the user will have a pgAdmin4.desktop file to be able
> > to
> > run it from normal menus.
>
> Yes.
>
> > I've just tested a full fresh install on user system, and if it is run
> > from
> > graphical environnement, nobody will see the console output
> > The configuration database - '/ioda/home/bruno/.pgadmin/pgadmin4.db' does
> > not exist.
> > Entering initial setup mode...
> > NOTE: Configuring authentication for SERVER mode.
> >
> > Enter the email address and password to use for the initial pgAdmin
> > user
> >
> > account:
> Right - but why would you run it in server mode under a graphical
> environment? Server mode is intended for people running in multi-user
> mode behind a webserver - in which case the docs are pretty clear that
> the user should manually run setup.py from the command line.
>
> If you're in graphical mode (what we call desktop mode), then there
> are no prompts.
I guess you didn't catch what I've tried to explain.
I've run runtime/pgAdmin4 which has launched the qt web windows in which
nothing happen (cause the first time configuration was never run)
The text I copy and paste is coming from the output of pgAdmin4 in the console
I've run it. I was not trying to run it in server-mode.
Just emulating what a n00bs will do click on executable.
>
> > The console is "polluated" by the graphical engine, leading to a confused
> > user.
> >
> > What or how can the situation be improved to be able to send pgAdmin4 to
> > "dumb" end-users ?
> >
> > Who can I blame for having a setup for font size (in editor super) and not
> > the rest of the interface ... see attachment on my external hidpi
> > (192dpi) screen. I can't imagine the hassle to live with so small fonts
> > on the internal laptop screen at 288dpi :-)))
>
> I'm not sure why you've got such differences in font size, unless
> you've changed your config (the query tool/SQL box font size is
> specified in em units in File -> Preferences -> SQL Editor -> Options.
> On my retina display, the defaults seem to work nicely. I haven't
> heard of anyone else experiencing a mismatch.
>
> The zoom level might be an issue under some OSs. macOS handles it just
> fine, but I know on some Windows setups the default is unusably small.
> We probably need some code in the runtime to auto-adjust the zoom
> level in such cases.
The editor is right cause I've put 2em as font size, but I was thinking that
all the interface can be adapted to my favorite resolution.
So If the rest should follow the global setup, as you have on osx then there's
at least a problem with qt5/plasma5 here (which is not really a surprise, just
a damn thing more to debug)...
I will do some tests to check, if I found something.
If you have a pointer in code to a place to be hacked I'm your guinea pig :-)
>
> > Last things I found strange is the connection to
> > CLOSE-WAIT 1 0 10.26.8.2:43718 192.0.73.2:443
> > users:(("pgAdmin4",pid=11818,fd=109))
> > the ip point to automattic inc (automattic.com)
> >
> > I don't know what it does, nor the purpose for that, but I'm afraid to
> > have to give an anwser to openSUSE security team if they digg in, and
> > also to suspicious users.
>
> I have no idea what that is, and can't find any reference to either
> the IP or domain in the code. I also cannot reproduce it on my
> machine.
>
> I wonder if it could be Qt Web Engine loading some plugin you have for
> Chrome or something like that?
>
> Can you reproduce it outside of the pgAdmin runtime?
I will check that again several time on fresh vm with no internet access.
Thanks to have confirmed what I've tried to proove that nothing in the code
seems to point to this address.
--
Bruno Friedmann
Ioda-Net Sàrl www.ioda-net.ch
Bareos Partner, openSUSE Member, fsfe fellowship
GPG KEY : D5C9B751C4653227
irc: tigerfoot
--
Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgadmin-hackers
Re: [pgadmin-hackers] First time launch as simple user (improvement needed)
Hi
On Tue, Jan 17, 2017 at 4:50 PM, Bruno Friedmann wrote:
> On mardi, 17 janvier 2017 09.23:49 h CET Dave Page wrote:
>> Hi
>>
>> On Mon, Jan 16, 2017 at 5:20 PM, Bruno Friedmann wrote:
>> > In packaged world, the user will have a pgAdmin4.desktop file to be able
>> > to
>> > run it from normal menus.
>>
>> Yes.
>>
>> > I've just tested a full fresh install on user system, and if it is run
>> > from
>> > graphical environnement, nobody will see the console output
>> > The configuration database - '/ioda/home/bruno/.pgadmin/pgadmin4.db' does
>> > not exist.
>> > Entering initial setup mode...
>> > NOTE: Configuring authentication for SERVER mode.
>> >
>> > Enter the email address and password to use for the initial pgAdmin
>> > user
>> >
>> > account:
>> Right - but why would you run it in server mode under a graphical
>> environment? Server mode is intended for people running in multi-user
>> mode behind a webserver - in which case the docs are pretty clear that
>> the user should manually run setup.py from the command line.
>>
>> If you're in graphical mode (what we call desktop mode), then there
>> are no prompts.
> I guess you didn't catch what I've tried to explain.
> I've run runtime/pgAdmin4 which has launched the qt web windows in which
> nothing happen (cause the first time configuration was never run)
>
> The text I copy and paste is coming from the output of pgAdmin4 in the console
> I've run it. I was not trying to run it in server-mode.
> Just emulating what a n00bs will do click on executable.
Right, but whatever packages you're using should configure the
settings for you correctly (in a Git checkout or source build, it's
assumed you know what you're doing).
The reason the default in the config file in git is SERVER_MODE = True
is for security - setting it to false disables application logins, and
we want it to default to a secure setup rather than risk someone stick
it behind a web server, but not enable server mode by mistake.
>> > The console is "polluated" by the graphical engine, leading to a confused
>> > user.
>> >
>> > What or how can the situation be improved to be able to send pgAdmin4 to
>> > "dumb" end-users ?
>> >
>> > Who can I blame for having a setup for font size (in editor super) and not
>> > the rest of the interface ... see attachment on my external hidpi
>> > (192dpi) screen. I can't imagine the hassle to live with so small fonts
>> > on the internal laptop screen at 288dpi :-)))
>>
>> I'm not sure why you've got such differences in font size, unless
>> you've changed your config (the query tool/SQL box font size is
>> specified in em units in File -> Preferences -> SQL Editor -> Options.
>> On my retina display, the defaults seem to work nicely. I haven't
>> heard of anyone else experiencing a mismatch.
>>
>> The zoom level might be an issue under some OSs. macOS handles it just
>> fine, but I know on some Windows setups the default is unusably small.
>> We probably need some code in the runtime to auto-adjust the zoom
>> level in such cases.
>
> The editor is right cause I've put 2em as font size, but I was thinking that
> all the interface can be adapted to my favorite resolution.
>
> So If the rest should follow the global setup, as you have on osx then there's
> at least a problem with qt5/plasma5 here (which is not really a surprise, just
> a damn thing more to debug)...
>
> I will do some tests to check, if I found something.
> If you have a pointer in code to a place to be hacked I'm your guinea pig :-)
I'm really not sure if it's a bug or just the way some platforms work.
I've heard of similar issues on Windows - but on there (at least what
I've seen running it on VMware) is that you run in high-DPI mode, but
then have to set the application zoom level to be able to see anything
(and even then, some of the older Windows standard dialogues don't
play nicely).
I assume you're on Linux - but I don't know what your window
manager/desktop environment will be doing in terms of zooming in
response to high-DPI displays. Should it handle it automagically as
macOS does, or badly like Windows? Or something in between?
If we know what is supposed to happen on each platform, and can figure
out how to detect the display mode, then we can introduce a
compensating factor into the default zoom level in the runtime (see
line 145 in BrowserWindow.cpp). Or maybe Qt/QtWebEngine can deal with
it for us, and I just haven't figured out how yet).
>> > Last things I found strange is the connection to
>> > CLOSE-WAIT 1 0 10.26.8.2:43718 192.0.73.2:443
>> > users:(("pgAdmin4",pid=11818,fd=109))
>> > the ip point to automattic inc (automattic.com)
>> >
>> > I don't know what it does, nor the purpose for that, but I'm afraid to
>> > have to give an anwser to openSUSE security team if they digg in, and
>> > also to suspicious users.
>>
>> I have no idea what that is, and can't find any reference to either
>> the IP or domain in the code. I also cannot r
