Skipped oCIS tests for sharing jail

[kulmann]

In order to get the share jail PR merged I needed to skip some tests on oCIS. They all have in common that they do sharing related actions, then browser to the Shares folder via the personal page and do some checks there if files/folders exist or don't exist.
Since oCIS with share jail doesn't have the Shares folder in the personal view anymore, those checks don't work like that. Instead one could navigate into the respective share via shared with me page and check if that is successful (only for accepted shares). Other than that we can only rely on the share acceptance state in the shared with me page - which we already do.
One thought that went through my mind is: with the share jail we don't mount shares into the personal home anymore. Does it make sense to keep those tests at all? Because if we shorten them by the steps that check previously checked the mount point we only check state changes in the shared with me page. That could be covered with far less effort / fewer tests. And maybe even by only relying on unit tests. What do you think?

cc @individual-it @phil-davis

list of tests skipped on oCIS for sharing jail

• webUISharingAcceptShares/acceptShares.feature:127
• webUISharingAcceptShares/acceptShares.feature:145
• webUISharingAcceptShares/acceptShares.feature:212
• webUISharingAcceptShares/acceptShares.feature:245
• webUISharingInternalGroups/shareWithGroups.feature:100
• webUISharingInternalGroups/shareWithGroups.feature:138
• webUISharingInternalUsers/shareWithUsers.feature:77
• webUISharingInternalUsers/shareWithUsers.feature:108
• webUISharingInternalUsers/shareWithUsers.feature:126

[kulmann]

Note: for e2e tests for navigating into an accepted share, I'd rather write new e2e tests instead of new nightwatch acceptance tests. See #6895

[individual-it]

I think it really depends on what the test does.
The step When the user browses to the folder "Shares" on the files page in itself is not a check but an action (or part of the action) the user does to achieve something.
Looking through the tests I have different suggestions.

acceptShares.feature:

1. not to check if the share is shown in the file-list via webUI
2. add an API check to see if the share is in the correct state
3. check via API is the share is accessible

reasons:

1. this test is about checking if the accepting/denying works, so it should only test that, checking that an accepted share is shown in the filelist should be done in different tests
2. that way the tests would keep on working on oc10 and ocis
3. little change is needed

shareWithGroups.feature / shareWithUsers.feature

here we actually check if certain operations like upload, delete etc. work correctly in the webUI inside of a shared folder. For that we need to navigate into the folder. I can see two options

1. rewrite the the user opens folder "Shares" using the webUI to something like the user opens the share-jail and make it work on both oc10 and ocis
2. let the scenario skipped and create a journey it to the e2e tests that covers this cases. (still we would need a step there that is aware of if it runs on oc10 or ocis and does the right thing to navigate to the place where shares are accessible)

[SwikritiT]

List of skipped scenarios in #7246 :

• webUISharingInternalGroups/shareWithGroups.feature:32 (Scenario Outline: share a file & folder with another internal user)
• webUIResharing2/reshareUsers.feature:31 (Scenario: Reshare a folder without share permissions using API and check if it is listed on the collaborators list for resharer)
• webUIResharing2/reshareUsers.feature:45 (Scenario: Reshare a folder without share permissions using API and check if the receiver can reshare)
• webUIResharing2/reshareUsers.feature:57 ( Scenario Outline: share a received folder with another user with same permissions(including share permissions) and check if the user is displayed in collaborators list for resharer)
• webUIResharing2/reshareUsers.feature:84 (Scenario Outline: share a received folder with another user with same permissions(including share permissions) and check if the user is displayed in collaborators list for original owner)
• webUISharingInternalUsers/shareWithUsers.feature:18 (Scenario Outline: share a file & folder with another internal user)
• webUISharingInternalUsers/shareWithUsers.feature:246 (Scenario Outline: Share files/folders with special characters in their name)
• webUISharingPermissionsUsers/sharePermissionsUsers.feature:215 (Scenario: User is allowed to update permissions of a reshared sub-folder within the permissions that the user has received)
• webUIResharing1/reshareUsers.feature:20 (Scenario: share a folder with another user with share permissions and reshare without share permissions to different user, and check if user is displayed for original sharer)
• webUIResharing1/reshareUsers.feature:49 (Scenario: share a folder with another user with share permissions and reshare without share permissions to different user, and check if user is displayed for the receiver)

[individual-it]

@SwikritiT can we close this issue?

[SwikritiT]

list of all the tests skipped in Nightwatch shares jails included are listed here #7264