diff --git a/tests/acceptance/expected-failures-localAPI-on-OCIS-storage.md b/tests/acceptance/expected-failures-localAPI-on-OCIS-storage.md index 367a1cf8eef..b79f04bf33a 100644 --- a/tests/acceptance/expected-failures-localAPI-on-OCIS-storage.md +++ b/tests/acceptance/expected-failures-localAPI-on-OCIS-storage.md @@ -250,8 +250,8 @@ The expected failures in this file are from features in the owncloud/ocis repo. #### [OCM. federated connection is not dropped when one of the users deletes the connection](https://github.com/owncloud/ocis/issues/10216) -- [apiOcm/deleteFederatedConnections.feature:39](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/apiOcm/deleteFederatedConnections.feature#L39) -- [apiOcm/deleteFederatedConnections.feature:66](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/apiOcm/deleteFederatedConnections.feature#L66) +- [apiOcm/deleteFederatedConnections.feature:21](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/apiOcm/deleteFederatedConnections.feature#L21) +- [apiOcm/deleteFederatedConnections.feature:67](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/apiOcm/deleteFederatedConnections.feature#L67) #### [OCM. server crash after deleting share for ocm user](https://github.com/owncloud/ocis/issues/10213) diff --git a/tests/acceptance/features/apiOcm/acceptInvitation.feature b/tests/acceptance/features/apiOcm/acceptInvitation.feature index 315f23dd09a..41f2248e7b2 100755 --- a/tests/acceptance/features/apiOcm/acceptInvitation.feature +++ b/tests/acceptance/features/apiOcm/acceptInvitation.feature @@ -31,19 +31,17 @@ Feature: accepting invitation Scenario: two users can accept one invitation Given using server "LOCAL" And "Alice" has created the federation share invitation - When using server "REMOTE" - And "Brian" accepts the last federation share invitation + And using server "REMOTE" + And "Brian" has accepted invitation + When "Carol" accepts the last federation share invitation Then the HTTP status code should be "200" - And "Carol" accepts the last federation share invitation - And the HTTP status code should be "200" Scenario: user tries to accept the invitation twice Given using server "LOCAL" And "Alice" has created the federation share invitation - When using server "REMOTE" - And "Brian" accepts the last federation share invitation - Then the HTTP status code should be "200" + And using server "REMOTE" + And "Brian" has accepted invitation When "Brian" tries to accept the last federation share invitation Then the HTTP status code should be "409" And the JSON data of the response should match diff --git a/tests/acceptance/features/apiOcm/createInvitation.feature b/tests/acceptance/features/apiOcm/createInvitation.feature index dbc618a7f88..fcbcd00a2c5 100755 --- a/tests/acceptance/features/apiOcm/createInvitation.feature +++ b/tests/acceptance/features/apiOcm/createInvitation.feature @@ -31,33 +31,6 @@ Feature: create invitation } } """ - When "Alice" lists the created invitations - Then the HTTP status code should be "200" - And the JSON data of the response should match - """ - { - "type": "array", - "minItems": 1, - "maxItems": 1, - "items": { - "type": "object", - "required": [ - "expiration", - "token" - ], - "properties": { - "expiration": { - "type": "integer", - "pattern": "^[0-9]{10}$" - }, - "token": { - "type": "string", - "pattern": "%fed_invitation_token%" - } - } - } - } - """ @issue-9591 Scenario: user creates invitation with valid email and description @@ -88,37 +61,6 @@ Feature: create invitation } } """ - When "Alice" lists the created invitations - And the HTTP status code should be "200" - And the JSON data of the response should match - """ - { - "type": "array", - "minItems": 1, - "maxItems": 1, - "items": { - "type": "object", - "required": [ - "expiration", - "token", - "description" - ], - "properties": { - "expiration": { - "type": "integer", - "pattern": "^[0-9]{10}$" - }, - "token": { - "type": "string", - "pattern": "%fed_invitation_token%" - }, - "description": { - "const": "a share invitation from Alice" - } - } - } - } - """ Scenario Outline: user creates invitation with valid/invalid email @@ -155,28 +97,7 @@ Feature: create invitation Scenario: user cannot see expired invitation tokens Given using server "LOCAL" And the config "OCM_OCM_INVITE_MANAGER_TOKEN_EXPIRATION" has been set to "1s" - When "Alice" creates the federation share invitation - Then the HTTP status code should be "200" - And the JSON data of the response should match - """ - { - "type": "object", - "required": [ - "expiration", - "token" - ], - "properties": { - "expiration": { - "type": "integer", - "pattern": "^[0-9]{10}$" - }, - "token": { - "type": "string", - "pattern": "%fed_invitation_token%" - } - } - } - """ + And "Alice" has created the federation share invitation And the user waits "2" seconds for the token to expire When "Alice" lists the created invitations Then the HTTP status code should be "200" @@ -187,4 +108,4 @@ Feature: create invitation "minItems": 0, "maxItems": 0 } - """ \ No newline at end of file + """ diff --git a/tests/acceptance/features/apiOcm/deleteFederatedConnections.feature b/tests/acceptance/features/apiOcm/deleteFederatedConnections.feature index de6167afb3a..603aa3640ad 100755 --- a/tests/acceptance/features/apiOcm/deleteFederatedConnections.feature +++ b/tests/acceptance/features/apiOcm/deleteFederatedConnections.feature @@ -16,7 +16,16 @@ Feature: delete federated connections And "Brian" has accepted invitation When user "Brian" deletes federated connection with user "Alice" using the Graph API Then the HTTP status code should be "200" - When user "Brian" searches for federated user "alice" using Graph API + + @issue-10216 + Scenario: users should not be able to find federated user after deleting connection + Given using server "LOCAL" + And "Alice" has created the federation share invitation + And using server "REMOTE" + And "Brian" has accepted invitation + And user "Brian" has deleted federated connection with user "Alice" + And using server "LOCAL" + When user "Alice" searches for federated user "brian" using Graph API Then the HTTP status code should be "200" And the JSON data of the response should match """ @@ -34,16 +43,8 @@ Feature: delete federated connections } } """ - - @issue-10216 - Scenario: local user should not be able to find federated user after federated user has deleted connection - Given using server "LOCAL" - And "Alice" has created the federation share invitation And using server "REMOTE" - And "Brian" has accepted invitation - And user "Brian" has deleted federated connection with user "Alice" - And using server "LOCAL" - When user "Alice" searches for federated user "brian" using Graph API + When user "Brian" searches for federated user "Alice" using Graph API Then the HTTP status code should be "200" And the JSON data of the response should match """ @@ -77,8 +78,7 @@ Feature: delete federated connections | shareType | user | | permissionsRole | Viewer | And using server "REMOTE" - When user "Brian" deletes federated connection with user "Alice" using the Graph API - Then the HTTP status code should be "200" + And user "Brian" has deleted federated connection with user "Alice" When user "Brian" lists the shares shared with him without retry using the Graph API Then the HTTP status code should be "200" And the JSON data of the response should match @@ -112,8 +112,7 @@ Feature: delete federated connections | sharee | Brian | | shareType | user | | permissionsRole | Viewer | - When user "Alice" deletes federated connection with user "Brian" using the Graph API - Then the HTTP status code should be "200" + And user "Alice" has deleted federated connection with user "Brian" And using server "REMOTE" When user "Brian" lists the shares shared with him without retry using the Graph API Then the HTTP status code should be "200" diff --git a/tests/acceptance/features/apiOcm/share.feature b/tests/acceptance/features/apiOcm/share.feature index c7c55117348..8c96f49f9ef 100755 --- a/tests/acceptance/features/apiOcm/share.feature +++ b/tests/acceptance/features/apiOcm/share.feature @@ -24,8 +24,8 @@ Feature: an user shares resources using ScienceMesh application | shareType | user | | permissionsRole | Viewer | Then the HTTP status code should be "200" - When using server "REMOTE" - And user "Brian" lists the shares shared with him without retry using the Graph API + And using server "REMOTE" + When user "Brian" lists the shares shared with him without retry using the Graph API Then the HTTP status code should be "200" And the JSON data of the response should match """ @@ -117,8 +117,8 @@ Feature: an user shares resources using ScienceMesh application | shareType | user | | permissionsRole | Viewer | Then the HTTP status code should be "200" - When using server "REMOTE" - And user "Brian" lists the shares shared with him without retry using the Graph API + And using server "REMOTE" + When user "Brian" lists the shares shared with him without retry using the Graph API Then the HTTP status code should be "200" And the JSON data of the response should match """ @@ -189,8 +189,8 @@ Feature: an user shares resources using ScienceMesh application | shareType | user | | permissionsRole | Viewer | Then the HTTP status code should be "200" - When using server "LOCAL" - And user "Alice" lists the shares shared with her without retry using the Graph API + And using server "LOCAL" + When user "Alice" lists the shares shared with her without retry using the Graph API Then the HTTP status code should be "200" And the JSON data of the response should match """