Open StevenWeathers opened 5 months ago
I am not really sure where the limit of integration should be, I feel we should have a mapping and loosely map things, but there are sooooo many variables to instances, orgs, teams, stories, etc.
Take a look at the user jira instance functionality already in place, essentially its a way to define the jira instance URL and the authentication mechanism which currently we only support an API key mechansim. Longterm I would like to add other auth flows with jira so individual users can auth with jira at the time of use.
I am just wondering how you want this to work.
Right now a user can define instances. At an Org level, would this trickle down then so that users under an org would get instance support as well?
As a User under an Organization I can have an instance on my user. I can also possibly have an instance from the organization level.
As an Organization I should be able to have a jira instance that all users in the organization can connect with.
What are the security implications? Would unauthorized users be able to access resources they shouldn't?
I am just wondering how you want this to work.
Right now a user can define instances. At an Org level, would this trickle down then so that users under an org would get instance support as well?
As a User under an Organization I can have an instance on my user. I can also possibly have an instance from the organization level.
As an Organization I should be able to have a jira instance that all users in the organization can connect with.
What are the security implications? Would unauthorized users be able to access resources they shouldn't?
So with the new Team and Organization subscriptions all members of the subscription entity get access to setup Jira instances at their user level, with this ticket the goal is to allow an Org or Team admin to setup a jira instance associated to the respective entity that the members can then use. This allows an org to set it up once for all users, often jira instances are setup where users can't create API keys for their accounts however the system admins can so they could be in charge of setting up that connection.
Hope that clears it up, if not I can write detailed requirements 🤣
As far as security goes, only the admins of the respective entity should be able to manage the configuration of jira instances directly setup on that entity, end users should not be able to see the API key when invoking features that get the list of Jira instances belonging to the entity.
Add the ability for a subscribed Organization to setup a shared Jira Instance for its employees to use in Thunderdome features.