wiki:MM1

Specifications for Major Milestone 1

See also: MM2,  All active tickets for MM1

1. Backend

  1. (later)ACL and rights management system should be implemented (see SecuritySystem). (#194, #195)
  2. Articles and comments should be versioned within the database. (#148)
  3. Each version of article/comment should have a separate set of children that are valid for this version (see CommentValidity). (#148, #219)
  4. Although the journals shall have a common user base, we should be able to store a set of journals a user wants to be member of. When a user registers through a journal, he becomes the member of just that journal. He can simply add other journals later. (#223, #224)
  5. For all articles created and comments made, it should be saved which journal were they originally created for. (#122)

2. Webmore

0 (Noneh) | 4 (48.0h)

  1. Webmore should be stable, we can't get it wrong. It is our big hit. ( Webmore tickets)
  2. Webmore commenting (viewing and comment posting) should be operational on the frontpage. (#103, #133)
  3. Comments should be nested. (#132)
  4. It should be possible to edit/delete a comment only by its user and people/groups who has right to do it. (#136)
  5. For unallowed people, no edit/delete icons should appear. (#136)

3. Comments management

0 (Noneh) | 4 (36.0h)

  1. In that comment editor box, the user can switch back and forth from plain text to fckeditor. (#137, #141)
  2. The same mechanism (back and forth between plain text and xhtml) should be present when editing comments. (#142)
  3. Important: check the <webmore .../> tags upon commit:
    • for a brand new comment, drop all those tags; (#229)
    • when comment editing, drop every <webmore.../> tag that didn't exist before editing, and include all the missing ones at the end of the text (see EditingWebmoredText). (#230)
  4. For comments that are not valid (their parent has a version that they are not valid for) there should be an icon at the top-right: “accept parent's edit” (see CommentValidity). (#221)
  5. Invalid comments should sign it with red border color in the expanded state (see CommentValidity). (#220)
  6. Invalid comments should have some icon in the top right toolbar in expanded mode with which the reader can see the last version of the parent for which the comment was valid. (#242)
  7. Comment posting should be initiable by users currently not logged in. When the click commit, they should get an interface to register/log in, and finally to get their comments made. (#131)

4. Internationalization

1 (0.0h) | 1 (0.0h)

The system should contain some internationalization framework. The template fragments should be fillable with translateable content, and we should be able to create translations for hungarian. (#354)

5. Account page, preferences, notification

1 (3.0h) | 19 (72.0h)

  1. Header of account page should show on the right which journal did the user come from. Link to this journal should also appear in navigation bar in form "Journal >> Account >> Box" (#117)
  1. Account page should have a footer bar with links to every journal the user is member of. (#123)
  1. Below the footer line, it should embed the help page into itself. (#124)
  1. (dropped) Before release, the possibility of experimenting with the account page appearing in popups would be nice. (#127)
  1. Account page should display two draggable and expandable boxes: Preferences box and Comments box (see below).

  1. On the left of expanded box there should be graphical button that takes user back to account page. (#119)

a) Preferences box

  1. There should be two visually separated groups of settings in this box: personal data, and notification settings. (#116)
  1. User should be presented with Save/Discard/Cancel? dialog if she leaves preferences box with unsaved settings by clicking any of links on account page. (#118)
  1. Data fields in the preferences box:
    1. Personal settings: Nickname, First name, Last name, Email, OpenID URL (read only, with a question mark to tooltip style popup help).
    2. Notification:
        [ ] Get notified when my comments gets commented
            [ ] Get notified if any descendant of my comments get commented
      
      Second checkbox should be disabled if first one is unchecked. #114, #115
  1. Below the email, the system should sign if it is verified or not. (#75, #227)
  1. In the notification part: sign if notifications are not going to be sent because of unconfirmed email.
  1. Show button that will resend confirmation mail in case it was lost. (#228)
  1. Allow the user to select his favourite color (the color in which his comment bubbles will appear). (#282)

b) Comments management box

  1. Collapsed state: it should contain a table with rows corresponding to the last 10 comments made by the user. Columns: first few words of comment (not more than 15 chars), date, number of responses.

    Clicking on the rows should expand the comment management button in the same state as if the user first expanded it then clicked on the same row
    .
  1. Expanded state: a similar table, but
    1. There is a column with article title displayed as link to this article.
    2. All comments are shown, not just the last 10.
    3. Clicking on a row shows the actual expanded comment in an iframe. It appears in webmore bubble with a few surrounding sentences from parent article/comment. Comment descendants' bubbles are also displayed, but inactive. (#153, #156, #170)
    4. It should be possible to edit or delete expanded comment. (#154, #160)

6. Initial data, domains, journal frontpages

1 (12.0h) | 4 (36.0h)

  1. A newly created blog, named XY should be available at XY.ourdomain, where ourdomain is anything we have, the blog creator should decide. (right now, alapos.hu, mukk.hu, thiblo.com). Should the blog creator not select anything, the default is thiblo.com. (#225)
  2. It should be possible to set an external domain name for the blog. If it is set, then every internal link pointing to that blog should use the external domain. (#222)
  3. Domains alapos.hu and thiblo.com should be external domains for (alapos|thiblo).thiblo.com. (#226)
  4. In released form, the url thiblo.com/blog/something should not be available at all, blogs should be available strictly just by subdomains. The system may have some "debug" switch, which may switches on the /blog/ links. (#225)
  5. We'd like to have 4 blogs in the initial data which are going to be operational upon first release: alapos.hu, mukk.hu, thiblo.com. (#231)

6/a. Alapos frontpage

0 (Noneh) | 2 (19.0h)

  1. Ability to fill the orange box should be implemented. (#213)
  2. The top right corner should contain the "sign in", "register", "logout", "account page", "what's this" menus, but only the applicable ones. (#234)

6/b. Frontpages for mukk.hu and thiblo.com

2 (24.0h) | 4 (56.0h)

  1. Administrators should be able to edit their layout with some command-line interface. (#231)
  2. Pages on .hu domain should be by default in hungarian and thiblo.com in english. (#232, #233, #248)

7. Article page

1 (8.0h) | 2 (11.0h)

  1. There should be a header that shows the title of the journal we came from, with a link that takes us back. Also, the title of the journal should be shown nicely, and the picture belonging to the article too. (#214)
  2. The article showing page should receive the information from the journal that which tag was the tag of the box in which the user clicked on the article. (#215)

8. Registration and login

1 (16.0h) | 4 (33.0h)

  1. Send notification mails only to confirmed emails. (#114)
  2. The actual e-mail confirmation system (with a link that the user can click and accepted e-mail confirmations) should be developed. (#75)
  3. Smart user registration system should be developed. (#216, #223)
  4. Registration mechanism should be built into the comment posting system. (#131)
  5. On successful wizard completion, the user should be presented with an optional link that leads to his account page, preferences box expanded, where he can fill out his email. (#216, #223)
  6. Login window should be developed. (#235, #236)
  7. Captcha! (#261)
  8. The user should be given a randomly chosen color from our palettes. (#283)

9. Command line interface

A simple command line interface should be developed with which we can modify design, layout of the pages, and post or delete articles, and delete offensive comments.

  1. Export the current layout of a journal to yml. (#211)
  2. Reimport the potentially changed data. (#213, #212)
  3. Export/reimport boxrenderers, CSS files too. (#211)
  4. Posting an article (given a file name, a title, and a tag). (#213)
  5. Listing articles, (id, title, current tags). (#213)
  6. Tagging an article with a given tag. (#213)
  7. Removing a tag from an article. (#213)

10. User blogs

0 (Noneh) | 8 (0.0h)

Support user-created blogs, though as of now just with predesigned ones, not journal-frontpage editing. (It is a mistake that we call the blogs blogs, and not journals, but it is messed up in the current database schema... and it is not that critical after all. But be aware: Journal === Blog, so when I talk about journal, it is a blog entity in the database.).

On the interface, we should use the term journal everywhere.

  1. Create an owners = models.ManyToManyField(User) field for the Blogs table. Later we might delete this field, in case we decide to use the ACL system for this task, but in order to break the dependency to the development of the ACL system, it is the easiest to create this field now. Adjust initial-data accordingly. (#290)
  2. Create a journal-creation wizard as part of the account page, which can be invoked from the expanded "Journals" page. (It should be possible to link to this "New journal" interface from other parts of our system too, later the design will decide where to put these links.) (#289)
  3. Create a journal-management interface
    1. iGoogle boxes for every journal a user has (#292), and in the expanded view:
    2. article management (#293)
    3. journal deletion (#294)
    4. journal hiding (#295)
    5. owner management. For now, until we have ACL system, every owner can add/remove any owners. (#296)
  4. Create a new iGoogle box on the account page with title "Journals". Its content is a link to the journal-creation wizard, and, separated with a horizontal rule, a list of links the expanded journal management boxes. (#291)
  5. Create box for all articles written by the user (iGoogle box, collapsed and expanded). (#297)