View Issue Details

IDProjectCategoryView StatusLast Update
0003384AJAX/JSBug Report - Interfacepublic2019-10-13 14:24
Reporterjosi Assigned To 
Status newResolutionopen 
Summary0003384: Massadd Episodes: Broken or misleading reordering
DescriptionWhen moving an episode up or down, the episode number isn't moved together with the remaining fields.
Steps To Reproduce1. Go to
2. Click on the "Move up" button (arrow) in the last row (currently T1)
Additional InformationI would expect the episode number "T1" to always stay in the same row as "Ep 01 PV (17 sec)" (I have a feeling it used to work that way). Actual result in the attached screenshot ("Ep 01 PV (17 sec)" is now in the row "C11").

I wasn't brave enough to actually save the changes to see what happens (my real use case was adding a new special episode before an existing one, see

Tested in FF 69 and Chrome 77.



2019-10-12 10:14



2019-10-13 02:06

administrator   ~0004385

why would it? you are "moving" episodes, by changing their episode number. moving it up or and retaining the number would literally do nothing.


2019-10-13 02:39

reporter   ~0004386

Last edited: 2019-10-13 02:40

Well yeah, but I don't want that trailer to become a C episode either, which current interface suggests.

If I were to give a more realistic example: I want to add a new S episode before all existing S episodes. So I add it (a new row S3 titled "Episode S3" appears at the end) and move it up - it's now in the row S1, which is nice, but "Episode 12 Ending", which was S2 and is supposed to become S3, is now in the row C1 (and the PV is in the row S3). I'm personally afraid to save changes in this state, as I can't be sure whether the type of all episodes is correctly retained.

If this is the intended behavior and I can safely use the feature, I don't mind making this issue a lower priority suggestion instead of a bug and removing "broken" from the summary, but I still think the interface is misleading. Also I really think the interface used to behave differently right after implementing 0003128 as I used it a few times, but I might be wrong.


2019-10-13 14:24

administrator   ~0004387

ok i guess operating blockwise and only blockwise might have it's merits. wasn't somethign i considered when rewriting the code.

Issue History

Date Modified Username Field Change
2019-10-12 10:14 josi New Issue
2019-10-12 10:14 josi Tag Attached: massadd
2019-10-12 10:14 josi File Added: Screenshot_2019-10-12_12-10-42.png
2019-10-13 02:06 DerIdiot Note Added: 0004385
2019-10-13 02:39 josi File Added: Screenshot_2019-10-13_04-20-00.png
2019-10-13 02:39 josi Note Added: 0004386
2019-10-13 02:40 josi Note Edited: 0004386
2019-10-13 14:24 DerIdiot Note Added: 0004387