Uploaded image for project: 'Crowd Data Center'
  1. Crowd Data Center
  2. CWD-3512

For Internal and Caching directories, when searching for memberships you should be able to apply a search restriction to the result

    • Icon: Suggestion Suggestion
    • Resolution: Fixed
    • 2.9.1
    • None
    • None
    • Our product teams collect and evaluate feedback from a number of different sources. To learn more about how we use customer feedback in the planning process, check out our new feature policy.

      An example of this search would be the following:

      MembershipQuery query = QueryBuilder.queryFor(String.class, group()).with(Restriction.on(GroupTermKeys.NAME).startingWith("jira-admin")).parentsOf(user()).withName(ADMIN_USER).startingAt(0).returningAtMost(10);
      
              MembershipQuery<User> userMembershipQuery = QueryBuilder.queryFor(User.class, EntityDescriptor.user())
                      .with(Restriction.on(UserTermKeys.NAME).startingWith("justin"))
                      .childrenOf(EntityDescriptor.group())
                      .withNames("crowd-administrators", "jira-administrators")
                      .startingAt(1)
                      .returningAtMost(31);
      

            [CWD-3512] For Internal and Caching directories, when searching for memberships you should be able to apply a search restriction to the result

            joe added a comment -

            The implementation is of option 2; using this when any directory is not backed by a local database will fail fast.

            joe added a comment - The implementation is of option 2; using this when any directory is not backed by a local database will fail fast.

            joe added a comment -

            This is reasonably easy to add for internal directories, and not necessarily easy to implement efficiently for other directories.

            Options:

            1. This doesn't match the existing model; simply WONTIX and require clients to filter the result themselves.
            2. Support this for internal directories, fail outright when this query hits any other type.
            3. Make the search restriction optional. An internal directory will filter, any other type may ignore the restriction.
            4. As above, but allow a client to test ahead of time if this would be supported.
            5. Implement this behaviour server-side. This may result in a very inefficient query for uncached LDAP, but clients would be protected from knowing that.

            joe added a comment - This is reasonably easy to add for internal directories, and not necessarily easy to implement efficiently for other directories. Options: This doesn't match the existing model; simply WONTIX and require clients to filter the result themselves. Support this for internal directories, fail outright when this query hits any other type. Make the search restriction optional. An internal directory will filter, any other type may ignore the restriction. As above, but allow a client to test ahead of time if this would be supported. Implement this behaviour server-side. This may result in a very inefficient query for uncached LDAP, but clients would be protected from knowing that.

              justin@atlassian.com Justin Koke
              justin@atlassian.com Justin Koke
              Votes:
              1 Vote for this issue
              Watchers:
              4 Start watching this issue

                Created:
                Updated:
                Resolved: