NOTE: This is implemented & commited. Feel free to submit bugs.

TODO: Update Architecture pages.

Anti-Magic

I don't believe in "magic" non-obvious code. Right now the wiki and tasks/rounds are coupled in a fairly nasty way, which has a bunch of nasty effects:

• Whenever we need task/round title we need to JOIN ia_textblock ON CONCAT. This is ugly and might also be slow.
• We have to split wiki page names and textblock security is fairly complex. It tends to leak out of the permission system?.
• Tasks have to be named like task/* and rounds like round/*. Am I the only one who has a problem with urls like round/arhiva and task/adunare?

There is also no way to make a wiki page read-only or edit-protected, which IMHO is a must-have for 2.0%20Walker.

Proposed changes

What I propose is to remove the explicit link between textblock "task/XXX" and task "XXX". We can do this by adding a title and a homepage field in ia_task and a security field in ia_textblock which can have a value of "task(XXX)".

The "security" description string is freeform and is only handled in the permissions system. It can be something like "public", "private", etc. Even if we decide to do an acl-ish system we could adapt it to forward permissions to a certain task. This is NOT a system to mark a wiki page as belonging to a task, it's only for security stuff.

The wiki system doesn't rely on this coupling for actual formatting, it doesn't even receive $page_name. All task references inside a page are explicit, why should security be different?

Advantages

• No more JOIN.
• No more splitting textblock name.
• All permission code goes in permissions.php.
• Does not change current round and task id's.
• Urls are truly free, we can have tasks like "arhiva/adunare" or "preoni/2007/runda3/11-12/capsuni" (but probably won't). Hidden rounds can have multiple pages (happycodin/clasament).
• It doesn't required extensive changes, and I volunteer anyway. Database conversion is automatic.

Disadvantages / Unresolved Issues

We can't attach tests to "task/adunare" anymore. We could attach to the task's homepage or to a special "evaluator page". Attaching to a homepage can complicate security and attaching everything to a special "eval" page will mess with the user interface (though we could attach them from the task details page).

We can't use task/gigi?action=edit-details anymore. I say we make a special "admin" namespace, with things like "admin/task/adunare", "admin/reeval", "admin/newtask" etc. Creating a round/task is fairly complex, we should make a macro/controller just for that, completely separate from the editor. First create the task/round in the database, THEN you can edit it. It's silly to copy templates in db code.

This doesn't solve the problem of users creating pages where they shouldn't. We could just add a lot of code into permissions.php, or we could have something in admin like trac's BadContent.

Shouldn the creator of a wiki page page have some special rights? NO, but we can have an owner for tasks/rounds from low-security users.

What about older revisions? We should always use the newest "security" descriptor.

Having multiple pages for a single task/round might confuse retarded people, but you don't HAVE to use this.

We can't get rid of the round/task column in ia_parameter.

Important: If this is done it has to be done before 1 Dec since it involves changing the url scheme.