Adding a module to provide an “Issues List” client service

Richard Gould Cory Horner Jody Garnett

New Module Request

Not intended for a GeoServer release (ie this is a community module), results in a dependency available for community projects.

Withdrawn - was decided a GSIP was not needed for a new module request.

• IIssuesList

JIRA task:

Email discussion:

Other wiki discussions:

Client applications have a need to share “issues”. Such applications would request a list from GeoServer for resolution by the user. This resembles a bug tracker with the key addition that issues will usually reference a feature or geometry. More serious applications will make use of a workflow system (say JBoss) also resulting in a list of issues. This API will allow

Examples of an issue:

• WFS feature validation error
• workflow task

Much like the preferences module, the issues list module will take advantage of hibernate to back entries onto a database. Also similar to the preference module the resulting module will make available an API.

The IssuesAPI will be available:

• via SpringRemoting for client applications
• as a Bean for use in Spring wiring for other modules to use

Care will be taken during the construction of this API to allow for Issues to be retrived at two levels of granularity.

• As an Issue List where isssues relationships are not fully explorered
• On a per Issue basis, with all relationships resolved

The interface is subject to change; the initial cut is:

This interface forms the API used by other GeoServer modules, and will be made available to client applications via spring remoting.

interface IssueList 
  Set<String> getGroups()

  /** Shallow Issues, ie name, id, bounds, but not details like feature */
  List<Issue> getIssues(String groupId)

  /** Complete Issue, suitable for editing */
  Issue getIssue(String issueId)  
}

The uDig IIssuesList class provides some inspiration for this interface.

This class is based on the uDig Issue Model (and may be one in the same). Additional information may be required as we make use of a JBoss workflow implementation. At the very least a memento construct should be available for both the client and server side processes to store state associated with the issue (in an opaque fashion).

interface Issue {
  String getId()
  String getDescription()
  void setDescription()
  String getProperty(String key)
  void setProperty(String key, String value)
  Resolution getResolution()
  void setResolution(Resolution resolution)
  ? getBounds()
  ? getFeature()
  ...

interface Resolution {
}

• Pablo Casado (Bluesphere/SENS)
• Richard Gould
• Cory Horner