Server using a custom storage implementation

[juokaz]

Summary

A server implementation that stores tickets in and retrieves tickets from a storage system of its choice, be it flat files, a database or the almighty cloud.

Requirements

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in IETF RFC 2119.

Specification

The server MUST support anyonymous and authenticated users. The server MUST NOT put additional constraints such as email address validation into place for anonymous users.

The server MUST support retrieval and creation of tickets and comments.

The server MUST support closing and reopening and SHOULD support updating of tickets and comments by appropriately authorized users.

The server MUST support retrieval of information about users.

The server SHOULD support creation and updating of users.

The server SHOULD NOT discard unknown elements in requests upon serialization to the data store.

[caseysoftware]

Relates to: #4

[BigBlueHat]

Hacking on a CouchDB-based server option in the Storm Trooper room back by the offices. Join us if you'd like.

[joelclermont]

What does it mean to be an "appropriately authorized user"?

There is an implied concept of admin user and normal user. Can this be clarified in the requirements?

[JagPadala]

Is the authorization going to be basic auth?

[mamund]

yes.

[dzuelke]

@joelclermont: done, the example document "users.xml" now has three different user account levels listed.

@JagPadala: yes, as stated on the Hackday wiki page :) We chose not to use OAuth since that's a whole different can of worms.