WebIssues/Plan for Version 1.0

Here's the most general development plan for the nearest future:

Server Side	Client Side
create branch 1.0; change the layout and structure of the server code	continue development of version 0.9.5; multi-pane interface
update WebIssues protol to version 1.0	create version 0.9.6; improvements not requiring changing the protocol
create the Administration Panel	create branch 1.0; adaptation to protocol version 1.0
create the Web Client

Note that the stages of development will overlap. In particular, the Administration Panel and Web Client can be created at the same time the protocol is updated to version 1.0. Also development of client 1.0 can be started before release 0.9.6 is finished and those versions can be merged later.

WebIssues Server 1.0

The most important changes will be server-side and the server will be rewritten in most part. The layout of the server code will look more or less like this:

admin/	the Administration Panel application
client/	the Web Client application
common/	common files: images, style sheets, email templates, UI templates, etc.
data/	user's data: configuration file, attachments, custom email templates, etc.
server/	the WebIssues protocol handler
system/	common PHP includes: database abstraction layer, logging, validation, logic, etc.
cron.php	entry point for cron job
index.php	login page for Administration Panel/Web Client
setup.php	the setup wizard
update.php	the update wizard

Note that index.php will no longer be the WebIssues protocol handler. Instead it will be a login page for the applications. Code handling the protocol will be moved to the server subfolder and the Client will automatically append server/handler.php to the server's URL.

The setup and update wizards will be similar to what already exists, except that they will allow, as the first step, to enter database connection details and will create the configuration file if it's missing. It will only be possible to update to version 1.0 from the latest version, i.e. 0.8.4.

The configuration file, all data files and custom user's files will be stored, by default, in a single folder called data so that it's easier for the user to back up everything, protect the folder from unauthorized access and perform the updates.

Configuration of attachment storage, notifications, mailing engine, logging, etc. will be stored in the database and managed using the Administration Panel. Only the database connection details will be stored in the configuration file.

Log will be stored in the database, not in log files, and the it will be accessible through the Administration Panel.

The Administration Panel in the future can also provide statistics, reporting, user management, types/attributes management and other administration features.

Both the Administration Panel and the Web Client will display in the top of the page a bar containing: links to the main page of these two applications (note that Administration Panel will only be accessible for server administrators), name and version of the WebIssues server, name of the logged user and a Log out link and a link to the help page. Both applications will share the same session and will redirect to the common login page if user is not logged in.

The Web Client will mainly provide access to searching, displaying and modifying issues. This has to be designed in details and it's the biggest part of the project. See the Web and Mobile Interfaces proposal for more information.

All PHP includes with common logic (including the database abstraction layer, logging infrastructure, session management, parsing and validation of data, mailing engines, template engines, etc.) will be stored in the system folder. Other common files, such as images, style sheets, email templates and common templates for the user interface will be stored in the common folder. Other files specific for each application will be stored in their respective folders.

All components of the server should be packaged together as they depend on each other and use a lot of common components. It would still be possible to publish various parts of the server on separate machines, for example the server can be published on one machine and admin and client on another. I was also thinking about the possibility to have multiple instances of the server within a single installation (which could be accessed from different domains or virtual folders) but I think this is something to be added in the future, if needed.

WebIssues Protocol 1.0

Here's a general list of new functionalities which will be added in version 1.0 of the protocol:

• deleting and moving issues
• editing/deleting attachments & comments
• storing filters, column settings, etc.
• tracking read/unread state of issues
• extended notifications

There will also be some technical changes in the protocol, such as:

• separate field for large text (e.g. when submitting a comment)
• multi-argument commands (for example mass-editing an attribute for multiple issues)
• separate command for getting server version, limit of attachment/comment size and other settings

Of course not all things have to be fully implemented in the first release of version 1.0. Some features can be delayed to version 1.1, 1.2, etc., depending on the progress that we make and new ideas that we add. However the 1.x releases should remain backward-compatible with version 1.0 and this should be taken into account when designing the protocol (see information about [../Protocol|protocol compatibility]).

WebIssues Client

At the moment I'm working on the 0.9.5 version of the Client which will have a multi-pane UI (similar to email clients) in addition to the current multi-window UI. It's mostly done in the trunk and the first beta can be released quite soon. There will also be some other small improvements, for example the possibility to change the default sort order of issues using the column settings dialog.

While the prototype of Server 1.0 is created and before protocol 1.0 is fully defined and implemented, we can simultaneously continue implementing new functions in the client which doesn't require changing the protocol. A detailed list of improvements should be created. Some proposals are: extending program settings (colors, fonts, etc.), improving editing values (for example adding a drop-down calendar to date fields), etc.

The most important part of client-side development can start as soon as the new protocol is implemented server-side. Handling settings, filters, watches and notifications must be refactored and new commands must be implemented.

Jobs and Tasks

The tasks related to WebIssues can be organized into the following 'jobs':

• server lead developer - coordinator of server development; main logic and components
• administration panel developer - logic of administration panel and setup/upgrade scripts
• web client developer - logic of web client
• web designer - UI of server components, graphics, style sheets
• server developer - implementation of the WI protocol
• database developer - database abstraction layer, db scripts
• junior web developers - help in various areas of the web applications
• client lead developer - coordinator of client development, adaptation to protocol 1.0
• junior client developers - help in various functional improvements

Obviously this is a very general list and it doesn't have to be strictly obeyed as we are following the free software development model. One person can take multiple positions and some positions can be assigned to more than one person (especially the junior ones). I reserve the client lead developer job for myself as it requires deep knowledge of the client's logic; obviously I will also be the coordinator of the whole project.

The list doesn't take into account the analysis and design phase. I'm assuming that the developer responsible for a given component will also be the lead analyst in that area; however it's not necessary. Also, especially in the analysis and phase, I expect high level of collaboration and creativity across all team members.