Searching sharee with displayname #547

jesmrec · 2020-09-10T13:13:27Z

Only posible to get sharees by using the username:

Username: einstein
Display Name: Albert Einstein

results are fetched only matching einstein
Albert, Einstein, Ein, Albe do not match and response is empty (always forgetting the case sensitiveness)

oC10: matches with both.

Backend: EOS storage via via https://github.com/owncloud-docker/compose-playground/blob/master/examples/hetzner-deploy/make_ocis_eos_compose_test.sh
Version: v1.0.0-rc1
Client: iOS App v11.4 over iOS13

CC @pmaier1

The text was updated successfully, but these errors were encountered:

refs · 2021-01-13T10:25:42Z

I added the EOS storage tag but most likely is related with the Reva userprovider.

micbar · 2022-07-14T09:41:57Z

re tested:

Created User

Username: hans
Display Name: Peter Dampf
E-Mail: [email protected]

We can find:

hans
Peter
pd@

We cannot find:

Hans (should not be case sensitive)
ans(middle of the username)
Dampf (End of the string Displayname)
example.com (End of the email address)

Expectation

at least
Hans (username search should not be case sensitive)
Dampf (End or middle of the string Displayname)

Should work.

rhafer · 2022-07-14T12:56:00Z

Expectation

at least
Hans (username search should not be case sensitive)

This is caused by a bug in idm. Fix is on its way.

Dampf (End or middle of the string Displayname)

This is currently not working "on purpose". At some point we agreed on limiting search to prefix searches. As doing full substring searches will get pretty expensive easily. We can of course change that (just need to adjust the filter https://github.com/cs3org/reva/blob/75f2c2f836578f8280749569f7f01a3e7d2b5939/pkg/utils/ldap/identity.go#L480).

@micbar If you still want it. Should we maybe make that configurable?

rhafer · 2022-07-14T13:05:34Z

Hans (username search should not be case sensitive)

This part should be fixed with libregraph/idm#75

micbar · 2022-07-14T13:12:04Z

@micbar If you still want it. Should we maybe make that configurable?

That would be awesome, same for the character length.

rhafer · 2022-07-19T07:42:12Z

same for the character length.

@micbar The API does not enforce any limit on the minimum (or maximum) length of the search phrase. Can you elaborate on what you are referring to?

micbar · 2022-07-19T07:44:06Z

Currently the system starts searching for users after you enter 3 characters. This is fine as a default.

Some use cases and the test suite would like to use at least 2 chars to start the user enumeration. I would like to have that configurable. Is that possible?

phil-davis · 2022-07-19T07:51:33Z

For example, oC10 has:

'user.search_min_length' => 2,

So the default on oC10 is to start searching for matches after 2 characters are typed in.

For test scenarios, it will be easier if we can get oCIS to start with this set to 2 characters (either change the oCIS default from 3 to 2, or have a way that we can configure that when we start oCIS in CI - I don't really care)

There are some scenarios that change the setting on-the-fly and check that different values work. Tht is out-of-scope for oCIS at the moment - we don't have a general way to modify system-wide settings on-the-fly in oCIS, so those sort of test scenarios will have to be re-engineered anyway if there comes a time when we actually want to test such things.

pmaier1 · 2022-07-19T08:57:48Z

Configurable would be great, default like oC10 (2).

This includes a fix for case-insensitive substring filtering Partial-Fix: owncloud#547

This introduces new settings for the users and groups services. "group_substring_filter_type" for the group services and "user_substring_filter_type" for the users service. They allow to set the type of LDAP filter that is used for substring user searches. Possible values are: "initial", "final" and "any" to do either prefix, suffix or full substring searches. Fixes owncloud#547

This adds the "search_min_length" setting to the frontend service which allows to set the search_min_length capabilty which is e.g. used by web. Partial: owncloud#547

This includes a fix for case-insensitive substring filtering Partial-Fix: owncloud#547

This introduces new settings for the users and groups services. "group_substring_filter_type" for the group services and "user_substring_filter_type" for the users service. They allow to set the type of LDAP filter that is used for substring user searches. Possible values are: "initial", "final" and "any" to do either prefix, suffix or full substring searches. Fixes owncloud#547

This adds the "search_min_length" setting to the frontend service which allows to set the search_min_length capabilty which is e.g. used by web. Partial: owncloud#547

This includes a fix for case-insensitive substring filtering Partial-Fix: #547

This introduces new settings for the users and groups services. "group_substring_filter_type" for the group services and "user_substring_filter_type" for the users service. They allow to set the type of LDAP filter that is used for substring user searches. Possible values are: "initial", "final" and "any" to do either prefix, suffix or full substring searches. Fixes #547

This adds the "search_min_length" setting to the frontend service which allows to set the search_min_length capabilty which is e.g. used by web. Partial: #547

SagarGi · 2022-07-21T04:15:39Z

This PR got merged #4229 fixing this issue and needs a follow-up for the expected to fail.

ocis/tests/acceptance/expected-failures-API-on-OCIS-storage.md

Lines 409 to 421 in 176dd32

    
           #### [Searching sharee with displayname](https://github.com/owncloud/ocis/issues/547) 
        
           - [apiSharees/sharees.feature:350](https://github.com/owncloud/core/blob/master/tests/acceptance/features/apiSharees/sharees.feature#L350) 
        
           - [apiSharees/sharees.feature:351](https://github.com/owncloud/core/blob/master/tests/acceptance/features/apiSharees/sharees.feature#L351) 
        
           - [apiSharees/sharees.feature:370](https://github.com/owncloud/core/blob/master/tests/acceptance/features/apiSharees/sharees.feature#L370) 
        
           - [apiSharees/sharees.feature:371](https://github.com/owncloud/core/blob/master/tests/acceptance/features/apiSharees/sharees.feature#L371) 
        
           - [apiSharees/sharees.feature:390](https://github.com/owncloud/core/blob/master/tests/acceptance/features/apiSharees/sharees.feature#L390) 
        
           - [apiSharees/sharees.feature:391](https://github.com/owncloud/core/blob/master/tests/acceptance/features/apiSharees/sharees.feature#L391) 
        
           - [apiSharees/sharees.feature:410](https://github.com/owncloud/core/blob/master/tests/acceptance/features/apiSharees/sharees.feature#L410) 
        
           - [apiSharees/sharees.feature:411](https://github.com/owncloud/core/blob/master/tests/acceptance/features/apiSharees/sharees.feature#L411) 
        
           - [apiSharees/sharees.feature:430](https://github.com/owncloud/core/blob/master/tests/acceptance/features/apiSharees/sharees.feature#L430) 
        
           - [apiSharees/sharees.feature:431](https://github.com/owncloud/core/blob/master/tests/acceptance/features/apiSharees/sharees.feature#L431)

TODO QA-team

review tests linked to this issue
remove them from expected to fail if they pass or create another issue if necessary -> new issue created here ocs sharing api always returns an empty exact list while searching for a sharee #4265

SwikritiT · 2022-07-21T08:39:27Z

The tests are failing because they search for the exact match for a searched string but this field is always empty for OCIS

<exact>
      <users/>
      <groups/>
      <remotes/>
    </exact>

For instance if I create a multiple variations of user einstein in OC10 and search it with curl

curl -vk -uadmin:admin http://localhost/core/ocs/v1.php/apps/files_sharing/api/v1/sharees\?search\=einstein\&itemType\=file -H"OCS-APIREQUEST:1" | xmllint --format -

It responds with

<?xml version="1.0"?>
<ocs>
  <meta>
    <status>ok</status>
    <statuscode>100</statuscode>
    <message>OK</message>
    <totalitems/>
    <itemsperpage/>
  </meta>
  <data>
    <exact>
      <users>
        <element>
          <label>einstein</label>
          <value>
            <shareType>0</shareType>
            <shareWith>einstein</shareWith>
            <userType>0</userType>
          </value>
        </element>
      </users>
      <groups/>
      <remotes/>
    </exact>
    <users>
      <element>
        <label>Albert Einstein</label>
        <value>
          <shareType>0</shareType>
          <shareWith>Albert Einstein</shareWith>
          <userType>0</userType>
        </value>
      </element>
      <element>
        <label>einstein-einstein</label>
        <value>
          <shareType>0</shareType>
          <shareWith>einstein-einstein</shareWith>
          <userType>0</userType>
        </value>
      </element>
      <element>
        <label>einstein1</label>
        <value>
          <shareType>0</shareType>
          <shareWith>einstein1</shareWith>
          <userType>0</userType>
        </value>
      </element>
    </users>
    <groups/>
    <remotes/>
  </data>
</ocs>

Inside <exact><users> there's exact match of the string

But in the case of OCIS if i do the same

curl -vk -uadmin:admin https://host.docker.internal:9200/ocs/v1.php/apps/files_sharing/api/v1/sharees\?search\=einstein\&itemType\=file -H"OCS-APIREQUEST:1" | xmllint --format -

<?xml version="1.0" encoding="UTF-8"?>
<ocs>
  <meta>
    <status>ok</status>
    <statuscode>100</statuscode>
    <message>OK</message>
  </meta>
  <data>
    <exact>
      <users/>
      <groups/>
      <remotes/>
    </exact>
    <users>
      <element>
        <label>Albert Einstein</label>
        <value>
          <shareType>0</shareType>
          <shareWith>einstein</shareWith>
          <shareWithAdditionalInfo>[email protected]</shareWithAdditionalInfo>
        </value>
      </element>
      <element>
        <label>Einstein Albert</label>
        <value>
          <shareType>0</shareType>
          <shareWith>einstein-einstein</shareWith>
          <shareWithAdditionalInfo>[email protected]</shareWithAdditionalInfo>
        </value>
      </element>
      <element>
        <label>Einstein</label>
        <value>
          <shareType>0</shareType>
          <shareWith>einstein1</shareWith>
          <shareWithAdditionalInfo>[email protected]</shareWithAdditionalInfo>
        </value>
      </element>
    </users>
    <groups/>
    <remotes/>
  </data>
</ocs>

The exact match is rather given in <users>

curl -vk -uadmin:admin https://host.docker.internal:9200/ocs/v1.php/apps/files_sharing/api/v1/sharees\?search\=einstein-einstein\&itemType\=file -H"OCS-APIREQUEST:1" | xmllint --format -

<?xml version="1.0" encoding="UTF-8"?>
<ocs>
  <meta>
    <status>ok</status>
    <statuscode>100</statuscode>
    <message>OK</message>
  </meta>
  <data>
    <exact>
      <users/>
      <groups/>
      <remotes/>
    </exact>
    <users>
      <element>
        <label>Einstein Albert</label>
        <value>
          <shareType>0</shareType>
          <shareWith>einstein-einstein</shareWith>
          <shareWithAdditionalInfo>[email protected]</shareWithAdditionalInfo>
        </value>
      </element>
    </users>
    <groups/>
    <remotes/>
  </data>
</ocs>

The tests are looking inside exact and they don't find the expected value there.

Is this expected behaviour?

cc: @micbar @rhafer @phil-davis

rhafer · 2022-07-22T12:31:28Z

@SwikritiT thanks for looking into that. I think this deserves a separate issue though, would you mind creating a new one for this?

I think the original bug reported here (which was about broken substring and case-sensitiveness) was solved.

It seems the new issue is basically caused by an incomplete implementation of the ocs sharing api in ocis/reva. It always returns an empty exact list and stuffs all the results into the top level users list (https://github.com/cs3org/reva/blob/master/internal/http/services/owncloud/ocs/handlers/apps/sharing/sharees/sharees.go#L91)

SwikritiT · 2022-07-25T03:53:53Z

@SwikritiT thanks for looking into that. I think this deserves a separate issue though, would you mind creating a new one for this?

I think the original bug reported here (which was about broken substring and case-sensitiveness) was solved.

It seems the new issue is basically caused by an incomplete implementation of the ocs sharing api in ocis/reva. It always returns an empty exact list and stuffs all the results into the top level users list (https://github.com/cs3org/reva/blob/master/internal/http/services/owncloud/ocs/handlers/apps/sharing/sharees/sharees.go#L91)

Okay I'll create a separate issue and close this one

SwikritiT · 2022-07-25T04:25:04Z

@rhafer new issue created here #4265

SwikritiT · 2022-07-25T04:26:14Z

This PR got merged #4229 fixing this issue and needs a follow-up for the expected to fail.

ocis/tests/acceptance/expected-failures-API-on-OCIS-storage.md

Lines 409 to 421 in 176dd32

#### [Searching sharee with displayname](https://github.com/owncloud/ocis/issues/547)

- [apiSharees/sharees.feature:350](https://github.com/owncloud/core/blob/master/tests/acceptance/features/apiSharees/sharees.feature#L350)

- [apiSharees/sharees.feature:351](https://github.com/owncloud/core/blob/master/tests/acceptance/features/apiSharees/sharees.feature#L351)

- [apiSharees/sharees.feature:370](https://github.com/owncloud/core/blob/master/tests/acceptance/features/apiSharees/sharees.feature#L370)

- [apiSharees/sharees.feature:371](https://github.com/owncloud/core/blob/master/tests/acceptance/features/apiSharees/sharees.feature#L371)

- [apiSharees/sharees.feature:390](https://github.com/owncloud/core/blob/master/tests/acceptance/features/apiSharees/sharees.feature#L390)

- [apiSharees/sharees.feature:391](https://github.com/owncloud/core/blob/master/tests/acceptance/features/apiSharees/sharees.feature#L391)

- [apiSharees/sharees.feature:410](https://github.com/owncloud/core/blob/master/tests/acceptance/features/apiSharees/sharees.feature#L410)

- [apiSharees/sharees.feature:411](https://github.com/owncloud/core/blob/master/tests/acceptance/features/apiSharees/sharees.feature#L411)

- [apiSharees/sharees.feature:430](https://github.com/owncloud/core/blob/master/tests/acceptance/features/apiSharees/sharees.feature#L430)

- [apiSharees/sharees.feature:431](https://github.com/owncloud/core/blob/master/tests/acceptance/features/apiSharees/sharees.feature#L431)

TODO QA-team

review tests linked to this issue

remove them from expected to fail if they pass or create another issue if necessary -> new issue created here ocs sharing api always returns an empty exact list while searching for a sharee #4265

Closing this issue. I'll make a PR changing the issue link in expected to fail file

This includes a fix for case-insensitive substring filtering Partial-Fix: #547

This introduces new settings for the users and groups services. "group_substring_filter_type" for the group services and "user_substring_filter_type" for the users service. They allow to set the type of LDAP filter that is used for substring user searches. Possible values are: "initial", "final" and "any" to do either prefix, suffix or full substring searches. Fixes #547

This adds the "search_min_length" setting to the frontend service which allows to set the search_min_length capabilty which is e.g. used by web. Partial: #547

jesmrec added the bug label Sep 10, 2020

settings bot removed the bug label Jan 12, 2021

exalate-issue-sync bot added p3-medium Type:Bug labels Jan 12, 2021

refs added the Storage:EOS label Jan 13, 2021

settings bot removed the Storage:EOS label Jan 29, 2021

settings bot removed the p3-medium label Apr 7, 2021

ScharfViktor added the Storage:EOS label Sep 1, 2021

micbar added Priority:p2-high Escalation, on top of current planning, release blocker and removed Storage:EOS labels Jul 14, 2022

micbar added this to the 2.0.0 General Availability milestone Jul 14, 2022

rhafer mentioned this issue Jul 14, 2022

Searching for a user or group is case-sensitive #3534

Closed

rhafer self-assigned this Jul 14, 2022

rhafer added a commit to rhafer/ocis that referenced this issue Jul 19, 2022

Bump libregraph/idm to latest master

54d4197

This includes a fix for case-insensitive substring filtering Partial-Fix: owncloud#547

rhafer added a commit to rhafer/ocis that referenced this issue Jul 19, 2022

Bump libregraph/idm to latest master

43b085e

This includes a fix for case-insensitive substring filtering Partial-Fix: owncloud#547

rhafer closed this as completed in #4229 Jul 20, 2022

rhafer added a commit that referenced this issue Jul 20, 2022

Bump libregraph/idm to latest master

41cfd6c

This includes a fix for case-insensitive substring filtering Partial-Fix: #547

rhafer added a commit that referenced this issue Jul 20, 2022

Add config for setting search_min_length capability

288b76d

This adds the "search_min_length" setting to the frontend service which allows to set the search_min_length capabilty which is e.g. used by web. Partial: #547

SagarGi reopened this Jul 21, 2022

SagarGi unassigned rhafer Jul 21, 2022

SagarGi added QA:team and removed Type:Bug Priority:p2-high Escalation, on top of current planning, release blocker labels Jul 21, 2022

SwikritiT self-assigned this Jul 21, 2022

SwikritiT closed this as completed Jul 25, 2022

SwikritiT mentioned this issue Jul 25, 2022

ocs sharing api always returns an empty exact list while searching for a sharee #4265

Closed

dragonchaser pushed a commit that referenced this issue Jul 27, 2022

Bump libregraph/idm to latest master

6a15c8d

This includes a fix for case-insensitive substring filtering Partial-Fix: #547

dragonchaser pushed a commit that referenced this issue Jul 27, 2022

Add config for setting search_min_length capability

73113cb

This adds the "search_min_length" setting to the frontend service which allows to set the search_min_length capabilty which is e.g. used by web. Partial: #547

micbar mentioned this issue Aug 11, 2022

Release 2.0.0-beta.6 #4378

Closed

26 tasks

amrita-shrestha mentioned this issue Sep 27, 2022

Check closed issue Searching sharee with displayname still exist in expected-to-failure #4684

Closed

micbar moved this to Done in Infinite Scale Team Board Dec 16, 2022

micbar added this to Infinite Scale Team Board Dec 16, 2022

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Searching sharee with displayname #547

Searching sharee with displayname #547

jesmrec commented Sep 10, 2020 •

edited

Loading

refs commented Jan 13, 2021 •

edited

Loading

micbar commented Jul 14, 2022

rhafer commented Jul 14, 2022

Expectation

rhafer commented Jul 14, 2022 •

edited

Loading

micbar commented Jul 14, 2022

rhafer commented Jul 19, 2022

micbar commented Jul 19, 2022

phil-davis commented Jul 19, 2022

pmaier1 commented Jul 19, 2022 •

edited

Loading

SagarGi commented Jul 21, 2022 •

edited by SwikritiT

Loading

SwikritiT commented Jul 21, 2022 •

edited

Loading

rhafer commented Jul 22, 2022

SwikritiT commented Jul 25, 2022

SwikritiT commented Jul 25, 2022

SwikritiT commented Jul 25, 2022 •

edited

Loading

Searching sharee with displayname #547

Searching sharee with displayname #547

Comments

jesmrec commented Sep 10, 2020 • edited Loading

refs commented Jan 13, 2021 • edited Loading

micbar commented Jul 14, 2022

Expectation

rhafer commented Jul 14, 2022

Expectation

rhafer commented Jul 14, 2022 • edited Loading

micbar commented Jul 14, 2022

rhafer commented Jul 19, 2022

micbar commented Jul 19, 2022

phil-davis commented Jul 19, 2022

pmaier1 commented Jul 19, 2022 • edited Loading

SagarGi commented Jul 21, 2022 • edited by SwikritiT Loading

SwikritiT commented Jul 21, 2022 • edited Loading

rhafer commented Jul 22, 2022

SwikritiT commented Jul 25, 2022

SwikritiT commented Jul 25, 2022

SwikritiT commented Jul 25, 2022 • edited Loading

jesmrec commented Sep 10, 2020 •

edited

Loading

refs commented Jan 13, 2021 •

edited

Loading

rhafer commented Jul 14, 2022 •

edited

Loading

pmaier1 commented Jul 19, 2022 •

edited

Loading

SagarGi commented Jul 21, 2022 •

edited by SwikritiT

Loading

SwikritiT commented Jul 21, 2022 •

edited

Loading

SwikritiT commented Jul 25, 2022 •

edited

Loading