Active
Project:
Rules Bonus Pack
Version:
7.x-1.x-dev
Component:
Rules Bonus: Miscellaneous
Priority:
Normal
Category:
Feature request
Assigned:
Unassigned
Issue tags:
Reporter:
Created:
29 Jul 2011 at 07:02 UTC
Updated:
28 Oct 2011 at 05:41 UTC
Jump to comment: Most recent file
Comments
Comment #1
mh86 commentedI've just tested your patch and it does work for me. Concerning your code, there are still some trailing whitespaces (you can see them e.g. with the Dreditor or with a right git config).
Furthermore, there are quite a few functions that use the same code for loading and executing a view, looks like this would need some re-factoring (maybe small helper function), but actually that's a different topic.
Comment #2
itangalo commentedGood feature request – and very happy to see a patch as well!
Unfortunately I won't have time to look closer at it for maybe two weeks or so, but it is now on my list.
(PS: I incidentally did a pretty similar action as an example of a Rules plugin, over at http://nodeone.se/node/895 – might be worth comparing.)
Comment #3
nodestroy commentedthanks, I fixed the coding style issues.
regarding the rules_examples module: I compared the two functions, and as I can see, it does not use arguments and displays. Would you like too see a helper function for better code style or just the simple functions with duplicate code for readability?
Comment #4
itangalo commented@nodestroy: What I would like to see, eventually, is a data type for Rules that describes views – including possibilities to set arguments and select displays. (This would also allow having the number of results as a piece of information for the data type, utilizing Entity tokens rather than providing a new parameter to Rules.) This is pretty far off in the future, though, so I won't wait for that to happen before adding the functionality to Rules Bonus Pack.
I *would* like to see arrays and displays, though, since that would drastically increase the cases where the function can be used. I prefer better code style and helper functions over duplicated code (but it isn't really important at this stage).
You get extra bonus if you can have view selection and display selection separated – instead of the pretty ugly combination I used in Rules Examples. :-)
Comment #5
mlyno commentedI tested the condition
Event: Before saving content
Condition1: Content is of type
Condition2: Check number of results from a view
I wanted to pass Date field value from the saved node as argument to the view.
It did not worked with replacement pattern token for the date field on the saved node because of probable limitation in token module. Date field token is ALWAYS in "medium" format, does not matter in which format the date field is. Therefore you need to set the system provided medium format to an ISO format which can be handled by views.
If you know to which issue in the token module is this limitation linked, please post it here.
Comment #6
itangalo commentedHm, I now realize that the new functionality with a Views data type (comitted yesterday) kind of makes this action obsolete. If you have a view object in your rule, then the result count is available as an object property. (See also #4.)
However, for the new data type to really be useful, there should be a way to load a view manually – not just react when it is going to be viewed. (You might, for example, want to check a view on user login, to see if that user has made more than X nodes in the last 10 days.)
This means that this issue changes nature completely – and is now about creating a UI for adding a view to Rules manually. Sorry. :-/