Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[tests-only] [full-ci] removed scenario related to federated share #6511

Merged
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
5 changes: 0 additions & 5 deletions tests/acceptance/expected-failures-API-on-OCIS-storage.md
Original file line number Diff line number Diff line change
Expand Up @@ -155,11 +155,6 @@ Synchronization features like etag propagation, setting mtime and locking files

File and sync features in a shared scenario

#### [federation share is not implement in ocis] (https://github.com/owncloud/ocis/issues/1329)

- [coreApiSharees/sharees.feature:180](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiSharees/sharees.feature#L180)
- [coreApiSharees/sharees.feature:181](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiSharees/sharees.feature#L181)

#### [accepting matching name shared resources from different users/groups sets no serial identifiers on the resource name for the receiver](https://github.com/owncloud/ocis/issues/4289)

- [coreApiShareManagementToShares/acceptShares.feature:238](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareManagementToShares/acceptShares.feature#L238)
Expand Down
39 changes: 0 additions & 39 deletions tests/acceptance/features/coreApiSharees/sharees.feature
Original file line number Diff line number Diff line change
Expand Up @@ -161,45 +161,6 @@ Feature: search sharees
| 2 | 200 | 200 |


Scenario Outline: federated sharee for files
Given using OCS API version "<ocs-api-version>"
When user "Alice" gets the sharees using the sharing API with parameters
| search | test@localhost |
| itemType | file |
Then the OCS status code should be "<ocs-status>"
And the HTTP status code should be "<http-status>"
And the "exact users" sharees returned should be empty
And the "users" sharees returned should be empty
And the "exact groups" sharees returned should be empty
And the "groups" sharees returned should be empty
And the "exact remotes" sharees returned should be
| test@localhost | 6 | test@localhost |
And the "remotes" sharees returned should be empty
Examples:
| ocs-api-version | ocs-status | http-status |
| 1 | 100 | 200 |
| 2 | 200 | 200 |
Comment on lines -164 to -181
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ScharfViktor Should we remove these scenarios related to federated share (federated share is not implemented in oCIS yet but will be in the future: #1329)?
IMO, these can be removed because these scenarios might not describe the federation share the way oCIS will implement it.

Copy link
Contributor

@ScharfViktor ScharfViktor Jun 16, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if these tests will not work in ocis when we implement federated share, please merge this PR
I left this test because I thought they would be able to work in ocis

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we can remove these. As we have a lot of tests in core regarding the federation that hasn't been transferred to ocis yet. When the feature will be implemented, we can copy and paste the implementation from core if the federate implementation in ocis works according to that. If the implementation in ocis will not work according to the implementation in core these scenarios aren't relevant anyway



Scenario Outline: federated sharee for calendars not allowed
Given using OCS API version "<ocs-api-version>"
When user "Alice" gets the sharees using the sharing API with parameters
| search | test@localhost |
| itemType | calendar |
Then the OCS status code should be "<ocs-status>"
And the HTTP status code should be "<http-status>"
And the "exact users" sharees returned should be empty
And the "users" sharees returned should be empty
And the "exact groups" sharees returned should be empty
And the "groups" sharees returned should be empty
And the "exact remotes" sharees returned should be empty
And the "remotes" sharees returned should be empty
Examples:
| ocs-api-version | ocs-status | http-status |
| 1 | 100 | 200 |
| 2 | 200 | 200 |


Scenario Outline: enumerate only group members - only show partial results from member of groups
Given using OCS API version "<ocs-api-version>"
And these users have been created with default attributes and without skeleton files:
Expand Down