I hate to have to file this issue, but it's always bugged me, and now with people asking #1279768: Document where the Rules UI is, I think the time has come to start throwing wrenches. :)
How'd we get here?.. (this is just off the top of my head, so it's not meant to be exhaustively researched): The D7 information architects made a category for each module that required configuration/customization, and these were put under /config/[category]. A workflow category came into view late and with some problems unlike every other category. They couldn't fit anything in there by default and even the things they suggested be put there didn't seem like they naturally fit together, unlike their other groupings. One main problem was that it would be empty by default, so they decided to add another "feature" to core that would make this one sub-menu disabled by default unless a contrib module used it. ...Now, whether it's people finding this "/admin/config/workflow/rules" location difficult to find, difficult to navigate to, or difficult to wrap their head around it in the first place (see next paragraph), or it being hidden even while rules ui is enabled because of a menu cache problem (see issue in first paragraph)... we have to take another look at this.
Why is it wrong from an IA perspective? Every D6 module that was in admin/build/ went to admin/structure except for rules. Rules is not a "change a default setting" / "enter my api key" / "select a timezone" type configurable module. You build out your site/app with it. That's why it was in admin/build in D6. Having a subcategory that, in the majority of cases, only contains one item is a major IA fail. In any case, you end up with a module whose resources are stuck 5-6 children deep, so unlike admin/structure/views/add, we have admin/config/workflow/rules/reaction/add.
I'm not saying this change is without some growing pains, because it will require a change notification that may have difficulties of its own. I think the tradeoff, however, is worth it and could be the start of a very beneficial IA/paths discussion for Rules. A simple comment of whether or not you'd be comfortable with the switch during D7 would be very helpful. Please keep in mind, that waiting for this change in D8 is not a sensible option (as the future of Rules' contrib/core status has not yet been determined), and this is a discussion that never took place and could have wider implications on D8's programmatic interface naming conventions as well. Is there really any sense forgoing this discussion and holding off major changes that could be widely beneficial?? (rhetorical, expected answer is no)
What I am saying is that this problem exists. UX is a huge challenge for Rules, and this issue should be seriously evaluated the same way #1344598: Rename Rules Admin to Rules Admin UI needs to be. And we have to start working with this issue, as well as a number of others, either toward a release that sanctifies UX and/or that pushes Rules closer to more general, easier, wider adoption.
Comments
Comment #1
mitchell commentedBetter fitting status.
Comment #2
dasjoi believe this question has bugged several users before but i guess fago will just say that rules are configuration and should therefore remain where they are :)
for example image styles live in configuration as well and by moving such things to structure you would deny that they are actually configuration to the site.
Comment #3
mitchell commented>> rules are configuration and should therefore remain where they are
I would agree that they are configuration, however Rules' configurations are very different. If you can show a module whose configurations are like Rules, then I think you would be closer toward proving that Rules belongs there. Since configurations in structure are much more similar, I think that is a good reason why the UI shouldn't stay where it is.
>> for example image styles live in configuration as well and by moving such things to structure you would deny that they are actually configuration to the site.
The whole point is well stated as, "[I] believe this question has bugged several users before."
Comment #4
mitchell commentedMaybe we can come back to this later.
Another idea I had is to have another module monkey patch Rules for this fix.
Comment #5
guypaddock commentedMoving this to postponed since mitchell's last note was "maybe we can come back to this later" which implies future discussion, not that it's out of the realm of possibilities.
I came to this issue because our team constantly looks for Rules under Structure. Unlike Image Styles, Rules are not "set it and forget it" configuration settings. On many sites, especially Commerce sites, the same rules change often as the business grows, just like content types, views, or anything else that makes up how the site works (the site's "Structure").
Rules also get exported as first-class structure items just like content types, views, features, etc. I really don't see a strong argument for them just to be configuration settings.
Comment #6
guypaddock commentedFriendly bump on this.
Comment #7
akhil_saxena commentedHey @GuyPaddock,
Does this need to be move forward?
Comment #8
akhil_saxena commentedHello Drupal Community members,
It's being a long time this issue needs TBD. Checking just in case we have any update on this, so that we can move ahead with this.
Thanks!!
nirvana_u
Comment #9
guypaddock commentedI would personally love to see it moved under SB.
Comment #10
tr commentedComment #11
tr commentedAt this point in the D7 lifecycle, we have accumulated about 8 years of experience, examples, documentation, and issues (in the Rules queue as well as in the queues of all other modules that use Rules) - all of that points to the existing location for the UI under /admin/config/workflow/rules.
To change it now would be disruptive, regardless of the merits.
The Rules UI is the last major hurdle to releasing a D8 version of Rules, so now would be a good time to participate if you want to have a better UI in D8. But please do that in a separate issue.