Add ability to sort rules by weight

I've just fixed the overview to show the weight if its not equal to 0, see #1029608: Machine name should be displayed below the title.

Usually, if you have just have an event + some reacting rules the rules should not interfere, so the order is not important. I know, there are cases where they interfere though, so for that you can set the weight - but it shouldn't be the usual case.

However, if it appears for you that you have multiple rules for which the order is very important, perhaps make use of a rule set component would be an option? It has drag&drop for ordering the rules.

Anyway, since all exportables are in the DB now, we could rely upon entityfieldquery + its sorting capabilities and then pass the returned ids to entity_load(). We would need to find a way to pass that into overviewTable() without breaking the existing API though, maybe by supporting $conditions to be an efq object?

@component:
I'd still see using a component might help you, but that comes with some pro/cons. I'll describe it shortly so you can be sure to choose the right variant.
* Having a single rule-set component, is not modular. Modules cannot add in rules for the component without overwriting the whole component.
* Analogously single rules of a rule-set cannot be enabled/disabled, default-ed or revert-ed on its own.
* But, by removing the modular approach, all rules of the set are given any time, so putting them in a specific order is easy. So you get the drag&drop interface.
* You could do a similar UI as you have know by embedding the rule-set edit form, but yes the code to do so would change totally.

I see that having the modularity makes sense in your case though. I'm not so sure though for the pricing rules, where the rules are put in context to another and have to run in a certain order. Is it feasible for a module to provide a "pricing rule", for which it cannot decide upon the execution order related to other rules really, but still it interferes with other rules?
Anyway, you know your requirements best - I just try to point out the differences for you :)

btw.:
You could set $options['show plugin'] to FALSE, to hide the plugin column.

> * I think we should at least show the weight for everything if we're showing it for anything.
I liked having no weights if there are none, but ok - that way it is more consistent. Done so.

> * I think there should be a way to tell overviewTable() to sort by weight and if not, then it would be helpful to have the weight of the rule in the returned array so I can sort it on my end.

Agreed, having a sort option would be nice. I think we should do it by making use of queries, as that way we could add stuff like pagination later on too. So let's either add $options['sort'] or just support getting an EFQ passed as mentioned above? Anyway - patch welcome ;)

Please add a summary of 'what has been done' related to this issue, and also 'what actions are pending.'

I don't understand why Rules don't always sort by weight in the UI?

Marked #1596562: Ordering rules by drag & drop as a duplicate.

tag

Changing status to reflect high demand. This doesn't have any significance to the priorities of the maintainers, just an observation.

Subscribe

Hello,
I have been taken a look at this issue and weight related things. I am new to rules and forms api, so just wondering and trying to solve this. Sometimes ordering by weight doesn't work as expected. This happened to me with a "Create a new account for an anonymous order" reaction rule, having more than 12 Data Comparsion Conditions. Once I saved them, they were losing their weights. I think that has something to do with the sortChildren function (not really sure):

public function sortChildren($deep = FALSE) {
    // Make sure the array order is kept in case two children have the same
    // weight by ensuring later childrens would have higher weights.
    foreach (array_values($this->children) as $i => $child) {
      $child->weight += $i / 1000; <---------------------------- Float number for this?
    }
    usort($this->children, array('RulesPlugin', 'compare'));

    // Fix up the weights afterwards to be unique integers.
    foreach (array_values($this->children) as $i => $child) {
      $child->weight = $i * 2; <--------------------------------- Check form delta weight value?
    }

    if ($deep) {
      foreach (new ParentIterator($this->getIterator()) as $child) {
        $child->sortChildren(TRUE);
      }
    }
    $this->resetInternalCache();
  }

Float number:
Could be good to have a casting on that? This way we ensure that we are comparing same types (floating numbers) in usort function.

Child weight:
What could happen if the form has $form['elements'][$id]['weight']['#delta'] = 20 by default? It is my case for a commerce rule. If we have more than 10 items in the children array, they will have weigths values over the delta value. Could this has something to do with the sort issue?

I have attached a patch changing this line, trying to force only floating comparsions in usort function.
$child->weight += $i / 1000;
to
$child->weight += (float)($i / 1000);

Not sure if it is the right way, please reviews, comments would be great.
I am also have a question, where could we change the form delta value and set it to the highest $child->weight value? Does it make any sense?

Hi,
I can confirm that weights get wrong values when $child->weight value in sortChildren is bigger than the #delta value weight in RulesContainerPluginUI class:

      $form['elements'][$id]['weight'] = array(
        '#type' => 'weight',
        '#default_value' => $child->weight,
        '#delta' => 20,
      );

Where could we reset #delta value to a proper value acording with max child weight? Should we do it that way?

Hello,
I have ended up with this patch wich solves both, float comparsion (see #12) and sorting issues when children weights are bigger than form #delta value in RulesContainerPluginUI.

If someone could review it and comment it would be great.

Ok,
Sorry about all these messages.
I think I ended up with a solution that make sense. I have added a second loop (foreach) that sets each element #delta weight to the highest weight detected in any element of the previous foreach.
I didn't find any solution for doing this without the second foreach, but I think it is working fine so far.

Adding the patch, forget about the previous ones, this one includes all of them.

aguskii, your patch doesn't seem to work directly toward adding Rules sorting in the overview screen. #1573014: Elements in table are not in correct order after saving rule with more than 10 elements and this issue are both about plugin sorting, but you seem to be solving that one, as you describe:

Sometimes ordering by weight doesn't work as expected. This happened to me with a "Create a new account for an anonymous order" reaction rule, having more than 12 Data Comparsion Conditions. Once I saved them, they were losing their weights.

Hi mitchell,
Thanks for the review.
It is true, this patch will not solve the overview rules srceen, it will do it for the actions, conditions, etc... screen.
I will post this patch there (I didn't see that issue, sorry about that).

duplicate of #372328: Make rules overview sortable from 2009

Until this functionality is incorporated into rules, I am using a view to give me a list of rules that is sortable by Label, Plugin, Active, Weight and grouped by Plugin. It also has exposed filters in a block to add to the page. The Labels are links to edit the the rules.

hi
I am reading this interested thread because i would like to apply the patch.. but i started been confused when i saw this module https://drupal.org/project/rules_filter and want to know if it is not intend to resolve this issue ..

thanks