Header Willing to help? Home

OuzoBlog - Functional design

From Flouzo

Jump to: navigation, search

eltdelnob

Contents

[edit] Introduction

This is a user-centric blog, meant to let users have different levels of participation: submitting links, blog items or RSS feeds. Moderators monitors submitions and selected RSS feeds, publishing content appropriately.

[edit] Business & Technical Requirements

[edit] Dependencies

[edit] Internationalisation Requirements

[edit] Security & User Input Requirements

  • All input from the user or form elements should be tested before being used.
  • Special input types should be checked for validity (URL, email...)
  • Once logged in, the user is kept logged in using a long-lasting cookie (1 year), and the application shouldn't care about IP change for a given user.
  • When a user enters text content in a form, the following rules should apply:
    • Tags other than the following list should be stripped: <a> <em> <strong> <small> <sup> <sub> <cite> <blockquote> <code> <ul> <ol> <li> <dl> <dt> <dd> <h2> <h3> <h4> <img> <br> <br /> <p> <div> <span> <b> <i>
    • The only accepted attributes for the previous tags are: href= src= alt= height= width=
    • Closing (eg. </a>) or stand-alone (eg. <br />) tags are also accepted
    • Web page addresses and e-mail addresses turn into links automatically
    • Lines and paragraphs break automatically
  • When an entry coming from user input is recorded, IP address of the sender should be recorded with the entry
  • Entry posted by users should all be linked to the originating account id. If the user is anonymous, create a temporary hidden account based on the email address (see technical specifications below).

[edit] Performance Requirements

  • Extensive use of cache should be made everytime it is possible and doesn't impede user experience.
  • Pages served to anonymous users should all be cached and not impede user experience.

[edit] Web standards requirements

[edit] Deliverables

  • S1) Complete and precise implementation of the description of the bid request. All the business & technical requirements must be fulfilled.
  • S2) Complete and fully-functional working web site with no absolute URL in it (except the base url, filled once for all in the configuration file), shipped as a Ruby on Rails directory structure.
  • S3) RDoc-generated documentation, using precise and complete comments from the code describing each element - http://en.wikibooks.org/wiki/Ruby_Programming/RubyDoc
  • S4) Detailled HOWTO describing, step by step, the necessary steps to install, test the code and generate the documention on a GNU/Linux system, along with a general description of the architecture
  • S5) Buyer will receive exclusive and complete copyrights to all work purchased. Third party software may be included as long as they are published under a license compatible with the GNU GPL.
  • W1) All code must be tested (100% coverage in rcov http://eigenclass.org/hiki.rb?rcov )
  • W2) All javascript functions must be tested using http://www.jsunit.net/. All code must be encapsulated in functions. All javascript functions must be defined in .js files.

[edit] System Specifications

  • Mockups corresponding to the development to be made can be found as a separate attached archive called 'mockup_site.zip'
  • The developped application should behave accordingly to the messages displayed to the user on the mockups; behavior of the mockups and text describing the functionnality inside the mockup are authoritative.
  • Below is a list of additional rules which adds up to the mockups themselves.

[edit] Additional requirements

[edit] Login / rights

  • Users can login using <a href="http://openid.net/">OpenID</a> or a standard account created on the website
  • Accounts created on the website are actually hosted on a local OpenID server
  • Features inside the 'Moderation' menu are only available to Moderators and Adminstrators, with the exception of the Users list item and related feature, which is only available to Administrators (only them can see the list of users and edit preferences for all users). These features should be protected from direct linking.
  • In preference editing, only administrators can edit the account type.

[edit] Content submission

  • Everyone can submit links, blog posts and source feeds.
  • The name and email address fields are only asked to anonymous users.
  • If he was anonymous when he submitted the content and an account already exists with the same email address, he is directly asked for its login/password or OpenID URL before the content is actually posted.
  • If he was anonymous when he submitted the content and no account already exists with the same email address, he receives an email proposing him to create an account. It he creates an account, all the content he created with the same email will be automatically attributed to his account.
  • Once he has submitted something, a poster receives an email from the website confirming the article post and informing him it is pending moderation.
  • Moderators and administrators receive an email telling them there is new content to moderate, along with title, author and excerpt.

[edit] Moderation

  • The 'Display read links | Display unread links | Display both read & unread links' and alike links on the top of moderation lists allows a moderator to choose whether he displays read items, unread items or both. A similar behavior is expected for blog items, external news and source feeds.
  • As a moderator or administrator scrolls down through the list of external news or links to moderate, items are marked as read. It should work exactly as in http://reader.google.com/ : items are highlighted as the user scrolls down, and marked as read at the same time.
  • 'Publish' immediately publishes an item: he becomes the latest item in its corresponding category, and its date&time is changed to publication time.
  • 'Reject' and 'Remove' are the same thing: the item is marked as read, and disappears from the list of unmoderated items.
  • When a blog item is rejected or published, an email is sent to the author, informing him of the decision. If the blog item is published, a link to the published item is included in the mail.
  • Items still in the moderation queue should be protected from direct linking - even with the right link, only a logged moderator or administrator should be able to read it. This is only a reminder, as the same rule applies to all content and features inside the moderation menu.
  • When a source feed is removed, its existing items should remain on the website. The only effect is to prevent retrieval of new items for this feed from the moment it is removed.
  • When a category is removed, all corresponding items should be attributed to an hidden category, "Unattributed".
  • A popup should ask the mod/admin to confirm the action when he asks to remove a source feed or a category.

[edit] Comments

  • No comment on an item is made directly through the application. Instead, a FUDForum is used; details of how it actually works are beyond the scope of this document, but from the application perspective it works the following way:
    • When an item is published, the application sends an email to an hard-coded (config file) email address (one address for each type and each language: blog, external news, link, feed).
    • The sent email should be a plain text version of the content, with the title as the subject.
    • Cron watches an hard-coded (config file) forum RSS feed address (one URL for each type and each language: blog, external news, link, feed), adds a link toward the forum thread when it appears, and keeps the number of comments up to date every cron (see below).
  • For testing purposes, you can make the application send emails to 2@ml2forum.flouzo.net . The post should appear on http://forum.flouzo.net/index.php?t=thread&frm_id=5 with a RSS feed at http://forum.flouzo.net/rdf.php?mode=t&frm=5&n=20&l=1

[edit] Cron

  • Periodical work, such as checking the news feeds for new RSS 1.0/2.0 and Atom items, or checking the FUDForum RSS feed, should be performed by a rails controller, activated through an HTTP request. For example, retrieval of http://www.troisiemeplace.org/admin/cron should launch the execution of such tasks.
  • Read and unpublished news items (not user-entered links) should only be kept for two weeks - they should be purged from the database afterwards.
Retrieved from "http://flouzo.net/wiki/en/OuzoBlog_-_Functional_design"

Actions

User

Toolbox