chore: merge develop into main (#1096)

.github/workflows/build-test-release.yml

@@ -9,7 +9,10 @@ on:
     tags:
       - "v[0-9]+.[0-9]+.[0-9]+"
   pull_request:
-    branches: [ main, develop, "release/**" ]
+    branches:
+      - "main"
+      - "develop"
+      - "release/**"
 
 concurrency:
   group: ${{ github.workflow }}-${{ github.event.pull_request.number || github.sha }}
@@ -52,7 +55,7 @@ jobs:
       - uses: actions/setup-python@v5
         with:
           python-version: "3.7"
-      - uses: pre-commit/[email protected].0
+      - uses: pre-commit/[email protected].1
 
   semgrep:
     runs-on: ubuntu-latest
@@ -210,20 +213,22 @@ jobs:
       github.ref_name == 'main' ||
       github.base_ref == 'develop' ||
       github.ref_name == 'develop' ||
+      startsWith(github.ref_name, 'release') ||
+      startsWith(github.base_ref, 'release') ||
       contains(github.event.pull_request.labels.*.name, 'run-ui-tests')
     runs-on: ubuntu-latest
     permissions:
       id-token: write
       contents: read
       checks: write
-    continue-on-error: true
     needs:
       - meta
       - build-test-addon
       - build
       - test-unit
       - test-smoke
     strategy:
+      fail-fast: false
       matrix:
         splunk: ${{ fromJson(needs.meta.outputs.matrix_supportedSplunk) }}
         test-mark:
@@ -300,6 +305,33 @@ jobs:
           appinspect_manual_checks: tests/testdata/expected_addons/expected_output_global_config_everything/.appinspect.manualcheck.yaml
           appinspect_expected_failures: tests/testdata/expected_addons/expected_output_global_config_everything/.appinspect.expect.yaml
 
+  all-checks:
+    if: ${{ !cancelled() }}
+    needs:
+      - test-ui
+      - build-test-addon-openapi-client
+      - storybook-screenshots
+    runs-on: ubuntu-latest
+    env:
+      NEEDS: ${{ toJson(needs) }}
+    steps:
+      - name: check if tests have passed or skipped
+        id: check
+        shell: bash
+        run: |
+          ALL_JOBS_PASSED=$(echo "$NEEDS" | jq "all(.[]; .result == \"success\" or .result == \"skipped\")")
+          if [[ "$ALL_JOBS_PASSED" == "true" ]]
+          then
+              echo "all-checks=true" >> "$GITHUB_OUTPUT"
+          else
+              echo "all-checks=false" >> "$GITHUB_OUTPUT"
+          fi
+      - name: Fail job if something failed
+        if: ${{ steps.check.outputs.all-checks == 'false' }}
+        run: |
+          echo "Some check failed"
+          exit 1
+
   release:
     needs:
       - build
@@ -311,6 +343,7 @@ jobs:
       - appinspect-for-expected-outputs
       - semgrep
       - pre-commit
+      - all-checks
     runs-on: ubuntu-latest
     if: "! github.event.pull_request.head.repo.fork "
     steps:

.releaserc

@@ -18,6 +18,7 @@
     [
       "+([0-9])?(.{+([0-9]),x}).x",
       "main",
+      { name: "release/beta", prerelease: "beta", channel: "beta" },
     ],
   plugins:
     [

docs/additional_packaging.md

@@ -1,10 +1,10 @@
 # `additional_packaging.py` file
 
-To extend the build process, you can create `additional_packaging.py` file in the same file level where you have your globalConfig file.
+To extend the build process, you can create a `additional_packaging.py` file in the same file level where you have your globalConfig file.
 
-This file should have `additional_packaging` function which accepts 1 argument: add-on name.
+This file should have the `additional_packaging` function, which accepts add-on name as its only argument.
 
-Example of how to utilize it:
+See the following example for proper usage: 
 
 * Build custom UI after `ucc-gen` finishes all its necessary steps.
-* Workaround a `ucc-gen` feature which was not implemented.
+* Use a workaround for a `ucc-gen` feature that has not been implemented.

docs/advanced/custom_mapping.md

@@ -1,4 +1,4 @@
-We can use this feature to map each field with meaningful value to display in the table. For example, The category field contains 1, 2, and 4 values, but when those values are displayed as it is then the user might get confused as those values do not signify the meaning of their mapping. To avoid this confusion user can map each field with meaningful value as shown in the example below.
+We can use this feature to map each field with meaningful value to display in the table. For example, the category field contains 1, 2, and 4 values, but when those values are displayed, the user might get confused as those values do not signify the meaning of their mapping. To avoid this confusion, the user can map each field with meaningful value as shown in the following example:
 
 ### Usage
 
@@ -73,6 +73,6 @@ We can use this feature to map each field with meaningful value to display in th
 
 ### Output
 
-This is how it looks like in the UI:
+This is how it looks in the UI:
 
 ![image](../images/advanced/custom_mapping_output.png)

docs/advanced/custom_rest_handler.md

@@ -2,13 +2,11 @@
 
 It is possible to extend the default behaviour of the UCC-generated REST handlers.
 
-For example, if your add-on requires an API key to operate and you want to validate this API key during its creation, you may want to use the custom REST handlers to achieve that.
+For example, if your add-on requires an API key to operate and you want to validate this API key during its creation, you might want to use the custom REST handlers to achieve that.
 
-> Note that `ucc-gen` will not override the REST handler code if you use correct file name under `bin` folder.
+> Note: `ucc-gen` will not override the REST handler code if you use the correct file name under the `bin` folder.
 
-Below there an example of how it can be done. It contains a REST handler for creating an organization with `organization_id` and `organization_api_key` fields, not custom one, just generated by `ucc-gen`.
-
-But below that there is a custom handler `CustomRestHandler` class which has additional steps for configuration creation and edit operations, specifically `handleEdit` and `handleCreate` methods.
+See the following example of how it can be done. It contains a REST handler for creating an organization, with the `organization_id` and `organization_api_key` fields, which are not custom ones, generated by `ucc-gen`. But, also in the example, there is a custom handler, `CustomRestHandler` class which has additional steps for configuration creation and edit operations, specifically `handleEdit` and `handleCreate` methods:
 
 ```python
 import import_declare_test
@@ -111,17 +109,17 @@ if __name__ == "__main__":
 
 > UCC 5.18.0 natively supports custom REST handlers for the modular inputs.
 
-One of the common scenarios is to delete a checkpoint after you are deleting an
-input in the Inputs page. Otherwise, users may face the wierd consequences if 
-they create an input with the same name as the input that was deleted and this 
-newly created input will be reusing the old checkpoint because the names of 
+One common scenario is to delete a checkpoint after you delete an
+input in the Inputs page. Otherwise, users may face strange consequences if 
+they create an input with the same name as the input that was deleted, and this 
+newly created input will reuse the old checkpoint, because the names of 
 the inputs are the same. We would like to avoid this situation in the add-on.
 
-This can be done without a need to modify the REST handler code generated 
+This can be done without a need to modify the REST handler code
 automatically by running `ucc-gen`.
 
-Below is the automatically generated REST handler code for a modular input REST 
-handler.
+See the following automatically generated REST handler code for a modular input REST 
+handler:
 
 ```python
 

docs/advanced/dependent_dropdown.md

@@ -1,4 +1,4 @@
-This feature allows dynamic loading options for `singleSelect` and `multipleSelect` fields when options for that field depend on other fields' values. It loads options via API call to the endpoint mentioned in `endpointUrl` under options when any dependencies field is updated and all required dependencies fields are non-null.
+This feature allows dynamic loading options for the `singleSelect` and the `multipleSelect` fields when the options for that field depend on other fields' values. It loads options via an API call to the endpoint mentioned in `endpointUrl` under options when any dependencies field is updated and all required dependencies fields are non-null.
 
 All non-required dependencies fields can be of any type, but all required dependencies fields should only be of single-select type.
 
@@ -26,4 +26,4 @@ All dependencies fields' values are added to the endpoint URL as query parameter
 }
 ```
 
-> Note: When using the text type field, add debounce using the custom hook to reduce the number of API calls.
+> Note: When using the text type field, add debounce using the custom hook to reduce the number of API calls.

docs/advanced/groups_feature.md

@@ -1,13 +1,13 @@
-Using this functionality, the Inputs page form can be divided into distinct sections, each comprising relevant fields. If the `isExpandable` property is set to true in the global config file, the group will be of the [collapsible panel](https://splunkui.splunk.com/Packages/react-ui/CollapsiblePanel) type. 
+Using this functionality, the Inputs page form can be divided into distinct sections, each comprising relevant fields. If the `isExpandable` property is set to true in the global configuration file, the group will be in the [collapsible panel](https://splunkui.splunk.com/Packages/react-ui/CollapsiblePanel) type. 
 
 The groups will be displayed at the bottom of the form.
 
 ### Properties
-- `label` to display the title of a specific group.
-- `fields` to specify the list of fields in a group. All fields must be present in the **entity**.
+- `label` displays the title of a specific group.
+- `fields` specifies the list of fields in a group. All fields must be present in the **entity**.
 - `options`:
     - `isExpandable` can be used to hide/show fields of the group. The default value is **false**.
-    - `expand` to show all fields of the group while opening the form. The default value is **false**.
+    - `expand` can be used to show all fields of the group while opening the form. The default value is **false**.
 
 ### Usage
 ```
@@ -50,5 +50,5 @@ The groups will be displayed at the bottom of the form.
 },
 ```
 ### Output
-This is how it looks like in the UI:
+This is how it looks in the UI:
 ![image](../images/advanced/groups_feature.png)

docs/advanced/oauth_support.md

@@ -1,49 +1,49 @@
-UCC allows you to add Auth support in the configuration page. In UCC, OAuth2.0 of the Authorization Code Flow `grant` type is being used. It only supports the standard parameters specified in [RFCP749](https://www.rfc-editor.org/rfc/rfc6749) for obtaining an authorization code.
+UCC allows you to add Auth support in the configuration page. In UCC, OAuth2.0 of the Authorization Code Flow `grant` type is used. It only supports the standard parameters specified in [RFCP749](https://www.rfc-editor.org/rfc/rfc6749) for obtaining an authorization code.
 
-Auth can be used inside the entity tag. Use `type: "oauth"` in the entity list and also need to specify the `options` next to the `type: "oauth"`.
+Auth can be used inside the entity tag. Use `type: "oauth"` in the entity list and specify the `options` next to the `type: "oauth"`.
 
 ### Properties
 
 - `type` field value must be oauth.
 - `options`:
     - `auth_type` must be present. It can have either ["basic", "oauth"] (If we want basic and oauth both support) or ["oauth"] (If we want oauth support only).
-    - `basic` This must be present only if auth_type: ["basic"]
-        - This will have list of fields you want to add in basic authentication flow. In the given example, it is username, password and security_token. 
-        - **Please note that as of now, If you are selecting basic as auth_type then username and password fields are mandatory.**
-    - `oauth` This will have list of fields you want to add in oauth authentication flow. In the given example, it is `client_id`, `client_secret`, `redirect_url`, `scope` and `endpoint`.
+    - `basic` must be present only if the auth_type is ["basic"].
+        - This will have a list of fields for you to add in the basic authentication flow. In the given example, it is username, password, and security_token. 
+        - **Note: As of now, if you are selecting basic as auth_type, then the username and password fields are mandatory.**
+    - `oauth` will have a list of fields for you to add in the oauth authentication flow. In the given example, it is `client_id`, `client_secret`, `redirect_url`, `scope`, and `endpoint`.
     - These fields are mandatory:
-        - `client_id` this is client id for the your app for which you want auth
-        - `client_secret` this is client secret for the your app for which you want auth
-        - `redirect_url` this will show redirect url which needs to be put in app's redirect url.
-        - `endpoint` this will be endpoint for which we want to build oauth support. For example for salesforce that will be either "login.salesforce.com" or "test.salesforce.com" or any other custom endpoint.
-          - there is also a possibility to specify separate endpoints for authorize and token, to do that instead single 'endpoint' field use two separate ones:
-            - `endpoint_authorize` - to specify the endpoint used for authorization ie. login.salesforce.com
-            - `endpoint_token` - to specify the endpoint used for token acqusition ie. api.login.salesforce.com
-    - `auth_code_endpoint` this must be present and its value should be endpoint value for getting the auth_code using the app. If the url to get auth_code is https://login.salesforce.com/services/oauth2/authorize then this will have value /services/oauth2/authorize
-    - `access_token_endpoint` this must be present and its value should be endpoint value for getting access_token using the auth_code received. If the url to get access token is https://login.salesforce.com/services/oauth2/token then this will have value /services/oauth2/token
-    - `auth_label` this allow user to have custom label for Auth Type dropdown
-    - `oauth_popup_width` width in pixels of the popup window that will open for oauth authentication (Optional, defaults to 600)
-    - `oauth_popup_height` height in pixels of the popup window that will open for oauth authentication (Optional, defaults to 600)
-    - `oauth_timeout` timeout in seconds for oauth authentication (Optional, defaults to 180 seconds)
-    - `oauth_state_enabled` to include state for oauth authentication (default value is false)
-    - `auth_endpoint_token_access_type` optional parameter that is mapped into value of token_access_type query param in authorisation url
+        - `client_id` is the client id for applying auth to your app or apps.
+        - `client_secret` is the client secret for applying auth to your app or apps.
+        - `redirect_url` will show the redirect url, which needs to be put in the app's redirect url.
+        - `endpoint` will be the endpoint for you to build oauth support. For example, for salesforce, it will either  be "login.salesforce.com", "test.salesforce.com", or any other custom endpoint.
+          - There is also the ability to specify separate endpoints for authorize and token. To do this, instead of the single 'endpoint' field, use two separate ones:
+            - `endpoint_authorize` specifies the endpoint used for authorization, for example, login.salesforce.com.
+            - `endpoint_token` specifies the endpoint used for the token acqusition, for example, api.login.salesforce.com.
+    - `auth_code_endpoint` must be present and its value should be the endpoint value for getting the auth_code using the app. If the url to get the auth_code is https://login.salesforce.com/services/oauth2/authorize, then this will have the value /services/oauth2/authorize.
+    - `access_token_endpoint` must be present and its value should be the endpoint value for getting the ccess_token using the auth_code received. If the url to get the access token is https://login.salesforce.com/services/oauth2/token, then it will have the value /services/oauth2/token.
+    - `auth_label` allows the user to have the custom label for the Auth Type dropdown.
+    - `oauth_popup_width` is the width in pixels of the pop-up window that will open for oauth authentication (Optional, defaults to 600).
+    - `oauth_popup_height` is the height in pixels of the pop-up window that will open for oauth authentication (Optional, defaults to 600).
+    - `oauth_timeout` is the timeout in seconds for oauth authentication (Optional, defaults to 180 seconds).
+    - `oauth_state_enabled` is used to include the state for oauth authentication (default value is false). 
+    - `auth_endpoint_token_access_type` is an optional parameter that is mapped into the value of the token_access_type query param in the authorisation url. 
 
-    - Fields allowed in basic and oauth fields as of now:
-        - `oauth_field`: This should be kept as it is and without any change.
-        - `label`: This can be changed if the user wants to change the label of the field in UI.
-        - `field`: For now this user must keep it as it is for mandatory fields as mentioned above.
-        - `help` : This can be changed if user wants to change the help text displayed below field.
-        - `encrypted` : This should be true if user wants that particular field encrypted else no need to have this parameter.
-        - `required`: To specify whether the field is required or not. The default value is true.
-        - `defaultValue`: The initial input value. (string, number or boolean)
+    - The fields allowed in the basic and oauth fields are the following: 
+        - `oauth_field` should be kept as it is and without any change.
+        - `label` can be changed if the user wants to change the label of the field in UI.
+        - `field` must keep it as it is for mandatory fields as mentioned before. 
+        - `help` can be changed the if user wants to change the help text displayed below the field.
+        - `encrypted` should be true if the user wants that particular field encrypted, otherwise, there is no need to have this parameter.
+        - `required` specifies whether the field is required or not. The default value is true.
+        - `defaultValue` is the initial input value (string, number, or boolean).
         - `options`:
             - `placeholder`: The placeholder for the field.
-            - `disableonEdit`: When the form is in edit mode, the field becomes uneditable. Default value: false
-            - `enable`: The enable property sets whether a field is enabled or not. Default value: true
+            - `disableonEdit`: When the form is in edit mode, the field becomes unable to be edited. The default value is false.
+            - `enable`: The enable property sets whether a field is enabled or not. The default value is true.
 
 
 > [!WARNING]
-> [Placeholder](https://splunkui.splunkeng.com/Packages/react-ui/Text?section=develop) attribute is deprecated and will be removed in one of the following versions. Instead, we recommend using "help" attribute.
+> The [Placeholder](https://splunkui.splunkeng.com/Packages/react-ui/Text?section=develop) attribute is deprecated and will be removed in one of the following versions. Instead, using the "help" attribute is recommended. 
 
 ### Usage
 
@@ -147,8 +147,8 @@ Auth can be used inside the entity tag. Use `type: "oauth"` in the entity list a
 
 This is how the Add Account modal looks after adding the above code to the globalConfig.json file:
 
-This is how Add Account looks when auth_type is `basic`:
+This is how Add Account looks when the auth_type is `basic`:
 ![image](../images/advanced/basic_auth_output.png)
 
-This is how Add Account looks when auth_type is `oauth`:
+This is how Add Account looks when the auth_type is `oauth`:
 ![image](../images/advanced/oauth_output.png)