Specification

[radike]

The system keeps track of issues created by users. The issues are related to a city, e.g. a user is walking down a street, then he sees a broken street lights, so he takes out his phone and reports an issue.

Each issue has a name, category/type (predefined -> enum), description, state, created date, address (at least street is required) / GPS coordinates. The GPS coordinates can be obtained by HTML5 geolocation API or by converting (google places API) an address given by an user. An issue can be reported by a registered or anonymous user.

Client uses JavaScript framework and uses a REST interface of server [#15] . It has 3 layers:

• list of issues
• aggregated data presented in some way, e.g. heat map
• a map with the issues

Each issue has a chat [#17]. The chat is realtime and uses WebSocket (no refresh on a new message). Each message has a user name, date, and text.
The client uses Google Maps REST API.

Server side integrates the Redmine issue tracking system with our extensions. It also provides an interface between the client and the underlaying issue tracking system.
More technical: The business layer uses EJB. The persistent layer uses Infinispan. Dependencies are loaded via CDI. Bean Validation checks that all issues has coordinates near our city. Arquillian is used to test server's functionality.
The server uses Batching API [#16] to compute a heat map from the data.

JMS 2.0 API [#18] is used to integrate with some another systems, e.g. with some work management system. Change of an issue state is propagated to the JMS queue.

Each user has a nick, password, and email. There are 3 user roles:

1. Anonymous
2. Registered
3. Worker

Anonymous

• can see all issues

Registered

• can create and edit his issues
• can watch issues
• can post messages to a chat
• others can view his statistics (e.g. number of reported issues)

Worker

• can assign himself an issue
• can change state of an issue: from reported to accepted, rejected or solved