(but also the most rewarding for users )
- Bugzilla/AppDB login integration, Single signon for Bugzilla and the AppDB.
- Need to figure out how to combine the two sets of account databases, you could possibly create one master login wrapper with PEAR::Auth to authenticate on both systems and provide the user with one login.
- How to provide the Bugzilla and AppDB authentication cookies
- How to make the changes to both AppDB and Bugzilla as localized as possible to keep both applications usable for non-Wine related databases
- Note that there is no strong need to figure out which existing accounts are duplicated - once a single signon is implemented, all legacy accounts in AppDB could be removed while bugzilla accounts take over (or vice-versa).
- Plan B would be to get the Appdb onto OpenID. Our current project web facing stack is bugzilla, moinmoin wiki, appdb, phpbb forum
Bugzilla is moving that way - https://bugzilla.mozilla.org/show_bug.cgi?id=413617
moinmoin (our wiki) already has support - http://moinmo.in/FeatureRequests/OpenIDSupport
phpbb has a rough fork implementing support - http://sourceforge.net/projects/phpbb-openid/
- This ties in with the look and feel, as well as performance of the AppDB. Update the AppDB to Web 2.0, use AJAX where possible to avoid reloading the entire page and only refresh a subportion. This keeps the workload of the server down and eliminates page refresh flicker. Possible areas to be improved menus, login system, screenshots( increment one at a time with a left or right button, possibly one shot on either side of the image in view in reduced size much like the application launcher applets).
- Add a 'browse regressions' page
- Change the rejection system to be more friendly and informative. Store the processors comments on what needs to be improved or what needs explaining, and call it 'awaiting feedback' instead of 'rejected'
- Ability to email users that have selected notification of new applications added to the appdb, or perhaps that match given key words
- Email addresses are not checked if they are per spec, neither on sending nor on entrance into the db. Checking with a confirmation mail might also be useful.
- A mailing list that archives all email notifications.
- Currently applications have an URL field that is also displayed on each version, it should be replaced with something like the list of url+description pairs, possibly with the description "Homepage" for the old data.
- Add some way for admins (e.g. on the contact form or linked from it) to list information about a user like which reports/comments/apps/versions he submitted, which applications he maintains.
Up for discussion: Put HowTos on the wiki. Perhaps with an specific naming scheme (like AppDB/ApplicationName[/VersionName] ). Many HowTos share information (e.g. on copy prevention or how to do multi-cd installs) possibly put that under AppDB/Generic/FeatureOrProblemName (Does the wiki support something like include?). Then just link from the version page (one could also inline it or even include it on the server side) either manually in what we currently use for HowTos or automatically according to the naming scheme. This would have the added benefit that more users can contribute to the HowTos and that there is a history for the edits. Also generic reusable information in HowTos is currently hard to distinguish from the application specific information.
- Improve the notification mails. They could include who made the change and why (currently implemented for some actions), as well as a link to the contact form
- Allow maintainers to add notes/hints to the test result submission form
- Allow users to disable the contact form
- People cannot monitor an application family, only a application version. This is not a major problem but the feature would be nice to have
- Show a list of bug links for the version when processing test results. This should avoid maintainers replying 'please file a bug report' when there already is one
- Option for admins to disable global email notifications for themselves.
- Option to look at the test results for a certain version of wine (in a similar way that you can see all tests for a Distro).
Use exceptions to handle errors in creating User, Application and Version objects instead of either silently failing or requiring calls to "class::IsValid()" like functions
- Way to feedback information to the owner of the application to tell them that you use the app under wine
- Might be as simple as adding a note to the application with the appropriate vendor email address.
- Overhaul the look and feel of the AppDB. It looks a bit clunky in areas and I think with some polish it would be more pleasing to the eye and easier to maintain the look and feel.
Minor problems with the app screenshots. The screenshots screen (eg. ) has too many boxes and requires Too many clicks to see a screenshot. IMO, it would be a little cleaner to just show the first screenshot here, and have a [<<prev] and [next>>] link or quick index.
- Consider replacing the Google search. Alternatives
- Implement it with the help of the objectManager. By adding filtering options (see 'Medium' above) we should be able to add an easy-to-use and yet comprehensive search feature. Since we run a database we should be able to make the most sense of our data, and keep a consistent user interface
Create an advanced search page, recent updates to the AppDB have included specific queries such as browse_by_rating, browse newer apps, etc. Each time we create a new query we add a menu item. This is going to get cluttered fast.Create one page where the user selects what they would like to query, application, version, vendor, etc. Based on the selection the page should be generated by the columns existing within that table that we allow them to search upon. For example the user decides to query applications, then a drop down would populate containing fields such as date submitted, name, category etc., then the user would select an option populated for that column.( for dates >=, <,>), (version, =, contains, starts with, etc.)
- Add the ability to merge one version of an application into another and the ability to merge one version inside an application into another version, this would copy over all comments, test data and notes/howtos/warnings but not the application/version description (the one being copied to would stay as it is). (Except for moving how-tos and bug links, this is already implemented; it would only require extending the existing function and adding an interface for it)
In progress tasks
- Support accessing application entries via short URLs - John Klehm
- Add support to objectManager for filtering entries based on criteria like submitter and parent entries. For test results we want to have two parents: version and distribution - Alexander Sørnes
- Add a queue state of 'pending' to denote entries whose parents are queued. This will greatly simplify the SQL code and give a nice performance boost - Alexander Sørnes
- Support undelete. Add a queue state 'deleted' insteade of removing entries from the DB - Alexander Sørnes
- Improve/redesign AppDB forums. Considering the time it would have taken to integrate existing forum software, we should get a much better result by implementing our own with the features we need - Chris Morgan
- PHP script to automatically regenerate the image montage seen on the main page of the appdb in the upper right hand corner. This script should create a new image every X minutes (set in the appdb configuration file include/config.php file) - EA Durbin
- Fixing all notices to prevent nasty bugs in the future. Time consuming, so help is needed. - Edwin Smulders