Page MenuHomeMiraheze

Create $wgIncidentReportingInactiveServices config
Closed, ResolvedPublic

Description

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.

Event Timeline

Unknown Object (User) triaged this task as Low priority.Nov 23 2022, 16:37
Unknown Object (User) created this task.

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

image.png (343×1 px, 63 KB)

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.

I give up, if someone else wants to try be my guest.

Unknown Object (User) added a comment.Feb 1 2023, 18:34

I give up, if someone else wants to try be my guest.

Thank you for trying. It seems to be more difficult then it originally seemed.

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.

Unknown Object (User) removed a project: Universal Omega.Mar 18 2023, 03:33
Herald removed a subscriber: Unknown Object (User). · View Herald TranscriptMar 18 2023, 03:33
Universal_Omega claimed this task.
Universal_Omega subscribed.

This was done.