no enable/disable user provisioning API endpoint

[individual-it]

just to track it in the tests

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 10 days if no further activity occurs. Thank you for your contributions.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 10 days if no further activity occurs. Thank you for your contributions.

[wkloucek]

@individual-it @phil-davis Could you please have a look at

• apiProvisioning-v1/disableUser.feature:257 (https://github.com/owncloud/core/blob/633eef7c5794f5d5b872a6ee09d194873615f429/tests/acceptance/features/apiProvisioning-v1/disableUser.feature#L247-L257)
• apiProvisioning-v2/disableUser.feature:254 (https://github.com/owncloud/core/blob/633eef7c5794f5d5b872a6ee09d194873615f429/tests/acceptance/features/apiProvisioning-v2/disableUser.feature#L244-L254)

How can they pass, if we don't have the enable / disable user provisioning API endpoint?

Context: we had a PR with some changes which triggered these two tests to fail and therefore I looked at them.

[phil-davis]

Note:
apiProvisioning-v1/disableUser.feature:256 and
apiProvisioning-v2/disableUser.feature:253
are already in expected-failures. Those test with the "old" dav_version of the public WebDAV API

apiProvisioning-v1/disableUser.feature:257 and
apiProvisioning-v2/disableUser.feature:254
are the examples for "new" dav_version of the public WebDAV API

I will look at why they were passing previously...

[phil-davis]

The test happens to be in pipeline Core-API-Tests-ocis-storage-2
Example: https://drone.owncloud.com/owncloud/ocis/7950/23/6

  Scenario Outline: getting public link share shared by disabled user using the new public WebDAV API                                                                                                            # /srv/app/testrunner/tests/acceptance/features/apiProvisioning-v1/disableUser.feature:247
    Given user "Alice" has been created with default attributes and small skeleton files                                                                                                                         # FeatureContext::userHasBeenCreatedWithDefaultAttributes()
    And user "Alice" has created a public link share with settings                                                                                                                                               # FeatureContext::userHasCreatedAPublicLinkShareWithSettings()
      | path        | /textfile0.txt |
      | permissions | read           |
    When the administrator disables user "Alice" using the provisioning API                                                                                                                                      # FeatureContext::adminDisablesUserUsingTheProvisioningApi()
    Then the public should be able to download the last publicly shared file using the <dav_version> public WebDAV API without a password and the content should be "ownCloud test text file 0" plus end-of-line # PublicWebDavContext::checkLastPublicSharedFileDownloadPlusEndOfLine()

    Examples:
      | dav_version |
      | old         |
        The downloaded content was expected to be 'ownCloud test text file 0
        ', but actually is ''. HTTP status was 401
        Failed asserting that two strings are equal.
        --- Expected
        +++ Actual
        @@ @@
        -'ownCloud test text file 0\n
        -'
        +''
      | new         |

[wkloucek]

But how can When the administrator disables user "Alice" using the provisioning API succeed, if this API doesn't exist?

[phil-davis]

But how can When the administrator disables user "Alice" using the provisioning API succeed, if this API doesn't exist?

When steps are only coded to fail if some exception happens with the test code (the network to the system-under-test goes down or...)

A test is supposed to check the evidence about whether the When step operated correctly by using Then steps. Often we have When steps that attempt to do something (download a file), and actually the When step code cannot/does not know if the API call is expected to succeed or not. The When step code saves the response (status, body etc) and Then steps should assert things about it, and things about other observable behavior of the system.

In this case the test is a "negative" test. On oC10, when a user is disabled, any public shares made by the user still work. (Whether that should be the case or not is a product requirement decision - but that is what happens now). So the test is confirming that if the user is disabled, then "nothing happens" to the public shares.

The test scenario should really have more Then steps that check some basic stuff about the When step, like:
Then the HTTP status should be xxx
Then the user should be disabled

That will make it fail earlier, when it discovers that the "disable" API call failed.

The difference in failure at the moment is some artifact of which old and new public WebDAV API are working.

I will adjust core tests (and have a look at other core tests that do not have enough Then checks)

[phil-davis]

See owncloud/core#39512 for details of refactoring of tests - that is a separate issue to this one.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 10 days if no further activity occurs. Thank you for your contributions.

[wkloucek]

@phil-davis can we close this, since owncloud/core#39612 is merged?

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 10 days if no further activity occurs. Thank you for your contributions.

[phil-davis]

@phil-davis can we close this, since owncloud/core#39612 is merged?

The enable/disable user tests still fails. I guess that the feature has not yet been implemented?

[SwikritiT]

Now we do user-related operations through graph api is this issue relevant now?

cc @phil-davis @individual-it

[individual-it]

I would suggest to make sure no tests in ocis rely on enable/disable users by the provisioning API and delete all tests that try to test those things (if any)

@micbar do you agree?

[micbar]

We can enable/disable users via graph now.

IMO there is just a config missing in the default product.

[rhafer]

IMO there is just a config missing in the default product.

It should work with the default configuration (just checked that).

@individual-it @SwikritiT Which exact test is this failing?

[SwikritiT]

@individual-it @SwikritiT Which exact test is this failing?

No tests are failing as per my knowledge, we also don't have this issue linked to the expected-to-fail file. But still, sometimes tests get linked to some other issues. This issue specifically is for ocs provisioning API but as we are using graph API for this operation we can close this issue. But like @individual-it mentioned we need to check that there aren't any tests that rely on provisioning API to do this and remove them if there are.

[rhafer]

Enable/Disable users is implemented in the graph API. And AFAIK all tests are now using that.