Sharebar?

v1p2 filtering limitations on non-scalar fields

v1p2 filtering limitations on non-scalar fields

See here: https://www.imsglobal.org/sites/default/files/spec/oneroster/v1p2/roster...

From a practical perspective, I think the main limitation I notice versus v1p1 is that it is no longer possible to filter for a user in a particular role (formerly like: role='guardian'). Multiple roles are fine (more than fine, they are great), but there is no way to filter users among the increasing number of roles under the current scheme, as far as I can tell.

Maybe a compromise would be allow a convenience filter for the common use case rather than trying to support filtering on arrays of complex types. So if you wanted to grab users in the parent or guardian role you could do something like roleValues~'parent,guardian'; i.e. "roleValues" isn't an attribute proper, but we would have a convenient way of digging for what we need in "roles". Similar might be useful for selecting users from among certain orgs (a way to filter on roles[*].org), but I think the lack of basic role filtering from v1p1 is the greater drawback.

Aside:

Not to get too sidetracked, but from the link above the example of "preferredName" filtering seems misleading/wrong. None of the "preferred*Name" fields are arrays, but it is shows array filtering examples using ~, etc.

Agree with this sentiment on

Agree with this sentiment on limited filtering options. We have a use case to grab only school staff/employees and exclude students, parents, guardians, and relatives. Based on the spec, this would involve doing multiple logical operators, but the spec also recommends that implementations support only AND and OR, and only a single logical operator. The alternative is to make multiple requests (fetch teachers, fetch district admins, fetch site admins, etc).