Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Multi-User Database Platforms: Disable functionality in PDFKeeper the user does not have access to perform. #55

Closed
Sohail2949000 opened this issue Jan 7, 2025 · 7 comments
Assignees
Milestone

Comments

@Sohail2949000
Copy link

I have connected a user with read-only permissions to PDFKeeper. When this user attempts to upload a document, an error message appears stating that the user "test" does not have write permissions. However, after dismissing the error message, it keeps reappearing every few seconds, disrupting the user's experience.

image

@rffrasca
Copy link
Owner

rffrasca commented Jan 8, 2025

PDFKeeper is retrying to upload the staged PDF and additional properties XML file with the same name. You will need to move the PDF and XML out of C:\Users\User_Name\AppData\Roaming\Robert F. Frasca\PDFKeeper\UploadStaging.

@rffrasca rffrasca self-assigned this Jan 8, 2025
@rffrasca
Copy link
Owner

rffrasca commented Jan 15, 2025

@Sohail2949000 - By design, PDFKeeper will retry to upload on failure. This is a good thing when there is a database timeout or some other error. But in this case, there is no way for the PDF to upload since the user does not have permissions. I could parse the error but, this is not a reliable method since the language could be different in some environments and the message originates from the database. I think the best I can do here is check for PDFs in the UploadStaging folder after the upload cycle completes and display a message to the user with an option to open the UploadStaging folder. The user will then need to move the PDF and XML out of the folder. What do you think?

@Sohail2949000
Copy link
Author

@rffrasca Yes Sir the message option is good and also we can completely hide or disable the upload button based on login. If we we disable buttons like upload or other related to user who have write permissions I think it will be solved as user with read permission can not access the buttons

@rffrasca
Copy link
Owner

@Sohail2949000 - I like your suggestion disabling controls in the user interface. I'm thinking that this can be enhanced further by querying and storing the user's permissions during login and using those values to disable menu and toolbar items for operations the user doesn't have access to perform.

In addition, if the user doesn't have select access, the user should see an error message stating that they do not have read access to the database. Also, if the user doesn't have insert access, any PDF copied into the Upload folder will be moved to UploadRejected.

@rffrasca rffrasca changed the title Error with Persistent Write Permission Notification in PDFKeeper Multi-User Database Platforms: Disable functionality in PDFKeeper the user does not have access to perform. Jan 16, 2025
@Sohail2949000
Copy link
Author

@rffrasca yes this could enhance user experience a lot.

If possible we can also add creating users form PDFkeeper instead going to database and create user there. so admin can create users directly form PDFKeeper and assign the permission

@rffrasca
Copy link
Owner

@Sohail2949000 - This ask will require you to submit a feature request:
Add creating users form PDFKeeper instead going to database and create user there. So, admin can create users directly from PDFKeeper and assign the permissions.

@rffrasca rffrasca added this to the 11.1.0 milestone Jan 18, 2025
@Sohail2949000
Copy link
Author

@rffrasca okay sir I will create a feature request for this 🌟

@rffrasca rffrasca moved this to Backlog in PDFKeeper 11.2.0 Jan 18, 2025
@rffrasca rffrasca modified the milestones: 11.1.0, 11.2.0 Jan 19, 2025
@rffrasca rffrasca moved this to Backlog in PDFKeeper 11.3.0 Jan 19, 2025
@rffrasca rffrasca modified the milestones: 11.3.0, 11.2.0 Jan 23, 2025
@rffrasca rffrasca moved this to Backlog in PDFKeeper 11.2.0 Jan 23, 2025
@rffrasca rffrasca modified the milestones: 11.2.0, 11.3.0 Jan 26, 2025
@rffrasca rffrasca moved this to Backlog in PDFKeeper 11.3.0 Jan 26, 2025
@rffrasca rffrasca modified the milestones: 11.3.0, 11.2.0 Feb 9, 2025
@rffrasca rffrasca moved this to Backlog in PDFKeeper 11.2.0 Feb 9, 2025
@rffrasca rffrasca moved this from Backlog to Ready in PDFKeeper 11.2.0 Feb 22, 2025
@rffrasca rffrasca moved this from Ready to In progress in PDFKeeper 11.2.0 Feb 22, 2025
rffrasca added a commit that referenced this issue Mar 15, 2025
… does not have access to perform will be disabled. #55

Signed-off-by: Robert F. Frasca <rffrasca@gmail.com>
@rffrasca rffrasca moved this from In progress to In review in PDFKeeper 11.2.0 Mar 15, 2025
@rffrasca rffrasca moved this from In review to Done in PDFKeeper 11.2.0 Mar 30, 2025
@rffrasca rffrasca closed this as completed by moving to Done in PDFKeeper 11.2.0 Mar 30, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
No open projects
Status: Done
Development

No branches or pull requests

2 participants