News:

Loving SimpleDesk? Help us spread the word!

Main Menu

Topic solved
This topic is marked as solved and as such require no attention unless you want to bump this issue.

Re-order custom fields

Started by Spoogs, May 31, 2011, 09:53:34 PM

Previous topic - Next topic

Spoogs

Quote from: Spoogs on May 26, 2011, 09:51:58 AM
I read about this somewhere in SMF, possibly custom profile fields about re-ordering them. Is this something that would be possible in SD without too much trouble?

Easy example
Using SD as a tracker, you use version numbers as a category (just so you can filter when needed) you have:
1.0, 1.1,1.2, 2.0... but as you go along you realize there needs to be a 1.01 but you'd like to place it after 1.0 so essentially you have to reorder the values... what happens now when you try to reorder is that your existing tickets pick up the new values.
Quote from: Gruffen on May 26, 2011, 10:11:27 AM
Hmm.

Random idea just struck me about how it *might* actually be possible without crazy amounts of work. Need to let it percolate through brain a bit longer, not quite caffeinated enough yet.
Quote from: Gruffen on May 26, 2011, 10:14:43 AM
I'm not convinced it'll be added before 2.0 final, but if it's done right it shouldn't even require changing anything outside the admin area.
Quote from: Gruffen on May 26, 2011, 01:30:53 PM
What happens with inactive items? I'm inclined to display them, but not editably, and still have the UI let you reorder them.
Quote from: Spoogs on May 26, 2011, 01:46:51 PM
That works... honestly hadnt thought about that part :P, just hoping the logic that applies to them still being visible on tickets until edited would be preserved.
Quote from: Gruffen on May 26, 2011, 01:50:30 PM
Ah, see, that's the thing.

The values are still present, merely hidden away. There is an argument to be made, can go either way, about whether the fields get preserved but bumped to the end of the list, or whether they are still accessible for the purposes of ordering.

Fact is, they will be present either way, it's just what's done with them.
Quote from: Spoogs on May 26, 2011, 01:52:14 PM
Bumping them to the bottom of the list sounds like the way to go
Quote from: Gruffen on May 26, 2011, 02:22:45 PM
Works for me since I can keep it essentially silent in running because those values never have to be exposed to the user.

If I squeeze it in it'll be a last minute thing, because I should buckle down with the three other outstanding items first :P

Gruffen

To be clear, this is in reference to select/radio/multi-select, reordering the specific values (as reordering fields as a whole is supported already)

In case I don't get round to it, here's a few thoughts on how this could be done, conceptually it's actually simple to solve: the serialized options array that contains everything is ksort'd when rebuilding it for resaving (before any previous known values are preserved and pushed into the inactive key at the end of the array). Important: it's 1-indexed. (It's VERY important. 0 is used to deal with explicitly default-value cases.)

So, the options array will normally look vaguely like:
1 => first option
3 => third option
4 => fourth option
inactive => array(2)

(Should be self explanatory :P)

All you actually need to do to reorder it is simply juggle the order of keys about when saving it since the values will be preserved anyway in that case which is needed for displaying said fields, but for displaying the options, it will just iterate through the array and exclude the inactive key - though for the sake of neatness (and possibly bug avoidance) make sure the inactive key is the last one.

That said, multi-select will require more work because existing values will retain their original ordering (and likely retain their ordering anyway) because IIRC it's ksort'd on save, it should be sorted by order of the options keys on both display and resaving.

SleePy

Looking at this, I'm not sure how Gruffen wanted to keep it in the admin only changes.  Changing the order of the values forces us to have to reorder their index.  This causes a problem because we have to track the old ID and new IDs and then run a query against the values used in tickets in another table to make sure they still point to the same proper IDs.

Only 2 ways I see of doing this are:
1. Add a "order" array to the stored values that tracks the order of the ids, then have the GUI bring this out in the proper order
2. Do as I mentioned above, keep track of the old IDs and new IDs (keeping track of their order changes) and then update the values used.


The first is fairly easy to do, but requires updating all interfaces where we can edit the custom fields on the user side (not many places it seems).
The second requires no user side changes but does require more working with the database to fix everything.  Best idea I have is to use a transaction and temporarily increase the values by the max value number (so if we have 101 values, it would bump all ids by 101 making the min 102 and max 202), then resort old id to new id. This would have to keep track of all the unused as well still.
Jeremy D — Spare-Developer

tfs

I recall when Arantor left and we released before this was done... and I wondered if we didn't just lose a fleeting idea. :)
A good tree cannot bring forth evil fruit, neither can an evil tree bring forth good fruit.

SleePy

Yea, I wish I could see what he was thinking we could do.  My notes may have been a unforeseen issue though.  I think going with 1 makes it easier as we then just show them via the order we tack onto the existing array.
Jeremy D — Spare-Developer