Feature request: Possible values for lookup fields restricted by condition

[juliusverrel]

Use case: Two schemas, User and Projects, both having a growing number of entries, many of which become inactive after a while. When assigning users or projects, or vice versa, it would be useful to filter the possible values for either by a condition on a different, e.g., user.status = current, project.status = active.

[auto-comment[bot]]

Thank you for opening this issue. CosmoCode is a software company in Berlin providing services for wiki, app and web development. As such we can't guarantee quick responses for issues opened on our Open Source projects. If you require certain features or bugs fixed, you can always hire us. Feel free to contact us at [email protected] for an offer.

[splitbrain]

I assume this is about the Lookup type. Question: what would you expect to happen when you assign a user and then later this user's status is assigned a status != current? Should your page continue to show the user assignment or should the user vanish from the assignment? (I'm not yet sure which behaviour is easier to implement)

[juliusverrel]

Thanks for asking.

The former, we'd like to keep track also of former members of the project.

Actually, we usually create new users or project via a bureaucracy form, so the easiest solution (avoiding the inconsistency you describe) might be to allow constraints in bureaucracy forms. For instance with similar syntax as filters in struct aggregations, with lines separated by ";":

Project creation form:

• struct_field "project.Responsible" "filterand: user.Status=current; filterand: user.Role=Researcher"
• struct_field "project.Students" "filterand: user.Status=current; filterand: user.Role ~ Stud*"

User creation form:

• struct_field "user.Projects" "filterand: project.Status = active; filteror: project.Status = inprep"

The latter is hypothetical in our case, we link projects to users, not vice versa. For our current use case it would be fine to just have "and" combination of filters, but if you are implementing it anyway, allowing "or" probably makes sense.

From my very basic understanding of the code, the implementation could largely rely on splitting the constraint into separate lines, applying the search config parser, and then adding that filter somewhere around here.

[splitbrain]

Hmm, so you're suggesting to implement the filters for the Bureaucracy integration only? That would mean there's no filtering when editing the data via struct methods.

I don't think I like to have diverging behaviour for field editing in different contexts. I was thinking to add the filters to the field's configuration, which should ensure that they are honored at all places the field's data is edited.

Though this would also mean that wherever the field is edited, the same filter is applied. Your approach would allow to use different bureaucracy forms to fill the same schema using differently filtered fields. I can imagine a use case for that, too.

[juliusverrel]

You are right, both make sense for different use cases (even in within our wiki). I need to think about it...