Difference between revisions of "WebIssues/Plan for Version 1.0"

From MiMec
Jump to: navigation, search
(New page: Here's the most general development plan for the nearest future: {| border="1" cellpadding="5" cellspacing="1" ! Server Side ! Client Side |- | create branch 1.0; change the layout and st...)
 
 
Line 1: Line 1:
−
Here's the most general development plan for the nearest future:
+
The WebIssues server will be completely rewritten in version 1.0 and an integrated Administration Panel and Web Client will be added. Many changes are required in the database and the protocol in order to make it possible store all information on the server side and share them between the client and the server. Also many already existing features will be redesigned (including filters, watches and notifications) and new capabilities will be added.
−
 
 
−
{| border="1" cellpadding="5" cellspacing="1"
 
−
! 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 ==
 
== 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:
+
The layout of the server code will look like this:
  
 
{| border="1" cellpadding="5" cellspacing="1"
 
{| border="1" cellpadding="5" cellspacing="1"
Line 29: Line 10:
 
| client/ || the Web Client application
 
| client/ || the Web Client application
 
|-
 
|-
−
| common/ || common files: images, style sheets, email templates, UI templates, etc.
+
| common/ || code shared between the admin and client applications; data files and resources (images, style sheets, scripts, etc.)
 
|-
 
|-
−
| data/ || user's data: configuration file, attachments, custom email templates, etc.
+
| data/ || user's data: configuration files, attachments, logs, etc.
 
|-
 
|-
 
| server/ || the WebIssues protocol handler
 
| server/ || the WebIssues protocol handler
 
|-
 
|-
−
| system/ || common PHP includes: database abstraction layer, logging, validation, logic, etc.
+
| system/ || code shared between all parts of the application: 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
+
| index.php || the login page
 
|}
 
|}
  
−
Note that <tt>index.php</tt> 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 <tt>server</tt> subfolder and the Client will automatically append <tt>server/handler.php</tt> to the server's URL.
+
Note that <tt>index.php</tt> will no longer be the WebIssues protocol handler but instead it will be a login page for the web applications. Code handling the protocol will be moved to the <tt>server</tt> subfolder and the desktop client will automatically append <tt>server/webissues/handler.php</tt> 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 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 automatically create the configuration file. They will be stored in <tt>admin/setup</tt> subfolder.
  
−
The configuration file, all data files and custom user's files will be stored, by default, in a single folder called <tt>data</tt> so that it's easier for the user to back up everything, protect the folder from unauthorized access and perform the updates.
+
The configuration file, all data files and custom user's files will be stored, by default, in a single folder called <tt>data</tt> so that it's easier for the user to back up everything, protect the folder from unauthorized access and perform the updates. As much configuration data as possible will be stored in the database and managed using the Administration Panel. Also an event log will be stored in the database (accessible through the Administration Panel) and only debugging information will be logged to text files.
  
−
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.
+
See [[../MVC_Pattern|MVC Pattern]] for details of the architecture of the server application.
  
−
Log will be stored in the database, not in log files, and the it will be accessible through the Administration Panel.
+
== Protocol Changes ==
  
−
The Administration Panel in the future can also provide statistics, reporting, user management, types/attributes management and other administration features.
+
The most important functionalities which will be added in version 1.0 of the protocol are:
−
 
 
−
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|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 <tt>system</tt> folder. Other common files, such as images, style sheets, email templates and common templates for the user interface will be stored in the <tt>common</tt> 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 <tt>server</tt> can be published on one machine and <tt>admin</tt> and <tt>client</tt> 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
 
* deleting and moving issues
−
* editing/deleting attachments & comments
+
* editing/deleting attachments and comments
−
* storing filters, column settings, etc.
+
* managing filters, column settings, etc.
−
* tracking read/unread state of issues
+
* tracking read/unread state of issues, managing watches
−
* extended notifications
+
* updated support 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
+
Other changes include:
−
* administration panel developer - logic of administration panel and setup/upgrade scripts
+
* increase maximum length of attribute values to 255 characters and add support for multi-line fields
−
* web client developer - logic of web client
+
* support for localization of the format of dates and numbers
−
* web designer - UI of server components, graphics, style sheets
+
* command for getting server version and settings
−
* 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.
+
== Web Client ==
  
−
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.
+
The Web Client will be a regular web application without AJAX and generally it should be possible to use the Web Client without JavaScript enabled. On the other hand, the application should provide functionality equivalent to the desktop client, including a three-pane UI similar to email clients and support for all operations which can be performed through the desktop client. The UI doesn't have to be identical and should be design with web design principles in mind; for example contextual menus will be replaced with equivalents more natural to web applications. The Web Client will be fully localizable just like the desktop client.

Latest revision as of 21:17, 26 June 2010

The WebIssues server will be completely rewritten in version 1.0 and an integrated Administration Panel and Web Client will be added. Many changes are required in the database and the protocol in order to make it possible store all information on the server side and share them between the client and the server. Also many already existing features will be redesigned (including filters, watches and notifications) and new capabilities will be added.

WebIssues Server 1.0

The layout of the server code will look like this:

admin/ the Administration Panel application
client/ the Web Client application
common/ code shared between the admin and client applications; data files and resources (images, style sheets, scripts, etc.)
data/ user's data: configuration files, attachments, logs, etc.
server/ the WebIssues protocol handler
system/ code shared between all parts of the application: database abstraction layer, logging, validation, logic, etc.
index.php the login page

Note that index.php will no longer be the WebIssues protocol handler but instead it will be a login page for the web applications. Code handling the protocol will be moved to the server subfolder and the desktop client will automatically append server/webissues/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 automatically create the configuration file. They will be stored in admin/setup subfolder.

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. As much configuration data as possible will be stored in the database and managed using the Administration Panel. Also an event log will be stored in the database (accessible through the Administration Panel) and only debugging information will be logged to text files.

See MVC Pattern for details of the architecture of the server application.

Protocol Changes

The most important functionalities which will be added in version 1.0 of the protocol are:

  • deleting and moving issues
  • editing/deleting attachments and comments
  • managing filters, column settings, etc.
  • tracking read/unread state of issues, managing watches
  • updated support notifications

Other changes include:

  • increase maximum length of attribute values to 255 characters and add support for multi-line fields
  • support for localization of the format of dates and numbers
  • command for getting server version and settings

Web Client

The Web Client will be a regular web application without AJAX and generally it should be possible to use the Web Client without JavaScript enabled. On the other hand, the application should provide functionality equivalent to the desktop client, including a three-pane UI similar to email clients and support for all operations which can be performed through the desktop client. The UI doesn't have to be identical and should be design with web design principles in mind; for example contextual menus will be replaced with equivalents more natural to web applications. The Web Client will be fully localizable just like the desktop client.

Retrieved from "https://wiki.mimec.org/index.php?title=WebIssues/Plan_for_Version_1.0&oldid=230"