giseldo/neodataset huggingface dataset:
Hide Parameters title when that section is empty on SGPostgresConfig details

### Summary
SGPostgresConfigs Details view have two sections to show parameters: `Parameters` and `Default Parameters`. SGPostgresConfigs generated by default only have default parameters, and on their Details view the section for custom parameters appears empty (only title visible).

#### Steps to reproduce
1. Go to the Details view of any SGPostgresConfig generated by default.
2. The title `Parameters` appears but the section is empty.

### Expected Behaviour
Titles for empty sections should not appear.

### Environment
- StackGres version: 1\.3.0

### Relevant logs and/or screenshots
![Screenshot_2022-09-09_at_12.14.46](/uploads/dbf73a3587467cff968633119512d428/Screenshot_2022-09-09_at_12.14.46.png)

Story points: 4.0
PITR time slots are not set properly on the Web Console

### Summary
Cluster data initialization uses backups ordered alphabetically to setup PITR time slots, no matter the time a backup was finally stored.

#### Steps to reproduce
1. Create a new SGBackup and give it a name starting with `z`.
2. Wait for the first backup to complete and then create a new SGBackup and give it a name starting with `a`.
3. Go to Create new SGCluster.
4. On the Initialization tab, on the Backups section, note that the Backups are ordered alphabetically, which means the backup starting with `a` will appear first even though it was created later than backup starting with `z`.
5. Select the backup starting with `a`.
6. The PITR datepicker will allow you to select a time between the backup `a` and the **next** backup, no matter their chronological order. 
7. Now select the backup starting with `z`.
8. Since that backup is the last of the list, there is no other backup after it, and the PITR select won't work.

### Expected Behaviour
PITR datepicker should use the last backup based on time, not on alphabetical order.

### Environment
- StackGres version:1\.3.0

Story points: 8.0
Disable Delete option on SGInstanceProfiles and SGPostgresConfigs in use

### Summary
The User is allowed to delete SGInstanceProfiles and SGPostgresConfigs even if those are already in use by a SGDistributedLogs.

### Expected Behaviour
Delete option should be disabled on SGInstanceProfiles and SGPostgresConfigs that are being used.

### Environment
- StackGres version: 1\.3.0

Story points: 8.0
Event of missing SGBackupConfig is sent even if backup is working as expected

### Summary

Warning event that say `Missing SGBackupConfig for cluster <cluster namespace>.<cluster name>` is sent even if backup is working as expected.

### Current Behaviour 

A warning event is sent when SGBackupConfig is not used. 

#### Steps to reproduce

1. Create MinIO deployment
2. Create an SGObjectStorage targeting MinIO
3. Create an SGCluster with backups configuration targeting the created SGObjectStorage 

### Expected Behaviour

No warning event about missing SGBackupConfig is sent. 

### Possible Solution

Change the logic so that a warning event is sent about missing SGBackupConfig only if SGBackupConfig is in use or a warning event is sent about missing SGObjectStorage only if SGObjectStorage is in use.

### Environment

- StackGres version: 1.3.0
- Kubernetes version: ?
- Cloud provider or hardware configuration: ?

Story points: 2.0
Cluster form title is "CREATE CLUSTER" even when editing

### Summary

When editing a cluster from the web console, the form's title remains "CREATE CLUSTER", which might be misleading.

![image](/uploads/d93dc427cc1b42935e9a9eb07d86aa12/image.png)


#### Steps to reproduce

- Enter the web console
- Select any cluster 
- Click on EDIT
- The form title will be "CREATE CLUSTER"


### Expected Behaviour

When on edit mode, the form title should be "EDIT CLUSTER"


### Environment

- StackGres version: `1.3.0`

Story points: 4.0
UI backup scheduling inserting trailing zero in cron job minutes config

<!--
Please read this!

Before opening a new issue, make sure to search for keywords in the issues
filtered by the "Bug" label.

Issue tracker:

- https://gitlab.com/ongresinc/stackgres/-/issues?label_name=Bug

and verify the issue you're about to submit isn't a duplicate.
-->
### Summary

When updating a backup schedule in the UI, an extra zero is added to the minutes component of the cron string causing it to be invalid

### Current Behaviour 

Extra 0 added to minutes component, so trying to schedule for daily 15:59 produces "590 15 * * *"

#### Steps to reproduce

1. Update minutes in backup config schedule to >=10,<=59
2. `kubectl get -o yaml <cluster-name>`
3. Observe the incorrect config 

### Expected Behaviour

Schedule is added as entered

### Possible Solution

The field is not being properly synchronized and the default value is being appended to the entered value

### Environment

- StackGres version: 1.3.0
<!-- if you have used helm, you can use:  `helm get notes -n stackgres stackgres-operator` 
more generic: `kubectl get deployments -n stackgres stackgres-operator --template '{{ printf "%s\n" (index .spec.template.spec.containers 0).image }}'`
-->
- Kubernetes version: 1.24.4
<!--(use `kubectl version`) -->
- Cloud provider or hardware configuration:


### Relevant logs and/or screenshots

<!-- (Paste any relevant logs - please use code blocks (```) to format console output,
logs, and code as it's very hard to read otherwise.) -->

Story points: 8.0
Backup EDIT button points to undefined resource

### Summary

When hitting the EDIT button on a Backup view, the web console redirects users to an _undefined_ resource adress.

![image](/uploads/0c778a43ae220df05974fa23c8bbef5d/image.png)


#### Steps to reproduce

- Enter the web console
- Click on any backup to view its details
- Click on the EDIT button on the top right corner

### Expected Behaviour

EDIT button should take users to the backup edition section


### Environment

- StackGres version: `1.3.0`

Story points: 4.0
Wrong message during major/minor upgrade in a cluster with missing security upgrade to apply

### Summary

During a StackGres version upgrade if I forgot to apply the security upgrade before apply a major version upgrade or minor version upgrade, the operator should show only the current postgres version supported for old StackGres version, instead of show all versions! 


#### Steps to reproduce

- Install StackGres 1.1.0
- Create a simple SGcluster using pg `12.8`
- Upgrade StackGres to version `1.2.1`
- Apply a major version upgrade from pg `12.8` to `13.7`

Error (All pg versions included for V_1_2_1 are displayed) 
```
Error from server (https://stackgres.io/doc/1.2/api/responses/error#postgres-major-version-mismatch): error when creating "major.yml": admission webhook "sgdbops.stackgres-operator.stackgres" denied the request: Unsupported postgres version 13.7. Supported postgres versions are: (V_1_0, [14.0, 13.4, 13.3, 13.2, 13.1, 13.0, 12.8, 12.7, 12.6, 12.5, 12.4, 12.3, 12.2, 12.1]), (V_1_1, [14.1, 14.0, 13.5, 13.4, 13.3, 13.2, 13.1, 13.0, 12.9, 12.8, 12.7, 12.6, 12.5, 12.4, 12.3, 12.2, 12.1]), (V_1_2, [14.4, 14.2, 14.1, 14.0, 13.7, 13.6, 13.5, 13.4, 13.3, 13.2, 13.1, 13.0, 12.11, 12.10, 12.9, 12.8, 12.7, 12.6, 12.5, 12.4, 12.3, 12.2, 12.1])
```

### Expected Behaviour

Only the versions from the current StackGres version(V_1_1_0)
``` 
Error from server (https://stackgres.io/doc/1.2/api/responses/error#postgres-major-version-mismatch): error when creating "major.yml": admission webhook "sgdbops.stackgres-operator.stackgres" denied the request: Unsupported postgres version 13.7. Supported postgres versions are: 14.1, 14.0, 13.5, 13.4, 13.3, 13.2, 13.1, 13.0, 12.9, 12.8, 12.7, 12.6, 12.5, 12.4, 12.3, 12.2, 12.1
```

### Possible Solution

Filter the version by the current StackGres version (security upgrade not applied yet in this case)

Story points: 2.0
Rollback to previous version (if possible) when major version upgrade fails

### Problem to solve

Whenever a major version upgrade operation fails the user is not able to rollback the operation. Currently the only workaround is to follow the procedure to ["Reconvery PGDATA from existing volume"](https://stackgres.io/doc/latest/runbooks/recover-pgdata-from-existing-volume/) documented in a StackGres runbook.

### Further details

When a major version upgrade operation fails, if the user did not used the link or clone options the old data is not lost but is still present in the Persistent Volume. The problem is that the cluster can not be used due to the following reasons:

* The `.status.dbOps.majorVersionUpgrade` section is used by the operator to know that the major-version-upgrade init container has to be created. The container blocks the cluster from starting
* The `.spec.postgres.version` can not be changed directly by the user but have to be modified by the SGDbOps generated serviceaccount.

### Proposal

Make the SGDbOps major version upgrade operation to automatically rollback the operation in case of failure is the clone or link options are not used or only the check has been executed.

## Testing

Improve major version upgrade test in order to check the rollback is performed if the operation fails

## Acceptance Criteria

* [ ] Implementation
* [ ] Test
* [ ] Documentation

### Links / references

https://www.postgresql.org/docs/current/pgupgrade.html

Story points: 8.0
PITR date and time picker not working in the Web console


### Summary

Trying to restore a backup using PITR from the Web console, the date picker is not working, after the automatic refresh the date selected is cleaned.

![image](/uploads/faec6768713c5006ab2b1bc62e4b029b/image.png)

Also, the date range used to initialize the datepicker is wrong. 

To set the final date on the range, the initialisation process uses the backup immediately next to the chosen one, even though the SGBackups list coming from the API is ordered alphabetically rather than by date.

#### Steps to reproduce

1. Select create a new cluster
2. Choose an existing backup 
3. Click outside of the datepicker (so the base date is chosen automatically)
4. Wait until the "refresh icon" to the right of the topbar spins (new info is loaded from the API)

### Expected Behaviour

- Date picker keeps the selected date and time.
- Date range is initialised properly based on the last backup available


### Environment

- StackGres version: 1.3.0
<!-- if you have used helm, you can use:  `helm get notes -n stackgres stackgres-operator` 
more generic: `kubectl get deployments -n stackgres stackgres-operator --template '{{ printf "%s\n" (index .spec.template.spec.containers 0).image }}'`
-->
- Kubernetes version: 1.21
<!--(use `kubectl version`) -->
- Cloud provider or hardware configuration: DO

Story points: 6.0
.spec.managedSql.scripts entry duplicates id when a new entry with id 0 is provided by the user

### Summary

`.spec.managedSql.scripts` entry duplicates id when a new entry with id 0 is provided by the user when creating or updating an `SGCluster` 

#### Steps to reproduce

1. Create an sgcluster
2. Export the sgcluster as YAML and change the name
3. Create the modified copy of the original sgcluster

### Expected Behaviour

`.spec.managedSql.scripts` entry should not duplicate any id

### Environment

- StackGres version: 1.3.0
- Kubernetes version: n.p.
- Cloud provider or hardware configuration: n.p.

Story points: 2.0
Node Affinity match set when no inputs have been filled

### Summary

When creating a cluster from the web console, if either Fields or Expressions match has been set, the other is automatically added to the parent object, even when none of its inputs have been filled.

#### Steps to reproduce

- Enter the web console
- Enter the cluster creation form
- Set a cluster name
- Set values for any Node Affinity match, while leaving the inputs on the sibling match empty
- Click no the "View Summary" button
- The Node Affinity section will include the empty match set

![image](/uploads/2ded4376c24611df360a2ceb2a9732c7/image.png)


### Expected Behaviour

No empty matches should be included on a Node Affinity


### Environment

- StackGres version: `1.3.0`

Story points: 2.0
SGCluster edit screen and summary assumes backup performance specs always exist

### Summary

When loading the summary of a cluster creation/edition, the Summary component assumes that Backup Performance specs are always set, while this might not necessarily be the case, since this spec is not mandatory.


#### Steps to reproduce

- Enter the web console
- Select any cluster which doesn't have at least one of the backup performance specs
- Enter the EDIT CLUSTER form
- Click on the "View Summary" button

Nothing will happen and an error like the following will appear on the browser:

![Captura_de_Pantalla_2022-08-24_a_la_s__15.02.46](/uploads/8ed764e763240f7a53d1336bd91a7384/Captura_de_Pantalla_2022-08-24_a_la_s__15.02.46.png)


### Expected Behaviour

Summaries should always open when every mandatory input has been set


### Possible Solution

Validate if the property exists before requesting its value on the summary

### Environment

- StackGres version: `1.3.0`

Story points: 4.0
Implement Cascade replication with WAL shipping

The objective of this issue is to enable cascading replication with WAL shipping.

Additionally, we should implement a method for the promotion of the secondary cluster.

Acceptance criteria:

* [ ] Implement the cascading replication with WAL shipping 
* [ ] Create tests for the feature
* [ ] Document the feature for the customers
* [ ] Document the interface for the UI team

Story points: 32.0
Implement Cascade replication from an external instance

The objective of this issue is to create cascade replication from an external PostgreSQL instance.

Additionally, we should implement a method for the promotion of the cascade cluster.

Acceptance criteria:

* [ ] Implement the cascade replication from an external instance
* [ ] Create tests for the feature
* [ ] Document the feature for the customers
* [ ] Document the interface for the UI team

Story points: 48.0
Implement the UI for cascade replication from a local sgcluster

The objective of this issue is to create the necessary requirements for the UI to support cascade replication from a local sgcluster.

Based on the development of the issue: https://gitlab.com/ongresinc/stackgres/-/issues/1960.

Please consider having a button to promote the cascade replicated cluster.

**Acceptance criteria:**
- [x] Implement the UI for cascade replication from a local sgcluster
- [x] Test the implementation by adding a new cascade cluster
- [x] Test the promotion of the cascade cluster

Story points: 16.0
Implement Cascade replication from a local sgcluster

The objective of this issue is to create cascade replication from an SGCluster in the same namespace.

Additionally, we should implement a method for the promotion of the cascade cluster.

Acceptance criteria:

- [ ] Implement the cascade replication from an SGCluster in the same namespace
- [ ] Create tests for the feature
- [ ] Document the feature for the customers
- [ ] Document the interface for the UI team

Story points: 16.0
Error editing SGCluster with SGStorageBackup configured

## Problem Description

- Using the CLI create an SGCluster using the CRDs below 
kubectl apply 
```
cat << 'EOF' | kubectl create -f - 
apiVersion: stackgres.io/v1beta1
kind: SGObjectStorage
metadata:
  name: object-storage-demo
spec:
  type: s3Compatible
  s3Compatible:
    bucket: <BUCKET_NAME>
    region: <REGION>
    enablePathStyleAddressing: true
    endpoint: <URL>
    awsCredentials:
      secretKeySelectors:
        accessKeyId:
          key: accessKeyId
          name: <SECRET_NAME>
        secretAccessKey:
          key: secretAccessKey
          name: <SECRET_NAME>
---
apiVersion: stackgres.io/v1
kind: SGCluster
metadata:
  name: my-cluster-db
  namespace: default
spec:
  instances: 2
  nonProductionOptions:
    disableClusterPodAntiAffinity: true
  pods:
    persistentVolume:
      size: 10Gi
  sgInstanceProfile: 'default'
  configurations:
    backups:
      - cronSchedule: '*/5 * * * *'
        sgObjectStorage: 'object-storage-demo'        
  postgres:
    version: "14.4"
  prometheusAutobind: true
EOF
```
- Connect to Web Console
- Access the list of SGClusters
- Edit the SGCluster my-cluster-db

ERROR:

- The details page of the SGCluster will be blank
- Inspecting the page is going to be possible to see the error on the console:
```
TypeError: Cannot read properties of undefined (reading 'maxNetworkBandwidth')
    at s (app.0e699056.js:1:536537)
    at Rt.e._render (vue.esm.js:2512:28)
    at s.i (vue.esm.js:2947:27)
    at e.get (vue.esm.js:4119:33)
    at e.run (vue.esm.js:4195:30)
    at yn (vue.esm.js:3193:17)
    at Array.<anonymous> (vue.esm.js:3826:20)
    at zn (vue.esm.js:3748:16)
```

## Possible Solution

The error happens because the SGCluster object doesn't has the property `sgcluster.spec.configurations.backups.performance` fulfilled. This property is ot mandatory

- The property `sgcluster.spec.configurations.backups.performance` should be ignored is it's null

Story points: 1.0
DOC: wrong cluster selector info when connecting to the postgres-util container

## Description

- Using the doc version `1.3.0-RC1` or `1.2.1`, access the [demo quick start page](https://stackgres.io/doc/1.3/demo/quickstart) 
- Install `StackGres 1.3.0-RC1` or any other version
- Following the instruction, in the section `ACCESSING POSTGRES(PSQL)` try to copy/paste and execute the command to connect to the `postgres-util` container
  ```
  kubectl exec -ti "$(kubectl get pod --selector app=StackGresCluster,cluster=true,role=master -o name)" -c postgres-util -- psql
  ```

**Problem:** 

```
error: pod, type/name or --filename must be specified
``` 

**Also, this command is repeated in the section "CLUSTER MANAGEMENT AND AUTOMATED FAILOVER" twice!**

## Probably Solution

- Change the command to:
  ```
  kubectl exec -ti "$(kubectl get pod --selector app=StackGresCluster,stackgres.io/cluster=true,role=master -o name)" -c postgres-util -- psql
  ```

## Acceptance Criteria

- [ ] As result, the purposed solution should log into postgres using psql
```
kubectl exec -ti "$(kubectl get pod --selector app=StackGresCluster,stackgres.io/cluster=true,role=master -o name)" -c postgres-util -- psql
psql (14.5 OnGres Inc.)
Type "help" for help.

postgres=# 

```

Story points: 1.0
Bump StackGres version components

## Description

Bump all StackGres components to the latest versions

## Acceptance Criteria

- [ ] Envoy `at least 1.24.0`
- [ ] Fluentbit `at least 1.9.9`
- [ ] FluentD `at least 1.15.2`
- [ ] Quarkus `at least 2.13.3`
- [ ] GraalVM `22.2.0`

Story points: 4.0
Adjust color of Open in new tab icons

### Summary
Wrong color on `Open in new tab` icons on Extensions table on Create Cluster form.

### Environment

- StackGres version: 1\.3.0-SNAPSHOT

### Relevant logs and/or screenshots
![Screenshot_2022-08-12_at_15.31.07](/uploads/31c8f78c18520be65f1808875bca89f8/Screenshot_2022-08-12_at_15.31.07.png)

Story points: 4.0
Adjust layout on DbOps Overview when empty

### Summary
On the Overview of the DbOps, when there are none, the background of the row with the link to create a new one is not adjusted properly (missing one column).

Same happens on InstanceProfiles Overview.

### Environment
- StackGres version: 1\.3.0-SNAPSHOT

### Relevant logs and/or screenshots
![Screenshot_2022-08-12_at_15.12.37](/uploads/05adcfc1c5ac495d1f6b56ad0c95747e/Screenshot_2022-08-12_at_15.12.37.png)

Story points: 4.0
update docs about blocklisted parameters

Current doc [page about `SGPGConfig`](https://stackgres.io/doc/latest/reference/crd/sgpgconfig/) doesn't contain the up-to-date [list of blocked list parameters](https://gitlab.com/ongresinc/stackgres/blob/main/stackgres-k8s/src/operator/src/main/resources/postgresql-blocklist.properties).

## Acceptance Criteria

- [ ] Page is updated with the new parameters
- [ ] Page also update the description, saying that the blocked parameters are not allowed and during an update or the creation, the operation is canceled.

Story points: 1.0
Doc: Review and update SGDBOps CRD References

## Problem Description

The documentation of [SGDBOps CRD reference](https://stackgres.io/doc/latest/reference/crd/sgdbops) is outdated and missing a lot of required fields for almost all SGDBOps jobs.

## Possible Solution
- Review/Add all fields(required and not required) for each type of job
  - [benchmark](https://stackgres.io/doc/latest/reference/crd/sgdbops/#benchmark)
  - [vacuum](https://stackgres.io/doc/latest/reference/crd/sgdbops/#vacuum)
  - [repack](https://stackgres.io/doc/latest/reference/crd/sgdbops/#repack)
  - [majorversionupgrade](https://stackgres.io/doc/latest/reference/crd/sgdbops/#major-version-upgrade)
  - [minorversionupgrade](https://stackgres.io/doc/latest/reference/crd/sgdbops/#minor-version-upgrade)
  - [restart](https://stackgres.io/doc/latest/reference/crd/sgdbops/#restart)
  - [securityupgrade](https://stackgres.io/doc/latest/reference/crd/sgdbops/#security-upgrade)

Story points: 2.0
Highlight Storage Types fields when they cause an error on submit

### Summary
On the Object Storages form, when no Storage Type has beed selected, there is no clear indication for the user to know what field is causing the error on submit. 

#### Steps to reproduce
1. Go to Create Object Storages form.
2. Set a name.
3. Try to create the configuration. 
4. An error appears, but no fields are highlighted.

### Expected Behaviour
Storage Types icons should be highlighted in red when they cause an error on submit.

### Environment
- StackGres version: 1\.3.0-SNAPSHOT

Story points: 8.0
Benchmark duration fields remain red even if duration is set

### Summary
Once a Benchmark duration is not valid or not set, the duration fields remain red even if the User sets a duration.

#### Steps to reproduce
1. Go to Create DbOps form and select `Benchmark`.
2. Fill in all mandatory fields but the duration.
3. Try to create the DbOp. The duration fields will turn red since they are required.
4. Set a duration. The other duration fields remain red but should't.

### Expected Behaviour
When a duration is set, all duration fields should stop being red.

### Environment
- StackGres version: 1\.3.0-SNAPSHOT

### Relevant logs and/or screenshots
![Screenshot_2022-08-01_at_11.48.53](/uploads/40b370f3f68bce98564818a51db3002c/Screenshot_2022-08-01_at_11.48.53.png)

Story points: 8.0
password compromising in Downloading extensions metadata from log message

Hello, Stackgres Team,

Using helm we deployed Stackgres and configured internal proxy (--set-string extensions.repositoryUrls[0]="...").

We uses AD proxy authentication, and in stackgres-restapi we see next messages that compromises AD account password:

`2022-07-25 09:53:39,196 INFO  [io.stackgres.common.extension.ExtensionMetadataManager] (executor-thread-106) Downloading extensions metadata from https://extensions.stackgres.io/postgres/repository?proxyUrl=http%3A%2F%2Fsvc_stackgreststprxy%3A<!!!OUR ACCOUNT PASSWORD!!!>%40proxy.domain.local%3A3128`

1) Is it possible somehow to masquerade account password to do not show it in output log?<br>
2) Could we deploy and point stackgres to our own internal repository for this purposes? Is there any instructions how to deploy it?

Story points: 4.0