#2076 Macro to show news/blog entries from whole neighborhood

[Dave Brondsema]

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.

[Dave Brondsema]

• Description has changed:

Diff:

--- old 
+++ new 
@@ -1,3 +1,3 @@
 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.
+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.

• size: --> 4

[Jenny Steele]

• status: open --> in-progress
• assigned_to: Jenny Steele

[Jenny Steele]

• status: in-progress --> code-review
• assigned_to: Jenny Steele --> Tim Van Steenburgh

[Jenny Steele]

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.

[Tim Van Steenburgh]

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.

[Tim Van Steenburgh]

• status: code-review --> in-progress
• assigned_to: Tim Van Steenburgh --> Jenny Steele

[Dave Brondsema]

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.

[Jenny Steele]

• status: in-progress --> code-review
• assigned_to: Jenny Steele --> Tim Van Steenburgh

[Tim Van Steenburgh]

Couple of things in this code block:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31

#!/usr/bin/python def commit(self): self.subscribe() super(BlogPost, self).commit() if self.version > 1: v1 = self.get_version(self.version-1) v2 = self la = [ line + '\n' for line in v1.text.splitlines() ] lb = [ line + '\n' for line in v2.text.splitlines() ] diff = ''.join(patience.unified_diff( la, lb, 'v%d' % v1.version, 'v%d' % v2.version)) description = diff if v1.title != v2.title: subject = '%s renamed post %s to %s' % ( c.user.username, v2.title, v1.title) else: subject = '%s modified post %s' % ( c.user.username, self.title) else: description = self.text subject = '%s created post %s' % ( c.user.username, self.title) if(self.state=='published'): M.Feed.post(self, self.title, self.text) if(self.state=='published'): M.Notification.post(artifact=self, topic='metadata', text=description, subject=subject)

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?

• status: code-review --> in-progress
• assigned_to: Tim Van Steenburgh --> Jenny Steele

[Jenny Steele]

Tim, made the updates you suggested. I think I was still in JS land on that syntax!

[Jenny Steele]

• status: in-progress --> code-review
• assigned_to: Jenny Steele --> Tim Van Steenburgh

[Tim Van Steenburgh]

Looks good, merged to dev.

• status: code-review --> closed
• assigned_to: Tim Van Steenburgh --> Jenny Steele