Possible to add attachment without "browse" permission on project?

[Deleted user]

Hi,

currently we use the JRJC (1.0) to programmatically create issues in project "XYZ" for our customers. These issues get attachments, also added programmatically. The JIRA user being used in JRJC currently has the browse permission for this project and all works well.

Now we'd like to get rid of the browse permission for this particular user because of security reasons but when adding attachments we get an error message that the user does not have the permission to view the (just added) issue. We use the following code:

// use an IssueInputBuilder to "build" the issue...
BasicIssue basicIssue = issueClient.createIssue(builder.build(), pm);
// handcrafted attachments URI
URI attachmentsURI = UriBuilder.fromUri(basicIssue.getSelf()).path("attachments").build();
// create a list of attachments...
issueClient.addAttachments(pm, attachmentsURI, attachments);

Note that we build attachmentsURI by ourselves because basicIssue does not have an appropriate getter method for it and fetching the issue via "issueClient.getIssue(basicIssue.getKey()..." isn't an option either (no browse permission => getIssue() will fail).

So is it actually possible to add attachments to an issue (programmatically) without having browse permissions? Maybe JRJC 2.0 offers functionality for this? Or is it a (arguably reasonable) limitation of the JIRA backend?

Thanks for advice and regards from Germany,
Oliver

[Alex Perez · Accepted solution]

IMO its a Jira limitation.

I never heard about JRJC (I guess its a Jira client library) but if you access Jira Web as a normal user with these permissions (can create and attach but can't browse) the behaviour is that Jira allows the user to create the issue, but once create he can't view it's own issue (and he can't attach files if not attached in the 1st screen). This behaviour is consistent with you issue using JRJC ...

What do you want to avoid by revoking the browse permission?

Can you consider a listener watching the "file attached" event on issues created by the user X that changes the security level?

[Udo Brand]

I agree with most parts of Alex answer. Without browse project you're not able to attach something since you're not allowed to see the issue.

The listener is a good idea but would have its limitations. First, you would still see the issue if nothing is attached and second, you could only attach once.

If you would use for each customer an own generic user you could somehow add a customer specific security level during the creation (e.g. with a create listener for this user). That would probably solve your problem

[Rahul Yadav]

I have found a way to implement some sort of issue viewing restrictions while having to allow everyone the ability to Browse Projects in order to allow anonymous users to do issue attachments:

To allow anonymous users to include attachments to issues:

Go into your Administration page>Global Permissions>Permission Schemes

For your Default Permission Scheme click on the Permissions link

For Browse Projects, Create Issues, Create Attachments, Delete Own Attachments, you need to include:

Project Role (Users)

Group (Anyone)

Then the below needs to be followed in order to prevent anonymous users from seeing tickets within all projects:

Go into your Administration page>Issues>Issue Security Scheme

Click the Add Issue Security Scheme button

Enter a name such as 'Internal'

Click the Security Levels link for that new scheme

Enter a name such as 'Internal'

Click Add Security Level button

Click the Add link underneath Operations for that security level

Select a Group and then 'jira-users' in the drop down field and click the Add button

Go to Projects>Select one of your projects

Click the Administration tab

Go to Issue Security

Click the Action button and select 'Select a scheme'

In the Scheme drop down select the 'Internal' scheme which you had created and click the Next button

Select the Security level drop down and select the 'Internal' security level and click the Associate button

Log out of JIRA

Go to the dashboard page to enter a new defect (ex: https://yourcompanyname.atlassian.net/secure/Dashboard.jspa)

Try the attachment functionality and confirm it works

Once you have submitted the new defect go to the Projects link at the top and click View All Projects

Click on any of your projects

You will notice that you (as an anonymous user) cannot view any tickets within the project

[Alex Perez]

Hi Christian,

I think that the solution might be defining a set of security levels. At least, 2 security levels: public and private.

public: anyone can see (DEFAULT)

private: only staff (your support-development team) and reporter can see

Permission Scheme should include browse permissions for everyone involved. Don't worry, you will limit this with the security levels.

The generic user should have the create, browse and attach permissions. Define in the workflow a transition from "pending" to "completed?" with a postfunction to change the security level to Private. Once the security level is private, the generic user cant access the issue, but your staff and customer accounts still can access. If you need the generic account accesing to issues in some status, ensure that all incoming transitions to that status change the security level to public.

HTH

[Christian Riege]

The situation is as follows:

• we have a piece of software that can create JIRA issues
• there's a "generic" user account that is used to create the issues
• the "generic" user account is potentially shared amongst multiple customers, however each customer shall only see his specific issues
• therefore the "generic" account shall not have "Browse" permissions

Creating the issue is not a problem. Modifying the reporter to point to the specific user instead of the generic user is not an issue. Adding attachments does not work.

Using the user's account instead of the "generic" account is _not_ a workable solution as the user's account and his JIRA account might have different password (or are not related at all) because the user's account information is retrieved from the customer's directory server which is not connected to our directory server. And we don't want the user to enter a password for JIRA as that would mean that the functionality to submit a bug report/feature request will not be used as much.

[Peter Van de Voorde]

Hi Oliver,

Does your user have the add attachement permission?

Just wondering,

Peter

[Deleted user]

Yes, the user has the "add attachment" permission. It all works as expected when he also has the "browse" permission.

Regards,
Oliver

[Peter Van de Voorde]

Maybe the implementation of addAttachements contains a call to the getIssue method that fails when you don't have browse permissions? Do you have the sourcecode of the issueClient ?

[Deleted user]

Yes, I do have the source. I don't see any call to getIssue, just creating multi part POST data and a call to "postFileMultiPart(multiPartInput, attachmentsUri);", so I assume that this is just the actual HTTP REST call to the API. :-/

[Peter Van de Voorde]

Then maybe it really is an issue within Jira or JRJC 1.0.

I can't really help you any further, I'm sorry.

At least you still have the workaround with browse permissions.

best regards,

Peter

[Deleted user]

Thanks anyway. :-)