Target Directories from Ransomware plugin are broken

[ilija-lazoroski]

Describe the bug

Some package updates happened in the UI, possibly leading to target directories being shown as options in the Ransomware plugin. This could be happening in other plugins as well.

To Reproduce

Steps to reproduce the behavior:

1. Install Ransomware plugin
2. See the error in the configuration page

Expected behavior

It should be an input, not an option.

Screenshots

It seems that it has something to do with how the field is represented in the options. We have Optional field with a default value of None. If we remove the Optional part then:

If we leave the Optional part and add a different default value:

I am guessing Optional means Option? 😄

Machine version (please complete the following information):

• OS: Windows or Linux

[cakekoa]

The problem started when we updated the plugin build script to generate the config schema based on the options model. Before this, the schemas were generated manually. Now the build script uses pydantic's model_json_schema to generate the schema.

The ransomware target directory options are nullable types. The manually generated schema modeled this by using ["null", "string"] as the type of the field. The pydantic generated schema uses anyOf with one of the options as type: null. This anyOf is rendered by RJSF as a dropdown list.

Pydantic issue discussing anyOf for nullable types
PR adding RJSF's support for nullable types
RJSF documentation on nullable types

[cakekoa]

Potential solutions:

1. Provide a manually generated schema for Ransomware, and update the build script to only generate the config schema if one doesn't already exist
2. Use a custom generator that flattens out the anyOf when generating the schema
3. Flatten out the anyOf in the Island UI when retrieving the schema from the API
4. Submit a PR to RJSF to handle this anyOf case

[mssalvatore]

Sounds like #1 is perhaps the best approach. There may be other reasons in the future we would want a custom schema. Let's just make sure the build script prints a visible warning (use colors if possible) that warns when the schema is not regenerated.

[ilija-lazoroski]

Sounds like #1 is perhaps the best approach. There may be other reasons in the future we would want a custom schema. Let's just make sure the build script prints a visible warning (use colors if possible) that warns when the schema is not regenerated.

Something like this?