You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The default presentation of the not our responsibility state, as set in https://github.com/mysociety/fixmystreet/blob/master/perllib/FixMyStreet/DB/ResultSet/State.pm#L80 misleads users when the reports are actually sent direct to a contractor or department's computer system. and can lead them to believe they are being fobbed off by the council. In the case of my council I see this mainly from the street works side, where it is bad enough. The street cleansing side does not use this status, but if they did the result would often be to deny council responsibility when the council actually has an enforcement responsibility.
To Reproduce
Reproducing this requires cooperation of the backend system users, so all I can really do is to provide an example: https://www.fixmystreet.com/report/4468321 This is not my report, as I don't deliberately submit reports expected to fail. This example shows more than one problem, as noted further down. I'm only addressing one here.
Expected behavior
I'd expect a message saying that it wasn't this department's responsibility but there may be other ways of reporting it to the council. Ideally it would say exactly who was responsible for rejecting the report.
Actually, it would be desirable, from a user point of view, to be told exactly where reports were going, although I can imagine some FixMyStreetPro customers might want to present a single brand.
Desktop (please complete the following information):
This is not browser related, e.g. it appears in emails as well.
Additional context
The reporter of the example resubmitted it (the cobranded site doesn't allow updates) and clearly gives the impression of feeling fobbed off: https://www.fixmystreet.com/report/4583692
I notice that the code has some cobrands have opt outs for this message, but they all still assume that only one entity handles all FMS reports, which is not true in my council's case. The closest one to a single department is "not Island Roads’ responsibility", but that is presumably because FMS is only used for roads, in that case.
The immediate reset of the state to Investigating is, itself a bug, but I'm currently trying to pursue that through the council, as it may lie on the contractor's side (believed to be Symology) or in the configuration of the interface between it and FMS, and may not be a problem in FMS itself.
The street cleansing contractor is using "no further action" in this situation, which also makes users feel fobbed off, but is really a problem on their side, believed to be Echo, so isn't something that can be addressed in FMS.
The text was updated successfully, but these errors were encountered:
Describe the bug
The default presentation of the not our responsibility state, as set in https://github.com/mysociety/fixmystreet/blob/master/perllib/FixMyStreet/DB/ResultSet/State.pm#L80 misleads users when the reports are actually sent direct to a contractor or department's computer system. and can lead them to believe they are being fobbed off by the council. In the case of my council I see this mainly from the street works side, where it is bad enough. The street cleansing side does not use this status, but if they did the result would often be to deny council responsibility when the council actually has an enforcement responsibility.
To Reproduce
Reproducing this requires cooperation of the backend system users, so all I can really do is to provide an example: https://www.fixmystreet.com/report/4468321 This is not my report, as I don't deliberately submit reports expected to fail. This example shows more than one problem, as noted further down. I'm only addressing one here.
Expected behavior
I'd expect a message saying that it wasn't this department's responsibility but there may be other ways of reporting it to the council. Ideally it would say exactly who was responsible for rejecting the report.
Actually, it would be desirable, from a user point of view, to be told exactly where reports were going, although I can imagine some FixMyStreetPro customers might want to present a single brand.
Desktop (please complete the following information):
This is not browser related, e.g. it appears in emails as well.
Additional context
The reporter of the example resubmitted it (the cobranded site doesn't allow updates) and clearly gives the impression of feeling fobbed off: https://www.fixmystreet.com/report/4583692
I notice that the code has some cobrands have opt outs for this message, but they all still assume that only one entity handles all FMS reports, which is not true in my council's case. The closest one to a single department is "not Island Roads’ responsibility", but that is presumably because FMS is only used for roads, in that case.
The immediate reset of the state to Investigating is, itself a bug, but I'm currently trying to pursue that through the council, as it may lie on the contractor's side (believed to be Symology) or in the configuration of the interface between it and FMS, and may not be a problem in FMS itself.
The street cleansing contractor is using "no further action" in this situation, which also makes users feel fobbed off, but is really a problem on their side, believed to be Echo, so isn't something that can be addressed in FMS.
The text was updated successfully, but these errors were encountered: