Feature ideas

I’d like to propose a feature that would prevent users from progressing to the next stage or submitting a form based on specific conditions. Right now, we’re relying on hidden required fields to enforce this, which is bug-prone and limited. Implementing it similar to “Step-level visibility”[ https://docs.port.io/actions-and-automations/create-self-service-experiences/setup-ui-for-action/advanced-form-configurations?additional-inputs=visible ] would provide more robust, flexible validation, improve user experience, and eliminate the current workaround.

Currently, using the dynamic permissions feature, self-service actions will still appear in the UI. In case the user is not permitted, the run will be rejected only after sending the self-service action form. As part of this item, we would like to support hiding/displaying self-service actions using the dynamic permissions policies.

We want to build some fairly complex self-service action flows. Having more control over the forms and layout and screens would make some of these more viable.

Input fields that are hidden using the visibility property, or marked as disabled , remain visible and editable when the form is switched to JSON mode. Currently, the visibility property only affects how fields are displayed in the UI. It hides them from the standard form view but doesn’t remove them from the underlying data structure or JSON representation. This behaviour can potentially allow users to modify fields they shouldn’t have access to, which may introduce security or data integrity risks. Suggested Enhancement: Consider excluding hidden and disabled fields from JSON mode, or marking them as read-only, to align behaviour with the form view and prevent unauthorised edits.

We want to dynamically validate action form string inputs so that the second field must exactly match the first. Currently you can apply a regex to each input, but they don't work to validate between fields. Example Use Case: An SSA where the user inputs an email address, and then they're required to confirm it by entering the identical value in a second field.

We have a self-service action called "Transfer Ownership". This enables our teams to transfer ownership of codebases / services. We opted to restrict the user-inputs form so that the new owners drop-down only displays teams which the current user is a member of - to encourage new owners to claim ownership, rather than other teams dropping it on them. ```json "userInputs": { "properties": { "new_owners": { "type": "string", "blueprint": "_team", "dataset": { "combinator": "or", "rules": [ { "property": "$identifier", "operator": "in", "value": { "jqQuery": ". user.team " } } ] } } }, }, ``` We are interested in extending this dataset filter so that, if the current user is a Port admin, we would display all teams as an option in the drop-down. I'm aware of the new Contextual query rules ( https://docs.port.io/search-and-query/#contextual-query-rules ), however these do not pass validation rules, so I'm assuming it's not currently supported in this use-case.

Allow categorizing self service actions for ease of finding appropriate actions for your needs.

In self self-service form, when using a date field, the default is date & time, can we have just date

Currently member users can manually update the status for action runs to Failure if they executed the run. We would like to block the ability for member users to manually set an action run's status.

My team approves certain self-service actions. Me and my team also use the same self-service actions for our own day-to-day work at times. When we submit one of these requests we approve our own requests. While some requests might warrant a separate approver, even on the same team, in our case we don't. We simply need the self-service action to execute, but we have to approve our own request, which is just extra work. Today there is a "General access" section at the bottom of the Approvers section of the Edit action window. There is a toggle for Admins, so admins do not need approval. My Feature Request is to possibly rename the "General access" heading because this doesn't seem intuitive. Instead, name it something like "Approval Bypass". Keep Admins and add a new toggle like "Approvers". When enabled, if a requestor is a named approver or in an approver group then requests by that user would not need to be approved.