Show role names instead of IDs on render

Makes sense. For that we have to fix the data type's UI class's render() method to take the options list into account.

there's a solution, patch attached.

1. new definition in rules core data info -> modules/rules_core.rules.inc
list with 'ui class' => 'RulesDataUIListUserRoles',

2. new interface for user roles -> ui.data.inc
RulesDataUIListUserRoles extends RulesDataUIListText which use the names of roles

3. finally, the type of the "roles" parameter changed in user.rules.inc
from 'type' => 'list<integer>' to 'type' => 'list<userroles>'

It's not valid to introduce a new type name for integers, we have to stay with list. However, the role names should be already available in the 'options list' of the property - as seen in the form generation code. As described in #2, we can just use that information in render() to print the label instead of the key.

ok. you know best the "rules"
other solution (or maybe just an ideea to solve this issue)
changed the element settings in buildcontent from ui/ui.core.inc

        if (is_array($this->element->settings[$name]) && $parameter['options list']) {
          $this->element->settings[$name] = array_intersect_key(call_user_func($parameter['options list']), $this->element->settings[$name]);
        }

oh, I see render() has insufficient parameters. However, I don't think it is a good idea to pass in the label as $value, as it's just not the value (and the data type might be different). Let's better do a small API change and add pass the parameters $name, $info, $element to render() just as for form().

Stumbled over this issue too.

Strangely it offers me 2 Options: [account:user-role-names] - [account:user-role-ids]

But both give me just the ID's which are quiet useless if you want to use them in emails etc.

Great Module by the way!

Simon

I've just committed a fix for that. Please re-open if it doesn't work for you with the next dev snapshot.

Updated component.