#47938 nsRole Based VLV Search Issue
Closed: wontfix 4 years ago by mreynolds. Opened 9 years ago by nhosoi.

If nsrole is used in a VLVFilter, no entry matches in the VLV index generation and the search fails to return the entry.

[Sample VLV index]
dn: cn=VLVS0,cn=userRoot,cn=ldbm database,cn=plugins,cn=config
objectClass: top
objectClass: vlvSearch
cn: VLVS0
vlvBase: ou=RolesTests,o=roles
vlvScope: 1
vlvFilter: (&(objectclass=*)(nsrole=cn=role definition A,ou=rolestests,o=roles))
numSubordinates: 1

dn: cn=VLVI0,cn=VLVS0,cn=userRoot,cn=ldbm database,cn=plugins,cn=config
objectClass: top
objectClass: vlvIndex
cn: VLVI0
vlvSort: cn givenname sn

Search without VLV request returns entries.

ldapsearch ... -b "ou=rolestests,o=roles" '(&(objectclass=*)(nsrole=cn=role definition b,ou=rolestests,o=roles))' dn
dn: uid=tuser0,ou=RolesTests,o=roles
...

But with VLV request, -s onelevel -E vlv=0/99/0/0 -E sss='cn givenname sn', it returns none.


This requires a new imlementation. Some email conversations...

thierry bordaz wrote:

I think that finding a virtual attribute in the filter we should rely on the other attributes in the filter. So vlv_search_build_candidate_list should do nothing (return no index) and let build_candidate_list do the jobs. It should build a valid candidate list like the customer said (when -E is not set in ldapsearch).
A problem is to check that the candidates are valid, this would be the job of vlv_filter_candidates to be virtual attribute aware.

To support it, we have to implement something like virtual-VLV index in memory (using recno in memory?) or we have to generate idlist every time VLV request with virtual attributes in the filter comes in and cut out the entries in the range of the VLV request and return the set. Or ...

Metadata Update from @nhosoi:
- Issue set to the milestone: FUTURE

7 years ago

Metadata Update from @mreynolds:
- Custom field reviewstatus adjusted to None
- Issue close_status updated to: wontfix
- Issue status updated to: Closed (was: Open)

4 years ago

389-ds-base is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in 389-ds-base's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/389ds/389-ds-base/issues/1269

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.

Login to comment on this ticket.

Metadata