Enum resolvers: Add status enum for each entity type

[iLLiCiTiT]

PR Checklist

Added statuses enum resolver for each entity type there is.

Description of changes

Class StatusesEnumResolver now has defined entity_types to define set of available entity types for which to return statuses. The entity types enum is filtering them by the value and also create new items based on it. Then were added separate classes for each entity type.

Technical details

I first added entity_type as a string and then changed it to set[str], not sure if there might be usecase in future to be able to show statuses for folder and task at the same time? If not it should be easy to revert entity_types to entity_type.

Additional context

Currently the StatusesEnumResolver really can't be used in production as the usage is always scoped to a certain entity type.

[martastain]

Instead of having a separate resolver for every entity, couldn't we just use params? (add entity_type: str to accepted params and then use it in the same way project_name is used. That was the original idea of passing additional settings to resolvers. Ofc we could have aliases like in this PR, but the support for passing additional contextual parameters in query string is already there and can be used.

[iLLiCiTiT]

Instead of having a separate resolver for every entity, couldn't we just use params? (add entity_type: str to accepted params and then use it in the same way project_name is used. That was the original idea of passing additional settings to resolvers. Ofc we could have aliases like in this PR, but the support for passing additional contextual parameters in query string is already there and can be used.

That would be better, BUT how would you then use it in enum_resolver?

[martastain]

You mean in settings? This should work:

class MySettings(BaseSettingsModel):
    folder_status: Annotated[str, SettingsField(enum_resolver=lambda: EnumRegistry.resolve("statuses", entity_type="folder)]
    

[iLLiCiTiT]

You mean in settings? This should work:

So what is StatusesEnumResolver for? That requires some knowledge of EnumRegistry and you have to use lambda. Whereas with this, you can just use it...

[martastain]

The point is, that resolvers can have multiple parameter. and you'd need to write a resolver for every combination :)

the resolver already accepts project_name (but it is auto-populated in the case of settings). Also, having a central registry means that we can (well - we could, if we had time) export documentation: list all resolvers and accepted parameters.

[iLLiCiTiT]

Ok, still, same question as above, what is StatusesEnumResolver for?

[iLLiCiTiT]

Would the current approach work, added entity type param and also added for_type class method for easy usage.

[kalisp]

LGTM but probably @martastain should approve too