* Redirect to default source on invalid source ID
When supplied with an invalid source ID, the CheckSources component
would redirect the user to a "Create Source" page. This caused
surprising behavior when a source was deleted because that source ID
would become invalid. The effect being that deleting a source brought
users immediately to the create source page, rather than back to the
sources list.
This instead redirects users to the default source when provided an
invalid source id. The backend automatically re-assigns the "default"
source, so this will always succeed, since sources are fetched again
from the backend.
The regex used is slightly dependent on URL structure that has been
stable over the lifetime of this project. Also it relies on URL
structure more than the previous redirecting implementation.
* Force sources to reload after deletion
Deleting a source invalidates the state held by the client because of
automatic re-assignment of the default source by the backend. Without
duplicating backend logic, it is impossible for the frontend to discover
the new source without reloading sources.
The ManageSources page now uses an async-action creator which deletes
the requested source and reloads all sources. The source action creators
have also been refactored to use implicit returns like other action
creators.
* Remove Dead removeSource action
removeSource is no longer used because the API invalidates its
assumptions. For more information, see 04bf3ca.
* Update Changelog with source deletion redirect fix
Users are no longer unexpectedly redirected to the "create source" page
whenever they delete a source that they are connected to.
* Return 404 when deleting non-existent source
When deleting a source, a new default is assigned automatically. If a
non-existent source ID was provided, previously this would result in a
500. This is a violation of the Swagger docs. The solution is to examine
the error and if it was an ErrSourceNotFound, invoke the notFound
handler.
* Add Error handling to source deletion
There are two kinds of errors that can be encountered when deleting a
source: a 404 and a 500 (from either the delete or the subsequent
fetch).
The 404 is a precondition failure of the action creator. The source.id
requested can be non-existent for two reasons: 1) The action creator was
passed garbage by the caller. 2) A concurrent write occurred which
silently invalidated this session's state. For the first case, we can
ensure that the caller is sane by having an assertion check that the
requested source is among some set of sources. This could be
circumvented by a caller, but chances are good that both the full set of
sources and the desired source are both available to callers of this
action creator. The second case is not an error. In this case, we should
proceed reloading sources, since the deletion that was requested has
already been performed by someone else.
Finally, 500s can only occur if there is something broken with the API.
In this situation, we provide a notification that tells the user to
check the API logs for more information.
* Remove duplicate CHANGELOG entries
These were introduced due to a naive merge conflict resolution.
* Remove assertion
This was decided to be confusing and unnecessary.
* Remove remnants of removed assertion
These were needed for an assertion that has been removed. It's no longer
necessary to pass `sources` to the action creator.
Chris Goller
Andrew Watkins
Timothy J. Raymond
Jade McGough