It is obvious which part of the config needs attention and what steps to take to remedy it (e.g. using rooms remove or rooms add). Even if the exact reason for the config's failure to load is not diagnosable.
It is possible to introspect on the config. That isn't to say the exact JSON needs to be presented, that could be too technical.
Details
The way this will work is we will have to identify each piece of config and build an editor for them.
The configs
org.matrix.mjolnir.watched_lists
org.matrix.mjolnir.protected_rooms
org.matrix.mjolnir.enabled_protections
Note, these configs may fail when they load, but are more likely to fail downstream when consumed by their respective managers e.g. ProtectedRoomsManager (in the case of protected rooms).
The editors need to be prepared to handle anything, including completely garbled or undeserializable JSON. And being able to use the client server API to reset them.
There should be no reason to use devtools. If for example there is a malformed room id in the list, it should be possible for the editor to revert down to parsing room references as strings and presenting them as items in a list, allowing the config to still be viewed and edited.
This may require a general JSON editor (operated by commands of course) that can use JSON paths. But maybe we can avoid that. It's probably possible for us to display each value alongside it's JSON path in a code block, so that it is easy for the user to copy paste. Equally, we could make that path a prompt reaction.
Is it possible for us to reuse the ProtectionSettings editors and schema here? But we'd also want to be able to recover protection settings when they become corrupted too.
Restarts
As a stretch, each piece of config could pre-empt where issues arrive and suggest a course of action. So for example, wathced lists could suggest unwatching the list that is causing issues and create a prompt to do that for the user.
Then once the prompt has done, we can prompt to restart and boot into draupnir.
The way that can work is by adding something like a restart to a ResultError which really would be a side effect that can be triggered. Actually doing the restarting part would have to be all manual i think? Yeah. We could even add more restarts like how elaborationswork, and then show a list of available restarts.
Main story: https://github.com/the-draupnir-project/planning/issues/1
Acceptance criteria for this task:
Details
The way this will work is we will have to identify each piece of config and build an editor for them.
The configs
org.matrix.mjolnir.watched_listsorg.matrix.mjolnir.protected_roomsorg.matrix.mjolnir.enabled_protectionsNote, these configs may fail when they load, but are more likely to fail downstream when consumed by their respective managers e.g.
ProtectedRoomsManager(in the case of protected rooms).The editors need to be prepared to handle anything, including completely garbled or undeserializable JSON. And being able to use the client server API to reset them.
There should be no reason to use devtools. If for example there is a malformed room id in the list, it should be possible for the editor to revert down to parsing room references as strings and presenting them as items in a list, allowing the config to still be viewed and edited.
This may require a general JSON editor (operated by commands of course) that can use JSON paths. But maybe we can avoid that. It's probably possible for us to display each value alongside it's JSON path in a code block, so that it is easy for the user to copy paste. Equally, we could make that path a prompt reaction.
Is it possible for us to reuse the
ProtectionSettingseditors and schema here? But we'd also want to be able to recover protection settings when they become corrupted too.Restarts
As a stretch, each piece of config could pre-empt where issues arrive and suggest a course of action. So for example, wathced lists could suggest unwatching the list that is causing issues and create a prompt to do that for the user. Then once the prompt has done, we can prompt to restart and boot into draupnir.
The way that can work is by adding something like a
restartto aResultErrorwhich really would be a side effect that can be triggered. Actually doing the restarting part would have to be all manual i think? Yeah. We could even add more restarts like howelaborationswork, and then show a list of available restarts.