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

https://bitbucket.org/metabrainz/musicbrainz-server/pull-request/1429/add-an-admin-interface-for/diff

This adds the admin interface and makes the arrow buttons move the relationships properly.

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.