We should create the config $wgIncidentReportingInactiveServices for IncidentReporting. It would work to prevent inactive services appearing as an option when creating a new incident report, but maintain the now-inactive services for historical reasons for past incidents using them. No new incidents would ever need them, so it makes sense to not make them able to be used for new incident reports.
Description
Related Objects
- Mentioned Here
- R9:d3a44c982740: set wgIncidentReportingInactiveServices
Event Timeline
That's the only way I can see this being done without rewriting the extension, no idea why it doesn't work. That loop formats the name of the service for addition to the form, the new code checks if the service is in the InactiveServices config, then skips the rest of the loop in that iteration if it is. It should prevent the service from being added to the $irServices variable, thus never appearing in the form. Logic seems good, don't know what's happening.
Maybe I've misunderstood the config yet again but when I tested out https://github.com/miraheze/mw-config/pull/5101, this is what it appears like
I think it's a problem on my end actually. Special:IncidentReports is also used to check IncidentReports, right? Revert my PR, I'll write another way of doing this.
Actually, yeah, that function seems to be used to create the incident services table, all my code does is remove their names from there, which is obviously not what's supposed to happen. Incident reports are created at Special:IncidentReports/create, I should be messing with https://github.com/miraheze/IncidentReporting/blob/master/includes/IncidentReportingFormFactory.php instead.
Ok, this time it should work, works the same way as described above, config should look like R9:d3a44c9827409401d1640a548fbb699644a6aff5: https://github.com/miraheze/IncidentReporting/pull/56
It's mostly because of how the HTMLForm class works. Real HTML forms are much more flexible than the abstraction by MW (for example, if I could set custom attributes in the <option> elements, I could set the "hidden" attribute right there and then (it could look like ["label", "value attribute", "custom attribute"], just an additional entry in the array on the form descriptor. I wonder how hard it would be to get that into the MediaWiki core)), and I don't really find any way of doing this without a major rewrite, also, adding that godforsaken unmaintainable CSS hack I suggested, while possible and easier than rewriting, wasn't a good idea.
In fact, I think I know why HTMLForm doesn't support things like the "hidden" attribute. MW *still, in 2023*, supports that so-called "browser", Internet Explorer 11, and the hidden attribute is not supported there.