search

ElvishArtisan / rivendell

A full-featured radio automation system targeted for use in professional broadcast and media environments
197 stars 63 forks source link

Version 4.x no longer allows cut sorting within carts or multiple deletes - Bug? #940

Open KeepEmGoing opened 5 months ago

KeepEmGoing commented 5 months ago

I have installed several instances of RD 4.1.3 on CentOS 7 by the script install method and in every case, the cut sort feature by description, cut number, dates, etc that used to be in available in the audio carts in previous versions no longer works. This is especially tedious when you have hundreds of cuts in one cart and the program director wants to find certain episodes to make valid on certain dates.

Also, the ability to delete multiple cuts at a time no longer works. The Delete button grays out when more than one cut is selected. This worked on previous version.

ermina commented 4 months ago

just tested this on 4.1.3 (compiled from source on Debian) with a restore of our 2.5.1 production database, and i have the same problem: clicking on column headers does not trigger any kind of sorting.

dklann commented 3 months ago

Just weighing in here. "Column sortability" broke in all of the QT dialog boxes during the change from Rivendell 3 to Rivendell 4 (QT4 to QT5). The reason is that "column sorting" was a built-in feature of columns (tables?) in QT versions prior to 5, and must now be done by the application. Fred "restored" the ability to sort by columns in many "list views", but the cut list view is one where sorting is hard coded.

I have made one or two pull requests restoring column sorting (e.g. the dropbox list), but I am stymied at the prospect of implementing it for the Cuts list in RDLibrary. I'm stymied because sorting currently happens by either weight or order, depending on the value of the "Schedule Cuts" dropdown.

My question is, should the default action of sorting by weight or order be overridden by the column on which a user clicks? I'd love some help untangling the code in lib/rdcutlistmodel.cpp (where the sort code lives).

ElvishArtisan commented 3 months ago

My question is, should the default action of sorting by weight or order be overridden by the column on which a user clicks? I'd love some help untangling the code in lib/rdcutlistmodel.cpp (where the sort code lives).

I would argue that the order should be hard-coded to use the 'Ord' column when scheduling 'By Specified Order' is selected, but otherwise selectable by the usual method of clicking the title blocks. The rationale is the same as for why Log items cannot be sorted: the order of the items is an inherent aspect of the overall data organization (though a 'Find Item' search capability would be useful in both cases).

dklann commented 3 months ago

Fred, I understand and concur with your argument for ordering Log items (in, e.g., RDLogEdit). But I think this is different. In my experience, it's quite common for folks to want to sort the Cut list by play count, ingest date, or last-played date in order to visualize the "current state" or "history" of a Cart's Cuts.

It seems to me that when one opens a Cart, the initial Cut ordering by weight or specified order is appropriate. Giving users the ability to display the Cuts in any order without modifying weight or actual order in the database would be super helpful.

ElvishArtisan commented 3 months ago

That makes sense. However, when displaying some "alternative" item order in that mode, we need to make it obvious by some visual means that the order of the items is not the order in which they will be play out. How to do that? Change color somewhere? Display a big text label?

dklann commented 3 months ago

However, when displaying some "alternative" item order in that mode, we need to make it obvious by some visual means that the order of the items is not the order in which they will be play out.

Is that really necessary Fred? I mean, yes, it would be helpful for the user, but I'm looking at a multi-cut Cart in RDLibrary 3.6.8: I can sort by any of the columns and there's no visual indication that the Cuts are "out of order" with respect to the "By Weight" or "By Specified Order" selection.

How difficult would it be to change the color of the Cut list text in just the "Ord" column when the Cuts are being displayed "out of order"?

KeepEmGoing commented 3 months ago

Our need is to sort the cuts by title or play date or ingest date so that we can reassign a play date in the future as needed. Often when new recordings are imported into the same cart that already has hundreds, it’s hard to find. We have certain authors (part of title) that play on specific days, and if there are no new recordings, we will select those by them that played a long time ago and give them a new date. We rarely order the cuts within a cart by weight or numbered order, just by when we want them to play which can be done if you can find them as you scroll through hundreds.

We also used to be able to select multiple cuts in a row to be deleted but now you can only delete one at a time.

Tom

From: Fred Gleason @.> Sent: Thursday, April 4, 2024 10:04 AM To: ElvishArtisan/rivendell @.> Cc: Tom VanGorkom @.>; Author @.> Subject: Re: [ElvishArtisan/rivendell] Version 4.x no longer allows cut sorting within carts or multiple deletes - Bug? (Issue #940)

That makes sense. However, when displaying some "alternative" item order in that mode, we need to make it obvious by some visual means that the order of the items is not the order in which they will be play out. How to do that? Change color somewhere? Display a big text label?

— Reply to this email directly, view it on GitHubhttps://github.com/ElvishArtisan/rivendell/issues/940#issuecomment-2037463889, or unsubscribehttps://github.com/notifications/unsubscribe-auth/BFO6TXDVL7EQOAZWSDA2CALY3VTXZAVCNFSM6AAAAABCXBWWUWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMZXGQ3DGOBYHE. You are receiving this because you authored the thread.Message ID: @.**@.>>