Rick notes that the lookup for this could be expensive. Notification could store the neighborhood id (and project?), for faster lookups.
See allura/lib/macro.py for examples. But we'll want the macro to be in the tool, so we'll need a way to expose that to Allura code. Maybe it doesn't have to be in the tool, actually, if the macro works generically for any notification type.
Diff:
Changes are on allura and sftheme js/2076. To test the macro, put this anywhere in your neighborhood inside double square brackets: neighborhood_feeds tool_name=Wiki max_number=10. If you create pages in the Wiki, they'll show up where you put the macro. Try changing it to tool_name=blog to see blog entries. You should also make sure you don't see notifications from neighborhoods other than the current one.
Everything looks good except that the macro will show Blog posts that are still in draft status, which is probably not what the publisher would want.
We should add an example in our Markdown Help.
And I wonder if we'll need an index. It seems like one on (tool_name, neighborhood_id, pubdate) might be needed. I guess we could manually test a query on a prod slave to see what its performance is like without any indexes.
Couple of things in this code block:
Lines 25 & 27: remove parentheses and put spaces around ==
Line 28: In the case of a post that was saved as a draft and then published later, the description here is going to be a diff (possibly blank if the text did not change). Is that the intent?
Tim, made the updates you suggested. I think I was still in JS land on that syntax!
Looks good, merged to dev.