Merge pull request #495 from owncloud/user-create-ldap

Migrate ldap connection and configurations from user_ldap tests to core tests

Author: phil-davis

composer.json

@@ -5,8 +5,7 @@
         }
     },
     "require-dev": {
-        "bamarni/composer-bin-plugin": "^1.2",
-        "zendframework/zend-ldap": "^2.8"
+        "bamarni/composer-bin-plugin": "^1.2"
     },
     "require": {
         "php": ">=7.0.8",

tests/acceptance/config/behat.yml

@@ -32,7 +32,8 @@ default:
           ldapAdminPassword: admin
           ldapUsersOU: TestUsers
           ldapGroupsOU: TestGroups
-          ldapInitialUserFilePath: /../../config/ldap-users.ldif
+          ldapInitialUserFilePath: /../../../../tests/acceptance/config/ldap-users.ldif
+
       contexts: &common_webui_core_contexts
         - UserLdapGeneralContext:
         - FeatureContext: &common_feature_context_params
@@ -43,6 +44,7 @@ default:
             regularUserPassword: 123456
         - EmailContext:
         - FederationContext:
+        - OccContext:
         - WebUIAdminSharingSettingsContext:
         - WebUIFilesContext:
         - WebUIGeneralContext:

tests/acceptance/features/apiProvisioningLDAP/groups.feature

@@ -63,6 +63,7 @@ Feature: manage groups
 
   Scenario Outline: Administrator tries to delete a ldap group
     Given using OCS API version "<ocs-api-version>"
+    And group "grp1" has been created
     When the LDAP users are resynced
     And the administrator deletes group "grp1" using the provisioning API
     Then the OCS status code should be "<ocs-status-code>"
@@ -76,6 +77,7 @@ Feature: manage groups
   @issue-core-25224
   Scenario Outline: Add database user to ldap group
     Given using OCS API version "<ocs-api-version>"
+    And group "grp1" has been created
     And user "db-user" has been created with default attributes in the database user backend
     When the administrator adds user "db-user" to group "grp1" using the provisioning API
     Then the OCS status code should be "<ocs-status-code>"
@@ -91,6 +93,7 @@ Feature: manage groups
   Scenario Outline: Add ldap user to database group
     Given using OCS API version "<ocs-api-version>"
     And group "db-group" has been created in the database user backend
+    And user "user1" has been created with default attributes and without skeleton files
     When the administrator adds user "user1" to group "db-group" using the provisioning API
     Then the OCS status code should be "<ocs-status-code>"
     And the HTTP status code should be "<http-status-code>"
@@ -103,6 +106,8 @@ Feature: manage groups
   @issue-core-25224
   Scenario Outline: Add ldap user to ldap group
     Given using OCS API version "<ocs-api-version>"
+    And user "user1" has been created with default attributes and without skeleton files
+    And group "grp2" has been created
     When the administrator adds user "user1" to group "grp2" using the provisioning API
     Then the OCS status code should be "<ocs-status-code>"
     And the HTTP status code should be "<http-status-code>"
@@ -116,6 +121,10 @@ Feature: manage groups
 
   Scenario: Add ldap group with same name as existing database group
     Given group "db-group" has been created in the database user backend
+    And these users have been created with default attributes and without skeleton files:
+      | username |
+      | user1    |
+      | user2    |
     And user "user1" has been added to database backend group "db-group"
     When the administrator imports this ldif data:
       """
@@ -133,12 +142,21 @@ Feature: manage groups
     But user "user1" should belong to group "db-group"
 
   Scenario: creating a group in an OU that is different to the other groups
+    Given user "user3" has been created with default attributes and without skeleton files
     When the administrator creates group "new-group-in-other-ou" in ldap OU "TestUsers"
     And the administrator adds user "user3" to group "new-group-in-other-ou" in ldap OU "TestUsers"
     And the administrator invokes occ command "group:list"
     Then user "user3" should belong to group "new-group-in-other-ou"
 
   Scenario: creating a group with a name that already exists in LDAP but in a other OU
+    Given these users have been created with default attributes and without skeleton files:
+      | username |
+      | user2    |
+      | user3    |
+    And these groups have been created:
+      | groupname     |
+      | grp1          |
+    And user "user2" has been added to group "grp1"
     When the administrator creates group "grp1" in ldap OU "TestUsers"
     And the administrator adds user "user3" to group "grp1" in ldap OU "TestUsers"
     And the administrator invokes occ command "group:list"
@@ -147,6 +165,10 @@ Feature: manage groups
     And group "grp1_2" should not exist
 
   Scenario: creating two groups with the same name in different LDAP OUs at the same time
+    Given these users have been created with default attributes and without skeleton files:
+      | username |
+      | user1    |
+      | user2    |
     When the administrator imports this ldif data:
       """
       dn: cn=so-far-unused-group-name,ou=TestUsers,dc=owncloud,dc=com
@@ -170,6 +192,7 @@ Feature: manage groups
 
   Scenario Outline: Add database group with same name as existing ldap group
     Given using OCS API version "<ocs-api-version>"
+    And group "grp1" has been created
     When the administrator sends a group creation request for group "grp1" using the provisioning API
     Then the OCS status code should be "<ocs-status-code>"
     And the HTTP status code should be "<http-status-code>"

tests/acceptance/features/apiProvisioningLDAP/users.feature

@@ -80,6 +80,7 @@ Feature: Manage users using the Provisioning API
   @issue-core-33186
   Scenario Outline: admin tries to modify displayname of user for which an LDAP attribute is specified
     Given using OCS API version "<ocs-api-version>"
+    And user "user1" has been created with default attributes and without skeleton files
     When the administrator sets the ldap attribute "displayname" of the entry "uid=user1,ou=TestUsers" to "ldap user"
     And the LDAP users are resynced
     When the administrator changes the display of user "user1" to "A New User" using the provisioning API
@@ -96,6 +97,7 @@ Feature: Manage users using the Provisioning API
   @issue-core-33186
   Scenario Outline: admin tries to modify password of user for which an LDAP attribute is specified
     Given using OCS API version "<ocs-api-version>"
+    And user "user1" has been created with default attributes and skeleton files
     When the administrator sets the ldap attribute "userpassword" of the entry "uid=user1,ou=TestUsers" to "ldap_password"
     And the LDAP users are resynced
     And the administrator resets the password of user "user1" to "api_password" using the provisioning API
@@ -113,6 +115,7 @@ Feature: Manage users using the Provisioning API
   @issue-core-33186
   Scenario Outline: admin tries to modify mail of user for which an LDAP attribute is specified
     Given using OCS API version "<ocs-api-version>"
+    And user "user1" has been created with default attributes and without skeleton files
     When the administrator sets the ldap attribute "mail" of the entry "uid=user1,ou=TestUsers" to "[email protected]"
     And the LDAP users are resynced
     And the administrator changes the email of user "user1" to "[email protected]" using the provisioning API
@@ -132,6 +135,7 @@ Feature: Manage users using the Provisioning API
   @issue-core-33186
   Scenario Outline: admin tries to modify quota of user for which an LDAP attribute is specified
     Given using OCS API version "<ocs-api-version>"
+    And user "user1" has been created with default attributes and without skeleton files
     #to set Quota we can just misuse any LDAP text field
     And LDAP config "LDAPTestId" has key "ldapQuotaAttribute" set to "employeeNumber"
     When the administrator sets the ldap attribute "employeeNumber" of the entry "uid=user1,ou=TestUsers" to "10 MB"
@@ -152,6 +156,7 @@ Feature: Manage users using the Provisioning API
 
   Scenario Outline: admin sets quota of user for which no LDAP quota attribute is specified
     Given using OCS API version "<ocs-api-version>"
+    And user "user1" has been created with default attributes and without skeleton files
     #to set Quota we can just misuse any LDAP text field
     And LDAP config "LDAPTestId" has key "ldapQuotaAttribute" set to "employeeNumber"
     And the LDAP users have been resynced
@@ -169,6 +174,7 @@ Feature: Manage users using the Provisioning API
   @issue-core-33186
   Scenario Outline: admin sets quota of user for which no LDAP quota attribute is specified but a default quota is set in the LDAP settings
     Given using OCS API version "<ocs-api-version>"
+    And user "user1" has been created with default attributes and without skeleton files
     #to set Quota we can just misuse any LDAP text field
     And LDAP config "LDAPTestId" has key "ldapQuotaAttribute" set to "employeeNumber"
     And LDAP config "LDAPTestId" has key "ldapQuotaDefault" set to "10MB"
@@ -189,6 +195,7 @@ Feature: Manage users using the Provisioning API
 
   Scenario Outline: admin sets quota of user in LDAP when a default quota is set in the LDAP settings
     Given using OCS API version "<ocs-api-version>"
+    And user "user1" has been created with default attributes and without skeleton files
     #to set Quota we can just misuse any LDAP text field
     And LDAP config "LDAPTestId" has key "ldapQuotaAttribute" set to "employeeNumber"
     And LDAP config "LDAPTestId" has key "ldapQuotaDefault" set to "10MB"
@@ -205,6 +212,7 @@ Feature: Manage users using the Provisioning API
   @issue-core-33186
   Scenario Outline: admin sets quota of user when the quota LDAP attribute is specified and a default quota is set in the LDAP settings
     Given using OCS API version "<ocs-api-version>"
+    And user "user1" has been created with default attributes and without skeleton files
     #to set Quota we can just misuse any LDAP text field
     And LDAP config "LDAPTestId" has key "ldapQuotaAttribute" set to "employeeNumber"
     And LDAP config "LDAPTestId" has key "ldapQuotaDefault" set to "10MB"
@@ -226,6 +234,7 @@ Feature: Manage users using the Provisioning API
 
   Scenario Outline: Administrator deletes a ldap user and resyncs again
     Given using OCS API version "<ocs-api-version>"
+    And user "user0" has been created with default attributes and without skeleton files
     And user "user0" has uploaded file with content "new file that should be overwritten after user deletion" to "textfile0.txt"
     When the administrator deletes user "user0" using the provisioning API
     Then the OCS status code should be "<ocs-status-code>"
@@ -241,6 +250,7 @@ Feature: Manage users using the Provisioning API
 
   Scenario Outline: Administrator tries to create a user with same name as existing ldap user
     Given using OCS API version "<ocs-api-version>"
+    And user "user0" has been created with default attributes and skeleton files
     When the administrator sends a user creation request for user "user0" password "%alt1%" using the provisioning API
     Then the OCS status code should be "<ocs-status-code>"
     And the HTTP status code should be "<http-status-code>"

tests/acceptance/features/apiUserLDAP/moveUser.feature

@@ -5,6 +5,7 @@ Feature: move users between OUs
     Given the owncloud log level has been set to "info"
     And the owncloud log backend has been set to "owncloud"
     And the owncloud log has been cleared
+    And user "user0" has been created with default attributes and without skeleton files
     And user "user0" has uploaded file with content "new file that should still exist" to "textfile_new.txt"
     When the administrator deletes the ldap entry "uid=user0,ou=TestUsers"
     And the administrator imports this ldif data:

tests/acceptance/features/apiUserLDAPConnection/backupServerConnection.feature

@@ -8,6 +8,7 @@ So that user authentication still works when the main LDAP server is not reachab
   Background:
     Given the owncloud log level has been set to "warning"
     And the owncloud log has been cleared
+    And user "user0" has been created with default attributes and skeleton files
 
   Scenario: authentication works when the main server is not reachable but the backup server is
     Given LDAP config "LDAPTestId" has key "ldapHost" set to "not-existent"

tests/acceptance/features/apiUserLDAPConnection/groupFilter.feature

@@ -4,7 +4,18 @@ Feature: filter groups
   I want to be able to filter LDAP groups
   So that only groups meeting specific criteria are available in ownCloud
 
-    Scenario: single group filter
+  Background:
+    Given these groups have been created:
+      | groupname    |
+      | grp1         |
+      | grp2         |
+      | group1       |
+      | group2       |
+      | ShareeGroup  |
+      | ShareeGroup2 |
+
+
+  Scenario: single group filter
     When the administrator sets these settings of LDAP config "LDAPTestId" using the occ command
       | key             | value                                        |
       | ldapGroupFilter | (&(\|(objectclass=posixGroup))(\|(cn=grp2))) |
@@ -15,7 +26,7 @@ Feature: filter groups
       | admin   |
       | grp2    |
 
-    Scenario: filter with asterisk 
+  Scenario: filter with asterisk
     When the administrator sets these settings of LDAP config "LDAPTestId" using the occ command
       | key             | value                                           |
       | ldapGroupFilter | (&(\|(objectclass=posixGroup))(\|(cn=Sharee*))) |
@@ -27,7 +38,7 @@ Feature: filter groups
       | ShareeGroup  |
       | ShareeGroup2 |
 
-    Scenario: filter for multiple groups
+  Scenario: filter for multiple groups
     When the administrator sets these settings of LDAP config "LDAPTestId" using the occ command
       | key             | value                                                     |
       | ldapGroupFilter | (&(\|(objectclass=posixGroup))(\|(cn=group1)(cn=group2))) |
@@ -57,4 +68,3 @@ Feature: filter groups
         | group  |
         | admin  |
         | grp1   |
-

tests/acceptance/features/apiUserLDAPConnection/serverConnection.feature

@@ -4,6 +4,7 @@ Feature: connect to LDAP serer
   Background:
     Given the owncloud log level has been set to "warning"
     And the owncloud log has been cleared
+    And user "user0" has been created with default attributes and skeleton files
 
   Scenario: authentication fails when the configuration does not contain an ldap port
     Given LDAP config "LDAPTestId" has key "ldapPort" set to ""

tests/acceptance/features/apiUserLDAPSharing/sharingLocalUserLdapUser.feature

@@ -5,12 +5,14 @@ Feature: Sharing between local and LDAP users
 
   Background:
     Given user "local-user" has been created with default attributes in the database user backend
-    And these users have been initialized:
-    #these are LDAP users and are not initialized yet
+    And these users have been created with default attributes and skeleton files:
       | username |
       | user0    |
       | user1    |
       | user2    |
+    And group "grp1" has been created
+    And user "user1" has been added to group "grp1"
+    And user "user2" has been added to group "grp1"
 
   Scenario: Share a folder from an LDAP user to a local user
     When user "user0" shares folder "/PARENT" with user "local-user" using the sharing API