Add a "re-enqueue" action command on a Buildset page, displayed only
if the currently logged in user is an admin on the tenant. By
clicking this command, the user can re-enqueue the change with
the same parameters as the buildset.
Redux: turned the API error notifications into a more generic
notification system, that can now include success notifications.
Change-Id: I05b6b3deb912b121df8de207944d9ec26e7c92d1
This corrects a problem in the error handler when some request
variables are undefined.
This also handles the case of a buildset with no builds; currently
the REST API omits the builds value in that case, so this updates
usages to handle it.
Change-Id: Ifa09990d08257244f17e77e5c8141bfd8c1cc4d7
To improve user experience when fetch errors are encountered
due to expired sessions, an additional common solution proposal
is added here to the error message.
Change-Id: If7f8e905969acabd3e66710c519267d86367289d
In the case of a CORS error (which we suspect is similar to the
error caused by privacy badger blocking a request), we get an
Error object with a .message and .request, but no .response.
The .request.responseURL is also empty.
To provide the best feedback we can to the user, let's include
the URL (or the closest approximation possible) to our error
reporting methods, so that if they are called and the responseURL
is empty, we can use the supplied URL as a backup.
Further, if there is no response object, supply the message from
the error and abuse the status field to augment that with some
"helpful" text about network connectivity and ad blockers.
The result is that a user with a blocked CORS request should see:
*Network Error*
(Unable to fetch URL, check your network connectivity, browser plugins,
and ad-blockers) http://example.com/some-url
Change-Id: Ie7b989f9fb1576bfa23ed52c04c0cc308f124baa
This change adds a new error reducer to manage error from API calls.
The info actions retries failed info request after 5 seconds.
Change-Id: Ieb2b66a2847650788d9bf68080ab208855941f24
Matthieu Huin