Feature Request: Automatic metadata for easy importing
Nobody has claimed this yet.
- Dominant language
- Python
- Stars
- 6.5k
- Forks
- 787
- PR merge metrics
- No merged PRs in 30d
Description
In the vein of "How do we make it super easy to get started", we should revisit our metadata a bit.
Premise: A user should be able to drop in any executable and have it automatically be registered to the system.
This means, user should have to write no metadata. So, how does this work? Things to consider:
- We have chosen metadata as the route to go. It is a good one, and helps as users simplify user input with sane defaults and type checking in many cases. But, as a new user, I do not know the best way that users will consume the action, or I am still in the learning process of StackStorm. Are there ways to automatically generate boilerplate for any arbitrary command? Not sure if this needs to be saved automatically, or as an option, but... how would the default case go assuming the user needed to get started without writing a single line of metadata.
- Once the user learns more about the action in general, and how it is being consumed by users and the system, they will inevitably begin adding metadata to start drawing better bounds around a given action. In these cases, what might a transition path look like? We need to ensure that while a user is trying out setting schema for the action, that any 'out of the box' assumptions we make in the previous step are still usable. How do we give users to selectively toggle at runtime which set of parameters is actually parsed and submitted to the runner?
- How can we also make the script and the metadata less coupled together? What if when I share something with a user, I just want to give them the one script... not an entire pack with metadata and config and whatnot wrapped around. Are there ways that we can provide users with some sort of convention within whatever executable to be used to better define schema? Something like
pydoc? - UI should probably have some fun conventions here, as well as ChatOps. How can we make it such that scripts can be uploaded via drag-and-drop, or downloaded and installed via ChatOps and a URL? Once I have these things, how can I then promote or move around these actions to different packs within the system?
- Security. In systems with RBAC, this could theoretically introduce quite a large security exposure, but this is a usability versus security route, and it only really matters in a system where a user can define roles. What sort of restrictive permissions can be automatically applied until explicitly defined by the user and opened up? Admin only roles? User shouldn't even have to think about this until they want to even assume they're keeping this script in the system. To that end, if they have access to upload/register said action, can we assume they have access to execute it? If not, how can we ensure that this problem can safely be ignored on the part of the user, cause we got their back.
The use-case I'm thinking about here really has to do with the folks who are coming from the sysadmin/shell script backgrounds. This person has a script, and wants to check StackStorm, and I'm just throwing things at the wall to see how they stick. I don't need all the metadata. I just want to see how my script(s) are going to work in the context of /(ChatOps|Workflow)/. How can we make this ✨ and ease the learning curve?
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
The issue names no files, tests, or entry points and spans automatic registration, metadata, UI, ChatOps, pack movement, and RBAC. Start by narrowing it to a concrete first slice, then locate the existing metadata and action-registration paths. Done should be an agreed scope with explicit behavior, security boundaries, and acceptance criteria.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python
- Domain
- backend, devops, security, tooling
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 18/100