Skip to content

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

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

Provide More Safeguards for Library Deletion #1399

Closed
4 tasks done
Nitrousoxide opened this issue Jan 17, 2024 · 6 comments
Closed
4 tasks done

Provide More Safeguards for Library Deletion #1399

Nitrousoxide opened this issue Jan 17, 2024 · 6 comments
Labels
consider Not sure yet if this makes sense or not

Comments

@Nitrousoxide
Copy link

Describe your suggested feature

Library Delete is a HIGHLY destructive action, and it is currently only a couple of options away from a frequently used "empty trash" option. It is extremely easy for a user who isn't paying close attention to what they are doing to mistake the two, or to mindlessly attempt to use that option to delete some selected series in the manga list (I certainly did! But luckily I keep good backups!)

This option obviously has a popup to confirm, but it's a similar one to the "empty trash" popup confirmation and extremely easy to mistake it for the other.

Given the fact that this completely blows out all data for that library I really feel like additional protections need to be in place. Even something as simple as requiring the user to type out the name of the library and making the confirm button bright red would serve to distinguish it from "empty trash" and from the "delete series" which are also both accessible from the series list.

Ideally I think it would be best to move this option entirely out of the normal workflow's view and relegate it to somewhere in the server options since it's not the sort of setting you should be using in day-to-day use.

image image image

Other details

No response

Acknowledgements

  • I have searched the existing issues and this is a new ticket, NOT a duplicate or related to another open issue.
  • I have written a short but informative title.
  • I have updated the app to the latest version.
  • I will fill out all of the requested information in this form.
@gotson
Copy link
Owner

gotson commented Jan 18, 2024

"users don't read".

@gotson gotson added consider Not sure yet if this makes sense or not and removed triage labels Jan 18, 2024
@gotson gotson changed the title Feature Request - Provide More Safeguards for Library Deletion Provide More Safeguards for Library Deletion Jan 18, 2024
@AnnoyedDev
Copy link

A good Idea would be to do the same thing as github do for example wich mean we have to WRITE the full name of the Library name, with case sensitivy and paste disabled. I think it could be a very good idea for user that "don't read" :/

@gotson
Copy link
Owner

gotson commented Jan 22, 2024

yeah or users can start reading. if they wipe their library because they don't read big warnings in red and they tick confirmation boxes without reading, that will probably generate enough harm so that they realize they should read stuff :D

@Nitrousoxide
Copy link
Author

That seems like an... unproductive... approach to UI design.
"The users will hurt themselves until they share our vision"

@gotson
Copy link
Owner

gotson commented Jan 23, 2024

That seems like an... unproductive... approach to UI design. "The users will hurt themselves until they share our vision"

if it gets implemented, there's still a good chance people will still complain that it's not enough, that's all i'm saying. I haven't closed that issue, but there's a lot of other more important stuff to do.

@billsargent
Copy link

That seems like an... unproductive... approach to UI design. "The users will hurt themselves until they share our vision"

For this very reason, I keep a backup of my stuff. I mean I use this from a tablet... one slip up and yeah. Gone.

Repository owner locked and limited conversation to collaborators Jun 4, 2024
@gotson gotson converted this issue into discussion #1545 Jun 4, 2024

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

Labels
consider Not sure yet if this makes sense or not
Projects
None yet
Development

No branches or pull requests

4 participants