Setup stand-alone server Write Selenium tests that run against the web server - by default it should run agains the stand-alone server but should be configurable to run agains the Apache CGI and against the mod_perl version. Create a user group that can delete posts, lock (or delete?) users. Tests * Tests * Tests move database to PostgreSQL move to mod_perl Session information: remember logged in user, have check-box on the main form to say user wants to be remembered Enable users to connect their CPAN::Forum id with their PAUSE id: Let logged in user type in their PAUSEid send an e-mail with code to PAUSEID@cpan.org and save the same id in the session object tell the user to check their e-mail and copy the code to the approval form Unite and clean up the code that fetches list of people who need to be notified. Test both the interface to manage this and the the actually retreival of addresses to be notified. We might want to add another way of subscripton: to subscribe to a specific thread even if the user has not posted. One-time notification of module author when the first post arrives to one of her modules. Missing entries: ApacheDBI Net-SMS-TWSMS missing from 02... and from CPANTS they are both on search.cpan.org, now they are going to be auto-added but we should still understand this issue so we can keep the version numbers and the author changes up-to-date. Improve the populate.pl, look at CPANTS for ideas: http://search.cpan.org/src/DOMM/Module-CPANTS-ProcessCPAN-0.62/bin/update_authors.pl Finish the recent.pl file and maybe replace the populate.pl by using recent.pl # use this file to retreive list of CPAN authors and their e-mail address # http://www.cpan.org/authors/01mailrc.txt.gz Cleanup the schema. Currently the schema/schema.sql is not the same as the schema used in the live application. Describe the schema (in Forum.pm) which fields are in use and which are not. Make the data restrictions stricter in the schema (UNIQUE, NOT NULL) Provide the alerts in rss feed as well, not only in e-mail. Let people subscribe to alerts but ask to have the RSS feed only, no e-mails. /rss/user/username Check if the database (and its parent directory) is writable by the process and give appropriate error message if not. BUG: If the directory of the database is not writable and logging was setup the application fails. Logging: enable logging based on a single client IP address Include number of AnnoCPAN posts BUG: When I try to reply and the original subject is already 50 chars long in offers a new subject with Re: prefix but then when I try to submit it won't let me. (So far is ok, though it should 70 or 100 long) But the main problem is that if I delete the last word from the subject and press preview again it returns the same error message as it put back the word where it was earlier. At the bottom of the pages add subscribers to specific threads and thread started in separate listsings. Script that populates database should not lock the whole database for a long time Maybe it should fetch all the data to memory and work there. Add announcement service (check for new versions of modules and send e-mail to those whom are interested in announcements. For example I just tried to install a module but it failed its test. Checking search.cpan.org I noticed the module has been updated lately and looking at the results of the CPAN Testers I can see I am not the only one with these problems. So for now I skip the installation of this module but I'd like to get an e-mail when a new version of this module is uploaded to CPAN so I can try it while it is hot. I can subscribe to the announcement service of this module and get the message. Announcment service for new modules (modules that appear on CPAN for the first time) For this I n Register the PAUSEID where the module was last seen: Send out e-mail about PAUSEID changes In order to avoid accepting postings today that will break when we add more tags, we will reject any submission that is not correctly marked up. Create larger discussion groups (e.g. Web development and All) Record the date when a user joined Record when a user last visited Put time ellapsed since post instead of date of post, (3 min. 6 hours 3 days ago) make this configurable: User can say after N days passed the date should show, before that the ellapsed time - replace the e-mail address checking by if ($q->param('email') !~ $Email::Address::addr_spec) { - Enable people to edit their posts - Shall we track changes ? - Shall we display the orinal date and the last update date ? - Shall we display the post on its new date (order the display result by date ?) - Improve the markup language - Enable module authors (or some other volunteer) to configure some aspects of the section of their own module - Posting a message under more than one distribution - Get a nice logo and favicon.ico - xml version of the search results Admin: hide a posting Admin: delete or disable a user Admin: disable posting to a distibution, Admin: hide a distribution and all its postings Admin: change username ? Admin: hide a message (or a whole thread) (database already has field) Admin: freeze a distro: (cannot add new message but still can see the earlier messages) Admin: (or even the author ?) should be able to move a message from one module to another module or group. - Statistics on posts, views etc. - Other (human) languages (?) - Enable sending direct mail to a poster (?) (without disclosing e-mail address) Include the information received from cpanratings in our database: For each "group" add two fields: "ratings" and "review_count" Better integration with search.cpan.org, cpanratings.perl.org Provide statistics on number of comments per distro to be displayed on search.cpan - Replace the /post/number link by /post/TITLE_OF_POST ??? - make the page size (for paging) user configurable - Allow users to subscribe for announcement service: A script that will send an announcement on the new version of every module to those who asked for this information. - JavaScript that lets users to set all the modules in /mypan to the same value (either All message or thread starter or Followup or nothing) PROBLEM: Currently when a new browse visits the site we immediately give a cookie and instert an entry in the sessions table. After running for about 10 days we have about 32.000 entries in the sessions table. It is not likely that so many people have visited the site. I think the crawlers of Google and co. never return the cookie that I give them and thus every hit they generate will create a new cookie and a new entry in the sessions table. Besides, I never clean up the sessions table. So let's see what can we do 1) Add an index to that table to speed up the access time (this I should do in any case) 2) If I recognize a crawler (e.g. googlebot) don't give a session ID to it. 3) Run cleanup routine that will delete old sessions: As right now the session time is only kept within the a_session field this will be a slow process but should be done anyway 4) Add a field to the session table where I indicate the last access time - check out the remote authentication module of David Nicol: AIS::Client and its server. - Decide on Basic Markup language and how to extend for shortcuts opening tag for code: ]*> but right now only should be accepted closing tag for code: - check all submitted fields (restrict posting size to 10.000 Kbyte ? - Improve text and explanations. - clean up documentation - add indexes to the tables ? - show the release dates and version numbers of the modules Authentication and user management process: - new user comes to our site we give him a cookie, when he wants to login we offer him -- login using the auth.perl.org credentials -- login using XYZ credentials -- create local credential -- For auth.perl.org --- redirect the user to auth.perl.org wait till he logs in there (maybe even creates the new account) --- sets the preferences --- comes back --- we can fetch some of the information from that user --- we need to keep the user_id received from auth.perl.org for later identification of the user --- while we tell the user we would like to get the username/fullname/e-mail address from auth he might not want to give, for this case we should have our way to update the locally updated username, full name and validated e-mail address. -- For local credentials we need the user to give us username/password/fullname and validated e-mail address. We have to make sure that usernames which are displayed don't collide. Maybe we should use separate fields for usernames from various sources and when displayed we might prefix it auth:gabor, local:gabor etc. Not nice, any better way ? - Fix Installation - when installing one might need to be root, in order to set the permissions correctly ? - as user www fetch the module list file, unzip it in the db directory (as this is the only directory we can write to) and run the populator - on a new installation, change the ownership of directories (or at least tell the user to do so) - Reply within a thread When replying to a post within a thread we might want to open the editor window in the middle of the thread, just below the post I am responding to. - make sure links that are relevant for distros don't show up on pages which don't belong to distros. (e.g. a link to search.cpan.org/dist/CGI is ok but a link to search.cpan.org/dist/General is not) - Sometime we'll want to post a message in more than one group, e.g. now I'd like to know how to use CGI::Session with DBD::SQLite. I might want to post the message on more than one list at the same time as this is related to more than one module. Porbably if I need to chose one I'll select CGI::Session as I am trying to use that but it might be a nice feature. Maybe I need to tell one module as the main group and then have a way to associate a few more modules with the posting. This can be done by de-coupleing the name of the distribution from the posts table for all the distributions or we can add such an extra table for the additional distributions so there will be a leading distro of the thread. - Create a group for - each Distribution (DONE) - Some bigger groups (eg. databases, testing, ) maybe put each distribution under one or more of the groups too - General and other special purpose groups such as News (for the site) where only "administrators" can post. I am not sure if I have to keep all these things in one table and if the same form has to serve for creating messages in both distros and categories. - Database or plain files ? I think every information should be in the database but then we might want to generate static pages from the posts and discussions in order to reduce the need to fetch information from the database. Hmm, it sound faster but we'll probabl want to build the pages on the fly anyway so maybe it does not improve anything. We can start off by totally dynamic pages and then see if making them static will reduce the load on the server. First we'll have to have load on the server. :-) - Check if the technique we use to remember the last request before login cannot cause some security problem such as remembering the last request of someone else who used the same machine recently ? - xml - provided In order to prepare a downloadable version of the database we need to hide the personal infromation: update users set email = 'test_' || id || '@cpanforum.com' where id in(select id from users); update users set password = 'testpw'; update users set username = 'test_' || id where id in(select id from users); update users set fname='', lname=''; delete from sessions; delete from configure; -- ??? delete user_in_group; -- ??? update posts set uid=myuid where (select users.uid myuid from users where posts.uid=users.username; select posts.id pid, users.id uid, users.username from posts, users where posts.uid=users.username; Removed the use of CPAN::Forum::Build - need to see what was it doing and replace its functionality with something better Allow the module author to put an announcement in front of their module forum. Just some arbitrary block of HTML is fine. Allow the author to delete their forum. "Opt out". ???? Shlomi: The Forum uses cgiapp_prerun to set the mode according to the PATH_INFO instead of using a mode_param code-reference. This causes a lot of warnings in the logs, and doesn't really belong in cgiapp_prerun. It cannot be hosted on a URL except for its own virtual host, as it uses absolute URLs. ("/login/", "/register/", etc.) A better idea would be to track the path that the web-server gives (it's in one of the environment variables) and then to construct a /cpan-forum/login/ /cpan-forum/register/ etc. path. (or use relative URLs).