| Commit message (Collapse) | Author | Age | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
::Integration::Warwick subclasses ::Integration::Exor
refactor request_class and new_request
Exor service
Warwickshire updates retrieval, with datetimes
stubbing out of Oracle constants, for local testing
We also edit FMS's core PopulateServiceList routine to hide system
fields from FMS:
Bromley/Warwickshire send metadata in their services/FOO.xml
advising that you can pass, e.g. attributes[easting].
FMS by default shows all of these to the user to fill in, however
we don't *want* the user to supply these, rather they are added
by the cobrand.
Bromley had an exception for this (keyed by $body->areas->id).
We write this more generally for Warwickshire too, keying instead
by $body->name (as this is far less likely to be overridden for
installs using global or custom Mapit's)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Get Service Request Updates
This requires a new object ::Service::Request::Update, which of course
is not part of standard spec. So, in order to make the core not too
contaminated by :
* the endpoint should instantiate ::Service::Request::mySociety objects
which know about updates
* have added a learn_additional_types callback from Schema to Endpoint,
so that core doesn't need to know about /open311/service_request_update
* (but ::Spark knows about the exception for updates... meh, but is 1-line)
|
|
|
Subsystems include
* ::Spark encoding conventions for xml/json
* ::Schema using Rx to validate form of inputs and outputs,
including validation for, e.g., dates and CSV as part of Open311
Handles following paths:
* Open311 attributes for Service Definition
http://wiki.open311.org/GeoReport_v2#GET_Service_Definition
* POST service request
* GET Service Requests
* GET Service Request
Objects:
* ::Service
* ::Service::Request
|
