(This is on the beta server but won't be usable until the link types are actually marked as orderable.)

Yeah, that is possible, though I think the only good way to do that would be to write a postgres extension that can work with ORDER BY to do a natural sort...a while ago I investigated a bunch of PL/SQL and pure-SQL solutions that didn't work out. That might be a good idea. It could be slightly annoying to have to have different sorting code for manual/automatic series, though. Maybe we should get rid of the automatic/manual distinction and just have everything sorted by text attributes. The up/down arrows would have to go in that case.

Couldn't automatically-ordered series just use the text attributes to determine the order and have all the link orders as 0?

Of course for automatically-ordered series, the text attributes are what determine the link orders, so if two items have the same text attribute then the link orders should be either the same, or different but in an undefined order.

I've started fixing the issues nikki mentioned above (already have a working admin interface).

Regarding the arrow buttons being confusing/unintuitive, I wonder if it'd be a good idea at this point to stop allowing duplicate link orders greater than 0. It's part of the reason the interface is confusing, and I'm not sure of any place that it's used in a valid way right now...where what's "valid" depends on what meaning "link order" should even have outside of the actual code, which is kinda pertinent since it's exposed in the webservice (as "ordering-key"). It certainly seems valid to want to say "these two items in a series have the same position, therefore an undefined sort order relative to each other," but maybe that sort of information is what belongs encoded in the number/text attributes.

The orders aren't missing from the edits, the edits themselves are missing. Maybe that's the same thing, but maybe not.

Yes, it was intended; see this comment on the original pull request.

I agree the interface isn't very intuitive; I described my experience with it some time ago (with the following comment). I guess the only reason people don't complain about it is that series mostly use automatic ordering.

Regarding the edits not storing link orders, see this comment and its reply. This also reveals that the "0" display is actually my fault.

Testing the code currently on bitmap's sandbox, which I assume works the same as what's currently on the main server:

This still needs adding to the interface for editing relationship types and should be included on the relationship type documentation pages.

The orders aren't saved when I submit the edits (which makes testing rather difficult...).

I find the interface rather confusing and unintuitive to use when trying to edit things where the order hasn't yet been set, because my instinct is to try to move the first relationship to the top of the list, but that's not possible because everything is "0" and therefore already at the "top" of the list, so you have to move everything, including the first thing, down instead.

Speaking of "0", it also feels rather strange to me to use that in the interface to mean unsorted (behind the scenes sure). It also makes it very time consuming to use - if you have 10 relationships to order, you have to click the down arrows 55 times. If we want to allow both sorted and unsorted, I think we need to reconsider how it should behave.

It allows the same positions to be appear multiple times. I'm not sure if that was intended.

The plan is to wait a bit until (most of) the bugs from the schema change release are sorted out.

Wonderful, does this mean we can then make the request for the specific relation types through the Style list or there's still some coding that has to be finished first?

The code for this went in today with MBS-2714, but it's not activated for any relationship type yet.

The interface would certainly take some thought, but I hope that won't drag down the principle of adding ordering to these ARs.

(BTW I can see that my comment above doesn't make sense. What I was trying to say was that sets of tunes can be made work-work ARs if you use an arrangement work. Obviously there is still currently no ordering of the set regardless of whether you are dealing with work-work or recording-work ARs.)

The ones I mentioned before (medley and compilation) are recording-recording, recording-work and work-work, so yes, the solution would have to be for relationship types in general.

As far as the interface goes for this, I think the only logical solution is to make this depend on MBS-6234.

Additional to Nikki's comment, these relationships are not only between works but also between recordings and works. If you're dealing with ITM or other similar, most instrumental tracks are a "set of tunes" and we should be able to order these ARs. (This can be done by creating an arrangement work, but the usual guidance is that we shouldn't do this unless there is >1 known recording of the arrangement.)

I believe that we would need a schema change to do this, so I'm adding the 'schema change' component.

The "part of" relationship isn't the only one that should be able to specify the order, the medley and compilation ones could do with it too.

Sorry nikki, I was troubled because it's the first time I see we close an earlier ticket of a duplicate.
If you say it's the same thing then I paste my more straightforward explanation from MBS-3062 as I don't really get this one.

From MBS-3062(MBS-3574)↘
We can't set the work parts order in a parent work in the work-work "part of" relationship (related to STYLE-69).
Example : 組曲「九尾」〜玉藻前〜照魔鏡〜殺生石 (not 殺生石〜照魔鏡〜玉藻前 as it is now reversed, based on title characters)

But the explanation here is totally confusing (for non english like me at least) and it seems the proposed solution, based on sortname isn't the same at all. I wouldn't want a sortname nor anything based on a hackish work name, I would want a cardinality on AR.

closing the other issue instead since this one already has a number of votes and watchers, whereas the other has none

See MBS-3574 for some comments about ordering relationships in general

I believe that that best way to do this is to add a field with an integer ("1", "2", "3") or string ("1.1", "1.2", "1.10") which gives the sorting order. Long term we'll go crazy trying to make a text string be both a human-readable description of a work and a machine readable sort order key.