@Chris Milton , the issue security scheme everyone has pointed you at controls what the external user can see; your question is what they can manage, and that depends on something nobody has asked yet: what kind of external user this is. There are three, and the answer is different for each.
1. A JSM portal customer (free, no Jira licence). They can raise, view, comment on and, if you enable it, transition their own requests through the portal, and see requests shared with them or their organisation. They cannot edit fields, assign, or manage anything on the agent side. If "manage" means "follow and respond to their own tickets," this is the answer and it costs nothing.
2. A Jira guest (free, 5 per paid user, Standard plan and above, external domain only). @Arkadiusz Wroblewski is right to raise this and it is the closest fit for "manage a subset." A guest is added to one space and gets the space's guest role, whose permissions you configure in the permission scheme like any other role: Browse, Edit, Assign, Transition, Comment, and so on (guest permissions in Jira). No global permissions, no space administration. The limitation is that the role's permissions apply to every work item the guest can see in that space, so "only specific tickets" is achieved by combining the guest role with issue security (which is where @John Funk and @Jack Ruby answers come in): the guest role gets Edit and Transition in the permission scheme, and an issue security level restricts which items they can see at all. Permission decides what they can do; security decides on which items.
3. A licensed user. If the external person needs to work across spaces, administer anything, or exceed what the guest role allows, they are a paid seat, and then it is the normal permission scheme plus issue security again.
The combination that answers your question literally: guest role in the space with Browse, Edit, Assign (if needed) and Transition, plus an issue security scheme with a level that includes that guest for the specific tickets. Set the level on those items (by hand, or by an automation rule on a label or component), and the guest can manage exactly those and nothing else. Two gotchas: guests cannot be internal-domain people, and you cannot downgrade an existing paid user to a guest to save a seat; Atlassian's doc is explicit on both.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.