Re: Require suggestions on feature #5766

[Anil Sahoo]

Hi Dave,

As discussed I moved with auto-update of pgAdmin 4 application in macOs
system locally. It is successful.
So now I have to do some additional user experience improvements.

Listing down some ways we can show the user that a new version is available
and he can download and install it.

*Option 1:*

Show a dialog with the released features and fixes(mentioned in the release
note) with *"Download & Restart"* and *"Cancel"*  buttons. This dialog will
be shown only when the application starts for the first time of the day.

Benefits of showing this dialog will help users to know about the new
features and bugs fixed available in the latest version.

"Download & Restart" button will download the latest version and quit the
app and install and open the latest app. "Cancel" will cancel the
notification.

*Option 2:*

We are currently showing a warning notification of the latest version
available, if the older version is being used by the user, we can add
*"Download
& Restart"* and *"Cancel" * buttons. And those buttons will work the way
they are working in Option 1.

Additionally we will add *"Check for updates"* option in pgAdmin 4 native
menu, if any time a user wants to check for updates manually then can
prefer this and if update is available then the *"Restart to update"*
option will show and if clicked will quit the app and install the latest
version.

Let me know in which way we can proceed.

Thanks
Anil


On Thu, Dec 5, 2024 at 5:11 PM Dave Page  wrote:

> Hi
>
> On Wed, 4 Dec 2024 at 05:19, Anil Sahoo 
> wrote:
>
>> Hi Dave,
>>
>> For Windows, I checked how pgAdmin works for machine-wide installations
>> as admin1 (Administrator), and there is another admin user like admin2
>> (Administrator), and normal users are user1 and user2. When logged in as
>> other mentioned users, I was able to use pgAdmin, but when I tried to
>> upgrade pgAdmin as admin2 from v8.12 to v8.13, I faced the below error:
>>
>> "An error occurred while trying to replace the existing file:
>>
>> DeleteFile failed; code 5.
>>
>> Access is denied."
>>
>>  And if I cancel installation, then run pgAdmin, v8.12 is getting
>> corrupted and giving
>>
>> "The pgAdmin 4 server could not be contacted:
>> C:\Program Files (x86)\pgAdmin 4\python\python.exe: can't open file ‘
>> C:\\ Program Files (x86)\\pgAdmin
>>
>> 4\\web\\pgAdmin4.py: [Errno 2] No such file or directory."
>>
>> For user-level installation, everything is working fine for different
>> users.
>>
>> I have checked some of the desktop applications that are being built with
>> Electron, like VS Code and Postman.
>>
>> *How VS Code works is,*
>>
>> They have 2 different installers, one for user level and another for
>> system level.
>>
>> When I installed the VS Code system installer on admin1, it was working
>> fine, and I was able to check for updates, and for admin2 and user1, it is
>> available, working fine and able to check for updates, not able to update
>> as I am in the latest version. (Note: not found system installers for older
>> versions, but user installers are available)
>>
>> When I installed the VS Code user installer on admin1, it was working
>> fine, and VS Code says when running it as an administrator in a user setup
>> installation, updates will be disabled.
>>
>> When I tried to install the user installer on user1, it was working fine
>> and able to check for updates.
>>
>> *How Postman works is,*
>>
>> When I installed Postman on admin1, it was available for admin2 also. It
>> was working fine, and checking for auto updates was also working fine for
>> both admins. It is not available for normal users when installed for admins.
>>
>> When I installed Postman for user1, it was available only for the current
>> user, and checking for updates was working fine.
>>
>> So please give your suggestions on which approach to follow.
>>
> Postman seems to be a nice model to follow, though it will require us to
> check if the current user has permissions to update the installation. That
> might be tricky to get right.
>
> I would suggest that for the initial version we simply disable auto-update
> for machine wide installations, and think about supporting them for admin
> users in the future when we can properly check that we have the desired
> permissions. We should also consider changes to the installer - e.g.
> perhaps make the per-user installation the default, and (if possible) add a
> note under the machine-wide option to warn the user that auto updates would
> be disabled.
>
> Thanks, Dave.
>
> --
> Dave Page
> pgAdmin: https://www.pgadmin.org
> PostgreSQL: https://www.postgresql.org
> pgEdge: https://www.pgedge.com
>
>

-- 


*Anil Sahoo*

Software Development Engineer II

LinkedIn  || Blog
 || *GitHub
*

enterprisedb.com

Regarding Feature #5305

[Akshay Joshi]

Hi Dave/Hackers,

I have started working on the feature #5305
. Based on my
understanding, the Object Explorer should only display nodes or objects
where the currently logged-in user has at least one permission granted in
the ACL. In other words, the user must have some level of access to each
object displayed.

For example, consider two users: 'postgres' (the default user) and 'test'.
There are objects, such as a table, where the 'test' user does not have any
permissions. This table was created by the 'postgres' user, who has revoked
all permissions for other users. Now, if the 'test' user logs into the
database server, we need to check whether the logged-in user has any
permissions on the object. If not, it should not be displayed in the Object
Explorer.

We will have a preference for whether to apply this check or not. There are
following two solutions that can be implemented:
1) Change the *nodes.sql* to filter out the nodes based on privileges. It's
challenging, as I tried with aclexplode(relacl), unnest(relacl) in the
WHERE clause, and other different attempts to filter out Table nodes, but
seems we will find some solution for sure).
2) Once nodes are fetched then filter out the data at the backend.

Any other solution or suggestion?


Akshay Joshi

Principal Engineer | pgAdmin Hacker

enterprisedb.com

*  Blog*: https://www.enterprisedb.com/akshay-joshi
*  GitHub*: https://github.com/akshay-joshi
*  LinkedIn*: https:// 
www.linkedin.com/in/akshay-joshi-a9317b14

Re: Regarding Feature #5305

[Dave Page]

On Wed, 19 Mar 2025 at 11:12, Akshay Joshi 
wrote:

> Hi Dave/Hackers,
>
> I have started working on the feature #5305
> . Based on my
> understanding, the Object Explorer should only display nodes or objects
> where the currently logged-in user has at least one permission granted in
> the ACL. In other words, the user must have some level of access to each
> object displayed.
>
> For example, consider two users: 'postgres' (the default user) and 'test'.
> There are objects, such as a table, where the 'test' user does not have any
> permissions. This table was created by the 'postgres' user, who has revoked
> all permissions for other users. Now, if the 'test' user logs into the
> database server, we need to check whether the logged-in user has any
> permissions on the object. If not, it should not be displayed in the Object
> Explorer.
>
> We will have a preference for whether to apply this check or not. There
> are following two solutions that can be implemented:
> 1) Change the *nodes.sql* to filter out the nodes based on privileges.
> It's challenging, as I tried with aclexplode(relacl), unnest(relacl) in the
> WHERE clause, and other different attempts to filter out Table nodes, but
> seems we will find some solution for sure).
> 2) Once nodes are fetched then filter out the data at the backend.
>
> Any other solution or suggestion?
>

This seems like it would be a very large amount of work, for very little
gain, and would certainly be inconsistent with how we would expect to
browse files and folders for example. I do not think it is worth the effort.

-- 
Dave Page
pgAdmin: https://www.pgadmin.org
PostgreSQL: https://www.postgresql.org
pgEdge: https://www.pgedge.com

Re: Require suggestions on feature #5766

[Dave Page]

On Wed, 19 Mar 2025 at 10:58, Anil Sahoo 
wrote:

> Hi Dave,
>
> As discussed I moved with auto-update of pgAdmin 4 application in macOs
> system locally. It is successful.
> So now I have to do some additional user experience improvements.
>
> Listing down some ways we can show the user that a new version is
> available and he can download and install it.
>
> *Option 1:*
>
> Show a dialog with the released features and fixes(mentioned in the
> release note) with *"Download & Restart"* and *"Cancel"*  buttons. This
> dialog will be shown only when the application starts for the first time of
> the day.
>
> Benefits of showing this dialog will help users to know about the new
> features and bugs fixed available in the latest version.
>
> "Download & Restart" button will download the latest version and quit the
> app and install and open the latest app. "Cancel" will cancel the
> notification.
>
> *Option 2:*
>
> We are currently showing a warning notification of the latest version
> available, if the older version is being used by the user, we can add 
> *"Download
> & Restart"* and *"Cancel" * buttons. And those buttons will work the way
> they are working in Option 1.
>
> Additionally we will add *"Check for updates"* option in pgAdmin 4 native
> menu, if any time a user wants to check for updates manually then can
> prefer this and if update is available then the *"Restart to update"*
> option will show and if clicked will quit the app and install the latest
> version.
>
> Let me know in which way we can proceed.
>

Option 1 seems good to me; though the current notifier should continue to
work as it does now if a particular distribution channel doesn't support
auto-updates (for example, the EDB PostgreSQL Installer).

-- 
Dave Page
pgAdmin: https://www.pgadmin.org
PostgreSQL: https://www.postgresql.org
pgEdge: https://www.pgedge.com

Re: Regarding Feature #5305

[Dave Page]

On Wed, 19 Mar 2025 at 12:42, Akshay Joshi 
wrote:

>
>
> On Wed, Mar 19, 2025 at 5:11 PM Dave Page  wrote:
>
>>
>>
>> On Wed, 19 Mar 2025 at 11:12, Akshay Joshi 
>> wrote:
>>
>>> Hi Dave/Hackers,
>>>
>>> I have started working on the feature #5305
>>> . Based on my
>>> understanding, the Object Explorer should only display nodes or objects
>>> where the currently logged-in user has at least one permission granted in
>>> the ACL. In other words, the user must have some level of access to each
>>> object displayed.
>>>
>>> For example, consider two users: 'postgres' (the default user) and
>>> 'test'. There are objects, such as a table, where the 'test' user does not
>>> have any permissions. This table was created by the 'postgres' user, who
>>> has revoked all permissions for other users. Now, if the 'test' user logs
>>> into the database server, we need to check whether the logged-in user has
>>> any permissions on the object. If not, it should not be displayed in the
>>> Object Explorer.
>>>
>>> We will have a preference for whether to apply this check or not. There
>>> are following two solutions that can be implemented:
>>> 1) Change the *nodes.sql* to filter out the nodes based on privileges.
>>> It's challenging, as I tried with aclexplode(relacl), unnest(relacl) in the
>>> WHERE clause, and other different attempts to filter out Table nodes, but
>>> seems we will find some solution for sure).
>>> 2) Once nodes are fetched then filter out the data at the backend.
>>>
>>> Any other solution or suggestion?
>>>
>>
>> This seems like it would be a very large amount of work, for very little
>> gain, and would certainly be inconsistent with how we would expect to
>> browse files and folders for example. I do not think it is worth the effort.
>>
>
> OK Thanks, So should we keep this feature request open or close it?
>

I'd close it.

-- 
Dave Page
pgAdmin: https://www.pgadmin.org
PostgreSQL: https://www.postgresql.org
pgEdge: https://www.pgedge.com

Re: Regarding Feature #5305

[Akshay Joshi]

On Wed, Mar 19, 2025 at 5:11 PM Dave Page  wrote:

>
>
> On Wed, 19 Mar 2025 at 11:12, Akshay Joshi 
> wrote:
>
>> Hi Dave/Hackers,
>>
>> I have started working on the feature #5305
>> . Based on my
>> understanding, the Object Explorer should only display nodes or objects
>> where the currently logged-in user has at least one permission granted in
>> the ACL. In other words, the user must have some level of access to each
>> object displayed.
>>
>> For example, consider two users: 'postgres' (the default user) and
>> 'test'. There are objects, such as a table, where the 'test' user does not
>> have any permissions. This table was created by the 'postgres' user, who
>> has revoked all permissions for other users. Now, if the 'test' user logs
>> into the database server, we need to check whether the logged-in user has
>> any permissions on the object. If not, it should not be displayed in the
>> Object Explorer.
>>
>> We will have a preference for whether to apply this check or not. There
>> are following two solutions that can be implemented:
>> 1) Change the *nodes.sql* to filter out the nodes based on privileges.
>> It's challenging, as I tried with aclexplode(relacl), unnest(relacl) in the
>> WHERE clause, and other different attempts to filter out Table nodes, but
>> seems we will find some solution for sure).
>> 2) Once nodes are fetched then filter out the data at the backend.
>>
>> Any other solution or suggestion?
>>
>
> This seems like it would be a very large amount of work, for very little
> gain, and would certainly be inconsistent with how we would expect to
> browse files and folders for example. I do not think it is worth the effort.
>

OK Thanks, So should we keep this feature request open or close it?

>
> --
> Dave Page
> pgAdmin: https://www.pgadmin.org
> PostgreSQL: https://www.postgresql.org
> pgEdge: https://www.pgedge.com
>
>

Re: Require suggestions on feature #5766

[Anil Sahoo]

Okay, I will implement it as per the suggestions.

Thanks

On Wed, Mar 19, 2025 at 5:14 PM Dave Page  wrote:

>
>
> On Wed, 19 Mar 2025 at 10:58, Anil Sahoo 
> wrote:
>
>> Hi Dave,
>>
>> As discussed I moved with auto-update of pgAdmin 4 application in macOs
>> system locally. It is successful.
>> So now I have to do some additional user experience improvements.
>>
>> Listing down some ways we can show the user that a new version is
>> available and he can download and install it.
>>
>> *Option 1:*
>>
>> Show a dialog with the released features and fixes(mentioned in the
>> release note) with *"Download & Restart"* and *"Cancel"*  buttons. This
>> dialog will be shown only when the application starts for the first time of
>> the day.
>>
>> Benefits of showing this dialog will help users to know about the new
>> features and bugs fixed available in the latest version.
>>
>> "Download & Restart" button will download the latest version and quit the
>> app and install and open the latest app. "Cancel" will cancel the
>> notification.
>>
>> *Option 2:*
>>
>> We are currently showing a warning notification of the latest version
>> available, if the older version is being used by the user, we can add 
>> *"Download
>> & Restart"* and *"Cancel" * buttons. And those buttons will work the way
>> they are working in Option 1.
>>
>> Additionally we will add *"Check for updates"* option in pgAdmin 4
>> native menu, if any time a user wants to check for updates manually then
>> can prefer this and if update is available then the *"Restart to update"*
>> option will show and if clicked will quit the app and install the latest
>> version.
>>
>> Let me know in which way we can proceed.
>>
>
> Option 1 seems good to me; though the current notifier should continue to
> work as it does now if a particular distribution channel doesn't support
> auto-updates (for example, the EDB PostgreSQL Installer).
>
> --
> Dave Page
> pgAdmin: https://www.pgadmin.org
> PostgreSQL: https://www.postgresql.org
> pgEdge: https://www.pgedge.com
>
>

-- 


*Anil Sahoo*

Software Development Engineer II

LinkedIn  || Blog
 || *GitHub
*

enterprisedb.com