test edit, please remove -- GarconDuMonde - 18 Jul 2005

IMC Database Development Page

• Multiple access levels (DB admin, IMC master, IMC moderator, guest...), single accounts for each user
• Automatic password reminder
• Syndication of contact data: A way to integrate an IMCs' contact data stored in the DB to a local IMCs website (XML?)
  Your IMC can include your IMC's contact data from the DB on its own contact page at YOUR-IMC.indymedia.org, so you only need to keep one entry up to date and don't need to worry about editing CMS templates once it has been integrated.
• A user-friendly frontend for non-IMC people to contact their local IMC (also but not limited to volunteer.indymedia.org)
  The right people at your IMC will be contactable through either contact.indymedia.org or volunteer.indymedia.org, this should also integrate the world map from volunteer.indymedia.org
• A user-friendly frontend for moderated cross-posting to multiple IMCs' mailing lists (possible also to multiple IMCs web sites).
• Syndication of a listing of local IMCs RSS's (as already availabe at http://contact.indymedia.org/oml.php
• Syndication of a listing of local IMCs web link collections
• Syndication of a listing of local IMCs calendars
• Store server(s) information related to each IMCs site(s)
• Store server admin contact information for the various IMC servers
• Store IRC channel information for the various IMCs
• Store multiple contacts for each IMC: IMC process liaison, IMC database maintainer, private contact(s) (or mailing list), public contact(s) (or mailing list), tech contact(s) (or mailing list)
• Store general information for each IMC (web site URL, historical info (web site founded in ..., biggest event coverage so far...), ), spoken languages, CMS used, information on the reputation (read: imc-process approval as official IMC) within the Indymedia network...)
• Automatically send update reminders to private IMC contacts twice a year
• Automatically send information on non-updated IMCs to DB admins (mailing list?) twice a year
• Templating,custom CSS etc.
• Clean design

Security

• Security is an important issue as the DB is supposed to store the IMCs' private contact data
• Make sure, the email functions can not be used by spammers or trolls
• While security is important, accessibility is slightly more important.

• Full i18n of all strings.
• not all bundled in one file, but rather one per language
• we could borrow the system from another codebase ?

• No mixture of logic & presentation anymore.
• Lay-out should be in templates.
• an easy to use base structure (base classes & stuff) that should make it easier to add extra functionality.

• A static part of the site for the public parts (like new_imc.php). maybe we can mirror that easily.
• dynamic admin part for things that need user authentication.

Seperation logic/presentation

separation public & private part.

Functionality

Code Design

Better i18n

ImcDatabase Development Page

This page will be used to discuss the structure of the code we will make for the dbase. Since it's now spaghetti-style & completely relying on register_globals we'll have to rewrite it anyway.

-- PseudoPunk - 07 Jan 2004