Artweb-design adva cms → Sprint #1

Comments and changes to this ticket

• 

  Sven Fuchs July 8th, 2008 @ 10:55 PM

  • Milestone set to “First alpha”
• 

  Sven Fuchs July 15th, 2008 @ 02:07 AM

  • Milestone changed from “First alpha” to “Release 0.1.0”
• 

  Sven Fuchs September 22nd, 2008 @ 11:54 AM

  • State changed from “new” to “open”
  • Tag set to “email, notification”
• 

  Clemens Kofler September 22nd, 2008 @ 10:20 PM

  • Assigned user changed from “Sven Fuchs” to “Clemens Kofler”
  • Tag changed from “email, notification” to “email, feature, notification”
• 

  Clemens Kofler September 25th, 2008 @ 05:43 PM

  As discussed in IRC, I'll try to outline my ideas for the adva_activity engine.

  Currently, adva_activity only logs (i.e. stores in the database) a couple of different events (e.g. create and destroy) for articles, comments and wikipages. However, in the near future this should and definitely will change. Therefore, it is important to think about the best way to handle activities.

  One thing that the CMS definitely needs is some kind of notifications for users. Think about users publishing articles - moderators and admins should then be told that there are articles awaiting moderation. This notification can be presented in various different ways (e.g. e-mail, RSS, live on the page, etc.) but the underlying functionality stays the same.

  The idea is to use some kind of bottom-up event bubbling to notify all users who are watching either an object itself or one of their parent objects.

  Imagine the following site structure: "advaBEST" (= the site's name) has a section named "adva_cms" which in turn has a section named "adva_cms Wiki" (which is, of course, a wiki). Now let's assume the following two activities on the page:

  • A user adds a new wiki page to the adva_cms Wiki.
  • A user modifies an existing wiki page of the adva_cms Wiki.

  In the first scenario, we'd have to notify the following users (in this order):

  • Users watching the wiki section "adva_cms Wiki"
  • Users watching the section "adva_cms"
  • Users watching the site "advaBEST"

  Administrators of a given site and superusers should be subscribed to the whole site (advaBEST) by default but can then, of course, unsubscribe.

  In the second scenario, we'd also have to inform subscribers of the respective wiki page.

  The implementation can be done with a relatively simple subscription model that pretty much only includes the user_id, object_id and object_type (which can be Section, Wikipage, etc.). Later in the game, we could also think about providing some option similar to Google Groups (i.e. a daily digest instead of a notification for every single activity one is subscribed to). Then, when an activity is triggered, we walk the object tree recursively (via commentable_id, section_id, parent_id, etc.) until we hit the first section with parent_id = NULL at which point we fetch the site object. This way, everybody in the object hierarchy gets notified and we have a flexible solution that concrete presentation layers (like RSS, e-mail, etc.).

  Let me know if anything's unclear or if you have suggestions to improve this model.

• 

  Sven Fuchs September 28th, 2008 @ 10:28 PM

  • Milestone changed from “Release 0.1.0” to “Sprint #1”
• 

  Clemens Kofler September 29th, 2008 @ 05:15 PM

  • State changed from “open” to “resolved”

  Small version (only notify site admins and superusers) is done. The rest will be backed later in #74.