<commit_before>@api @provisioning_api-app-required @skipOnLDAP
Feature: access user provisioning API using app password
  As an ownCloud user
  I want to be able to use the provisioning API with an app password
  So that I can make a client app or script for provisioning users/groups that can use an app password instead of my real password.

  Background:
    Given using OCS API version "2"

  @smokeTest @notToImplementOnOCIS
  Scenario: admin deletes the user
    Given user "brand-new-user" has been created with default attributes and without skeleton files
    And group "brand-new-group" has been created
    And a new client token for the administrator has been generated
    And a new browser session for the administrator has been started
    And the user has generated a new app password named "<PASSWORD>"
    When the user requests "/ocs/v2.php/cloud/users/brand-new-user" with "DELETE" using the generated app password
    Then the HTTP status code should be "200"
    And user "brand-new-user" should not exist

  @notToImplementOnOCIS
  Scenario: subadmin gets users in their group
    Given these users have been created with default attributes and without skeleton files:
      | username         |
      | brand-new-user   |
      | another-new-user |
    And group "brand-new-group" has been created
    And user "another-new-user" has been added to group "brand-new-group"
    And user "brand-new-user" has been made a subadmin of group "brand-new-group"
    And a new client token for "brand-new-user" has been generated
    And a new browser session for "brand-new-user" has been started
    And the user has generated a new app password named "<PASSWORD>"
    When the user requests "/ocs/v2.php/cloud/users" with "GET" using the generated app password
    Then the users returned by the API should be
      | another-new-user |
    And the HTTP status code should be "200"

  @smokeTest
  Scenario: normal user gets their own information using the app password
    Given these users have been created with default attributes and without skeleton files:
      | username       | displayname |
      | brand-new-user | New User    |
    And a new client token for "brand-new-user" has been generated
    And a new browser session for "brand-new-user" has been started
    And the user has generated a new app password named "<PASSWORD>"
    When the user requests "/ocs/v2.php/cloud/users/brand-new-user" with "GET" using the generated app password
    Then the HTTP status code should be "200"
    And the display name returned by the API should be "New User"

  @notToImplementOnOCIS
  Scenario: subadmin tries to get users of other group
    Given these users have been created with default attributes and without skeleton files:
      | username         |
      | brand-new-user   |
      | another-new-user |
    And group "brand-new-group" has been created
    And group "another-new-group" has been created
    And user "another-new-user" has been added to group "another-new-group"
    And user "brand-new-user" has been made a subadmin of group "brand-new-group"
    And a new client token for "brand-new-user" has been generated
    And a new browser session for "brand-new-user" has been started
    And the user has generated a new app password named "<PASSWORD>"
    When the user requests "/ocs/v2.php/cloud/users" with "GET" using the generated app password
    Then the users returned by the API should not include "another-new-user"
    And the HTTP status code should be "200"

  Scenario: normal user tries to get other user information using the app password
    Given these users have been created with default attributes and without skeleton files:
      | username         |
      | brand-new-user   |
      | another-new-user |
    And a new client token for "brand-new-user" has been generated
    And a new browser session for "brand-new-user" has been started
    And the user has generated a new app password named "<PASSWORD>"
    When the user requests "/ocs/v2.php/cloud/users/another-new-user" with "GET" using the generated app password
    Then the HTTP status code should be "401"
    And the API should not return any data

  Scenario: normal user gets his own resources using the app password
    Given these users have been created with small skeleton files:
      | username       | password  | displayname | email                    |
      | brand-new-user | %regular% | New user    | <EMAIL> |
    And a new browser session for "brand-new-user" has been started
    And the user has generated a new app password named "<PASSWORD>"
    When the user "brand-new-user" requests these endpoints with "PROPFIND" to get property "d:getetag" using basic auth and generated app password about user "brand-new-user"
      | endpoint                                       |
      | /remote.php/dav/files/%username%/textfile0.txt |
    Then the HTTP status code should be "207"
<commit_msg>added a @notToImplementOnOcis tag in apiProvisioningV2 suite<commit_after>@api @provisioning_api-app-required @skipOnLDAP
Feature: access user provisioning API using app password
  As an ownCloud user
  I want to be able to use the provisioning API with an app password
  So that I can make a client app or script for provisioning users/groups that can use an app password instead of my real password.

  Background:
    Given using OCS API version "2"

  @smokeTest @notToImplementOnOCIS
  Scenario: admin deletes the user
    Given user "brand-new-user" has been created with default attributes and without skeleton files
    And group "brand-new-group" has been created
    And a new client token for the administrator has been generated
    And a new browser session for the administrator has been started
    And the user has generated a new app password named "<PASSWORD>"
    When the user requests "/ocs/v2.php/cloud/users/brand-new-user" with "DELETE" using the generated app password
    Then the HTTP status code should be "200"
    And user "brand-new-user" should not exist

  @notToImplementOnOCIS
  Scenario: subadmin gets users in their group
    Given these users have been created with default attributes and without skeleton files:
      | username         |
      | brand-new-user   |
      | another-new-user |
    And group "brand-new-group" has been created
    And user "another-new-user" has been added to group "brand-new-group"
    And user "brand-new-user" has been made a subadmin of group "brand-new-group"
    And a new client token for "brand-new-user" has been generated
    And a new browser session for "brand-new-user" has been started
    And the user has generated a new app password named "<PASSWORD>"
    When the user requests "/ocs/v2.php/cloud/users" with "GET" using the generated app password
    Then the users returned by the API should be
      | another-new-user |
    And the HTTP status code should be "200"

  @smokeTest
  Scenario: normal user gets their own information using the app password
    Given these users have been created with default attributes and without skeleton files:
      | username       | displayname |
      | brand-new-user | New User    |
    And a new client token for "brand-new-user" has been generated
    And a new browser session for "brand-new-user" has been started
    And the user has generated a new app password named "<PASSWORD>"
    When the user requests "/ocs/v2.php/cloud/users/brand-new-user" with "GET" using the generated app password
    Then the HTTP status code should be "200"
    And the display name returned by the API should be "New User"

  @notToImplementOnOCIS
  Scenario: subadmin tries to get users of other group
    Given these users have been created with default attributes and without skeleton files:
      | username         |
      | brand-new-user   |
      | another-new-user |
    And group "brand-new-group" has been created
    And group "another-new-group" has been created
    And user "another-new-user" has been added to group "another-new-group"
    And user "brand-new-user" has been made a subadmin of group "brand-new-group"
    And a new client token for "brand-new-user" has been generated
    And a new browser session for "brand-new-user" has been started
    And the user has generated a new app password named "<PASSWORD>"
    When the user requests "/ocs/v2.php/cloud/users" with "GET" using the generated app password
    Then the users returned by the API should not include "another-new-user"
    And the HTTP status code should be "200"

  Scenario: normal user tries to get other user information using the app password
    Given these users have been created with default attributes and without skeleton files:
      | username         |
      | brand-new-user   |
      | another-new-user |
    And a new client token for "brand-new-user" has been generated
    And a new browser session for "brand-new-user" has been started
    And the user has generated a new app password named "<PASSWORD>"
    When the user requests "/ocs/v2.php/cloud/users/another-new-user" with "GET" using the generated app password
    Then the HTTP status code should be "401"
    And the API should not return any data

  @notToImplementOnOCIS
  Scenario: normal user gets his own resources using the app password
    Given these users have been created with small skeleton files:
      | username       | password  | displayname | email                    |
      | brand-new-user | %regular% | New user    | <EMAIL> |
    And a new browser session for "brand-new-user" has been started
    And the user has generated a new app password named "<PASSWORD>"
    When the user "brand-new-user" requests these endpoints with "PROPFIND" to get property "d:getetag" using basic auth and generated app password about user "brand-new-user"
      | endpoint                                       |
      | /remote.php/dav/files/%username%/textfile0.txt |
    Then the HTTP status code should be "207"

{'fraction_non_alphanumeric': 0.0608250526949714, 'fraction_numerical': 0.005118940078289671, 'mean_word_length': 3.0372771474878446, 'pattern_counts': {'":': 0, '<': 17, '<?xml version=': 0, '>': 17, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 2, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '3527204', 'n_tokens_mistral': 2660, 'n_tokens_neox': 2584, 'n_words': 1289}