Difference with Rules link module

Play with the other module, you'll work it out.

Here we go..

• The two modules have the same goal: allow site builders to easily add and/or use click-able UI elements to trigger rules.
• They have different approaches for building APIs and backend functionality that support this, but the similarities abound..

The underlying issue here is that this functionality is a widely demanded feature, and thus it's a capability that is important for the full maturation of Rules. So, we need a reliable and well-documented solution, and I'm hoping we can get back on track for that. Perhaps we can even put #1655452: Rules Link in Rules Core, in which case I would recommend we take the best parts of each (described below); or maybe they won't need to merge, but at the very least, let's figure out how they might build on one another moving forward.
---

User story:
My first hope/expectation for this project was that it might solve #1280000: Replace triggering rule-sets with events, and possibly even replace Rules Link project with a great simplification. It made me question, "does Rules Link need to create links for me; can another form element be used?"

I tried a few methods for configuring this module, all of which didn't work. I set up a few path / click reactions for nodes: on node/view node/edit clicks, then I tried adding menu items so the paths (node/%/echo) might exist as well, then I also tried setting reactions on a Rules Link click event (echo/% & echo/*), but that didn't work either.

I think that the other reported instances of it working are like the example which uses a path defined in commerce or one of its plugins. I think the paths need to be defined more concretely than what i was trying. Either way, I'd really need more documentation to set this up, and if module defined paths are required, then we would need another API on top that adds embeddable link entities. But isn't that what Rules Link mostly does?

Regardless of the trouble with setting it up, my main concern was that the page/click event didn't seem to pass entity variables, so AFAICT, this isn't currently possible, and that's a big limitation.

On the front end side of things, both still have the limitation of no obvious way to embed links. As I describe above, figuring out how to make an #1513604: Execute link didn't even seem possible. Rules Link at least has views integration, that you can use like this #1338542-4: Link location: ability to specify where it shows, eg blocks, page area etc.
---

Pros and cons of each:
Rules Link Event

• P Exposes an event
• P Adds a link within the /admin/settings/workflow/rules area
• P Simplicity.
• C Needs to rebuild menus. Couldn't this be based on a more dynamic solution, like a router?
• C Missing an admin form
• C Has a critical a major bug, #1327396: Undefined Offset #1422222: Function name conflict/bad .install file respectively, and no docs

Rules Link

• P Creates a form element, managed as a field and available as views fields.
• P Has a working admin form
• P Has working examples: screencasts, Rules Workflow (sandbox)
• P Provides javascript and confirmation
• P Reacts on data rather and has attached entity parameter variables
• C Reacts
• C Docs aren't complete
• ? Adds conditions for display (wondering if it's overcomplicating the task or bordering Rules Forms)

This module aims to fill the gap created by #1283734: Make link-types pluggable. This is its only purpose.

There is a third option hidden inside Rules Bonus Pack that allows Page Manager (ctools) variants to trigger a Rules Event.

I currently prefer Rules Link module as it provides tokenized links that prevent against CSRF security vulnerabilities.

@darrenmothersele, could you point me to more documentation on this method? I think I understand how you are doing what you briefly explained, but I want to make sure. It would also be nice to have a specific example.

Thanks

I used the Page manager variant triggering Rules Event method in this old blog post: http://darrenmothersele.com/blog/2011/12/13/jquery-ui-widgets-drag-and-d... (mentioned bottom of page after "Add Attendee" heading).

But - I would not recommend this, as I mentioned in an update to that blog post, firing off Rules Events from a GET request is not a good idea, unless you use a tokenized URL.

According to the HTTP spec, a GET request should not really causes any state change on the server.

More importantly, this can lead to CSRF.

Related issue: https://drupal.org/node/2218413

I'd suggest that related issue is relevant to this module too. I.e. make sure the dangers of CSRF are highlighted in the documentation as people may not be aware of the security implications when creating (un-tokenized) GET requests using this module.

I've added a notice on the project page to beware of CSRF. If you think there is anything else I should add, please let me know. However, if there is please open a separate issue as this probably isn't the issue to continue discussion on this subject.

Thanks!