Minor unstable migration bugs and documentation changes

[retmas-gh]

Hi 👋
Since I've seen you merged the migration documentation from old build to the sea-orm version I assumed the migration itself should be in a workable state - so I decided to give it a try.
While the migration itself completed succesfuly (I didn't test it deeply so to say yet), the migration prompts / documentation are kind of rough :) so I will try to point out few things that you will hopefuly find helpful:

1. The prompt asks for backfill.sql script; the documentation has no mention of this at all, but I did find it in crates/migrations, so I copied it to a docker accessible location.
   Now, I don't know how you want to provide this sql script in relase, but it would be nice if the migration command would first attempt to look for the file in current directory (for binary release people), then in /config (for lazy people using docker that will just toss it to a directory they should already have mounted), and if not found, only ask then for it.
   After the succesful execution to not leave unneded artifacts laying around a prompt to remove the file would be nice.
2. There is no mention at all about the need to edit the backfill.sql file to change the path to the old database; it should either (preferably) ask in the command line about the location (you would need to check for writeability of the file beforehand I guess) or it should be mentioned that such an edit is needed beforehand (and that it needs to be from a docker's PoV if used in such a situation).
3. The third prompt asks for backup database; it is unclear what that means:

• is it the database of the backup that I made before running the migration? Did not make sense for me, but might not occur to everybody at first (and the backup should be untouched because it's the whole purpose of it :) )
• is it the database of the old instance? Did not make sense either because I already specified the location in the backfill.sql file (which, by the way, I only opened because I was curious what it does, but not everybody is)
• so it must be the location of the new, empty instance; hurray - it worked :)
  With this I want to pass to you that the information that the backup name should be changed to something else to lessen the confusion; an example would be: Enter the path to the new, empty database created by Stump to migrate to: (and, if you follow with # 2, Enter the path to the old database filled with your data to migrate from: would be for that case).

[aaronleopold]

Thank you for taking the time to give it a go and provide feedback! I really appreciate it.

1. The prompt asks for backfill.sql script; the documentation has no mention of this at all

Good catch!

I don't know how you want to provide this sql script in relase, but it would be nice if the migration command would first attempt to look for the file in current directory (for binary release people), then in /config (for lazy people using docker that will just toss it to a directory they should already have mounted), and if not found, only ask then for it.

I understand how convenient this is, however I would be basically building out a more complex feature-set into a tool meant to be a one-off usage for folks using Stump prior to this upcoming release. In this instance I'll most likely keep it as-is since I unfortunately have limited time I'd rather put towards bug fixes etc, but would love to see contributions if people feel strongly towards having that.

There is no mention at all about the need to edit the backfill.sql file to change the path to the old database;

You should not make any edits to the script when you are using the built-in migration tool, Stump will look for the placeholder value and replace it with whatever you input into the tool. In fact, editing the path would cause the tool to not function.

I'll also clarify the need to edit the script only when not using the tool I added for convenience, but hopefully the comments, warnings, and placeholder values used throughout the script itself is enough to tell folks who are inclined to use the script directly what to do, e.g.:

-- 1. open the newly migrated database in your preferred SQLite client, I use TablePlus but it doesn't matter. You may also use the CLI e.g. sqlite3 stump.db < resolve-missing-data.sql
--    you must use absolute paths to the databases, replace with your path
ATTACH DATABASE '/replace/with/full/path/to/stump-before-migration.db' as 'backup';

The third prompt asks for backup database; it is unclear what that means:

I'll clarify some of the language used in the prompts, but to answer some of your other questions in this section:

is it [backup database] the database of the backup that I made before running the migration? Did not make sense for me, but might not occur to everybody at first (and the backup should be untouched because it's the whole purpose of it :) )

Yes, and really that is the same to me as:

is it the database of the old instance?

It is just asking for the database will all your existing data inside it. It does not write or delete any data from that database, only the one you've told it is the new database. However if you're worried about potential data loss you can use a backup of the backup to the nth degree, so long as it has the data you want to be migrated.

---

I've pushed a few small changes already to breaking/docs if you'd like to take a look. I'll adjust the prompts in the tool later today, as well

[retmas-gh]

api token button throwing TypeError: can't access property "writeText", navigator.clipboard is undefined

This sounds like a browser compatibility or security issue. What browser are you using and are you accessing via HTTPS?

Yeah, for the test copy of stump I always use it without a proxy, just stright to the application docker container, so no https.
I've just tested it with a proxy with a cert and it does indeed work there.

toast windows (which are on by default I believe)

What are toast windows? Like the overlay that shows job progress?

Yeah sorry, I thought it was a widely used terminology

Screenshot of what I'm talking about

first scan after adding a library finishes prematurely

This one is interesting and I think warrants its own issue. If you're able to totally clear server logs and then try to reproduce it and share the logs after, that would be super helpful

I have tested it again to be double sure before encumbering you with a false positive and I've noticed one of the series, even after a rescan, does not show in the list; the series had a series.json file in the directory, which, after deleting, removed the problem of both the series not appearing and the scan not picking all the books.
While my file contained metadata, I tested the occurance of this problem with an empty file and containing valid json of {} and the problem persisted with those too.
Might it be you did not touch this part yet? I'm not really using this file so I just deleted it.

Another small thing I've noticed: it's not possible to toggle item visibility from a navigation menu in the webapp (so you can't hide book clubs entry etc.)

PS. I've derailed the discussion enough I've changed its title

[aaronleopold]

Yeah sorry, I thought it was a widely used terminology
Screenshot of what I'm talking about

No worries at all, there is a preference you can toggle labeled Job overlay that you should be able to use to hide that. I think at some point I wanted to add an x button inside that allows you to close it just for a session but never got around to it.

I've noticed one of the series, even after a rescan, does not show in the list; the series had a series.json file in the directory, which, after deleting, removed the problem... I tested the occurance of this problem with an empty file and containing valid json of {} and the problem persisted with those too

This is perfect, thank you! That gives me a pretty narrow set of things to check so I appreciate it. I'll try to bundle a fix for that along with some of the other things you mentioned, ideally before I promote it to experimental as a last round of fixes

[retmas-gh]

Yeah sorry, I thought it was a widely used terminology
Screenshot of what I'm talking about

No worries at all, there is a preference you can toggle labeled Job overlay that you should be able to use to hide that. I think at some point I wanted to add an x button inside that allows you to close it just for a session but never got around to it.

Yes, I'm aware - that's why I brought this to your attention because, as mentioned, it's on by default, so it has an impact on all the (new) people. Instead of a close button the window should be a little higher, in my opinion, so it would not cover the buttons but, like with almost all the things I mentioned here, it's just a minor inconvinence.

[aaronleopold]

I gotcha, I agree and I just pushed a commit to do just that where applicable 🙂

[retmas-gh]

Tested the change with few different screen sizes and works beautifly, thank you :)
As per the initial discussion I've created an issue formated as a checklist here so I will close this discussion now.