feat: Enable series name editing with duplicate validation

[H2OKing89]

Brief summary

Enables editing of series names directly from the book/series edit modal with proper duplicate name validation. Previously, the series name field was locked (disabled) when editing existing series, forcing users to use workarounds or third-party tools.

Which issue is fixed?

Addresses user feedback from #4937:

• @iconoclasthero: "I just want to be able to edit the series name... I have yet to fathom why that's a locked field."
• @Vito0912: Noted users need external tools for renaming series

Also resolves the long-standing TODO in SeriesController.js:

// TODO: Currently unused in the client, should check for duplicate name

In-depth Description

Why was it locked?

The series name field was disabled in EditSeriesInputInnerModal.vue when editing existing series, likely to prevent accidental renames that affect multiple books. However, this forced users to:

• Manually delete and recreate series
• Use third-party tools like abstoolbox
• Work around the limitation

What this PR does

Backend (SeriesController.js):

• ✅ Implements duplicate name validation (resolves TODO)
• ✅ Checks if another series with the same name exists in the same library before renaming
• ✅ Updates nameIgnorePrefix when series name changes (important for sorting)
• ✅ Returns descriptive error messages for validation failures

Frontend:

• ✅ Removes :disabled lock on series name input
• ✅ Adds originalSeriesName tracking to detect changes
• ✅ Validates duplicate names before submitting
• ✅ Calls PATCH /api/series/:id immediately when renaming existing series
• ✅ Shows backend error messages in toast notifications
• ✅ Prevents accidental overwrites with proper checks

How it works

1. User edits series → Opens edit modal, name field is now editable
2. User changes name → Frontend tracks the change
3. Frontend validation → Checks if new name conflicts with existing series in library
4. Submit → Sends PATCH request to backend
5. Backend validation → Double-checks for duplicates, updates nameIgnorePrefix
6. Success → Series renamed, all books in series automatically see the new name (linked by UUID, not name)
7. Socket event → series_updated notifies all clients

Why this is safe

• Books link to series by UUID, not by name - renaming doesn't break relationships
• Duplicate validation on both frontend and backend prevents name collisions
• Same library only - allows same series names across different libraries
• Immediate PATCH - changes are persisted to database immediately, not deferred

How have you tested this?

Manual Testing

1. ✅ Rename existing series - Changed "Harry Potter" to "Harry Potter Series"

   • All books updated correctly
   • Series list shows new name
   • Sorting still works (nameIgnorePrefix updated)

2. ✅ Duplicate name validation - Tried renaming to an existing series name

   • Frontend: Shows toast error "A series with that name already exists in this library"
   • Backend: Returns 400 with descriptive message
   • Original name preserved

3. ✅ Empty name validation - Tried submitting empty name

   • Shows "Must enter a series" error
   • Form doesn't submit

4. ✅ New series creation - Still works as before

   • Can type new series name
   • If matches existing series, uses that series ID

5. ✅ Cross-library series - Same series name in different libraries

   • Works correctly, only checks within same library

Automated Testing

• ✅ All 315 existing tests pass
• ✅ No regressions introduced

Edge Cases Tested

• Renaming to same name (no-op, no error)
• Renaming with different capitalization (allowed)
• Multiple books in renamed series (all updated)
• Socket updates propagate to other clients

Screenshots

Screenshots (click to expand)

Before (series name disabled):

After (series name editable):

Validation in action:
When attempting to rename to existing series name:

• Toast appears: "A series with that name already exists in this library"
• Form doesn't submit
• Original name preserved

[Vito0912]

As I said in my other comment, I do not think it is a good idea to make this changeable so easily. In my opinion, this should be added to the metadata utils, where other such actions are already possible, although I am just a contributor, so whatever. But that is not why I am commenting.

It is cool that you seem to have found AI that works for you. But you help nobody if you open AI-generated PRs. ABS already had a flood of AI PRs and you contributed 5 new ones.

It adds review work for things you did not write and likely do not fully understand, though I do not want to assume this about you. Even your answers are copied straight from an AI. The following was, in no world, written by a human: #4960 (comment)
Just wanted to state this.

AI is a nice assistance. Submitting a AI only PR and even answering trough AI is no assistance.

[H2OKing89]

Yeah the endpoint already existed. It just wasn’t being used because the UI prevented renames and the server-side handler still had a TODO about duplicate-name checking.

This PR adds the missing duplicate-name guard (and updates nameIgnorePrefix) and then wires the UI to call the existing PATCH when the name changes. just enabling the existing single-series edit path.

[iconoclasthero]

I just think it should be up to the individual library maintainers to be able to manually edit series names without having to delete the series and re-type it into a new name (since I can't even copy the old one) just to be able to make any corrections—which I still can't edit later. To me, it feels like unnecessarily restrictive UI. I made this point two years ago and, while I run into it infrequently because I do not read that many books that are elements of a series, it is frustrating when I do run into it.

As an e.g., if I want to change this title in my library to "MurderBot Diaries," without deleting the series and retyping it in a new one and reentering the element number, I'm SOL.

I'm not sure what "I do not think it is a good idea to make this changeable so easily"—which is the same as saying "I think this should be hard/harder to do"—is supposed to be protecting...me from balling up my own library?* I don't know what "other metadata utils" is referring to, but the field is right there, I don't want to have to go poking around anywhere else just to change e.g., "Murderbot" to "MurderBot."

For the reason why it is the case: Probably because this would affect many books in a book dialogue. Similar how you cannot rename a genre or tag, but you can via the setting. But dunno

If this speculation is correct, I am ok with it having the same back-end effect as the present method of correcting series names, i.e., I delete the series and then recreate a new one on exactly one book record leaving all other records to be manually edited as well. I don't use batch editing, but it would certainly be an obvious place to edit the series name.

This is a point of appreciable "frustration" for me every single time I run into it and would love to see it change...and as such I should probably run this response through ChatGPT to tone it down for me! (I.e., I need the opposite of K&P's Luther, the anger translator.)

*FWIW - If this is just designed to protect users from themselves, then a longer-range solution could be tiered settings levels e.g., in Kodi.

[Vito0912]

Just for the record. I do not mean to delete and add the series again. This would remove the set position.

But like for generes and tags, you have the option to rename them at a global place in the UI, also without removing and adding and is done in two clicks.
This is probably done because the same tags and genres can be used across libraries.
So after that fact maybe making the textfield editable is really the better option, because series are not across libraries. But my comment has no effect on mergability anyway.

I still think it would be cleaner in the settings, because then it would be all at one place and the benefit, you would be able to delete a series, but again, not will change if this PR is merged, just some comment

(And because that PR here is 100% AI generated anyway I also didn't do much thinking here, because that was not the main point I was making)