Prince Nyeche - ELFAPP Atlassian Partner

Why do you use base64 to the credential? You can just use it directly with the HTTPBasicAuth class from the requests.auth module and pass the auth request to the headers instead.

Depending on what programming language you're creating the cloud app on, you can simply use Heroku or any other PaaS platform.

That's true. Definitely an approach I'm taking with all my new scripts and functions as proper error handling actually helps to point out without a doubt where the problem lies. Thanks for the insight.

Hey folks about the 400 error on bulk delete issue. I've added an update to the app so the audit log will give out more reasons why it fails rather than just stating 400 error. The reason should provide an answer to the cause of the 400 error. I believe with that, it should resolve the issue.

Hey @Robert Rodrigues Glad to know you've gotten a clearer message of the error by returning the response content. Usually the response content should contain additional information about the error and why it happens.

Is there a specific use case why you need this field available on the Jira issue create screen? Probably you can use a custom field to achieve your aim and copy the value from that custom field into the request participant field via automation for Jira after the issue is created. However, understanding the use case will…

You might want to check if the problem is one of two issues listed on this KB article.

If you're referring to this endpoint it should return a response if successful. Take note that it can be accessed anonymously too, so you have to ensure that you've done proper authentication to the resource to remove any ambiguity in the request.

Not possible, that field is not meant to be visible on a Jira issue create screen.

Hey @Tabitha Lay Just to get more clarity, are you able to use the single delete feature within BulkOps app for Jira to delete a single user or do you still get the 403 error?

The OAuth 2.0 token has a lifetime of 1hr if I'm not mistaken. So you might want to reauthenticate or use a refresh token instead, so you do not have to reauth all the time (which I think is too much of a hassle if that happens).

Hey @Tabitha Lay A 403 error for a user delete action is referring to a permission issue. You might want to check the account that you registered with, if such account has the site-admin privilege. As a site-admin account is one that is capable of deleting users.

I think you can start by making a distinction of what both accounts can do on Jira (Personal vs company). Do they have similar privilege to control or administer Jira? API token once created will work. If the token generated from your company account doesn't work on the program you intended it for, then checking the…

I think I know what the problem might be. It seems to be a character encoding with windows system, it has to be explicit when reading files too. I'll push an update to v0.6.4 soon. As I have new features that comes with that update.

Are there any logs to your result of script when you run it? Indicating why it's not working. You should probably log the value of ${input1CfIddate} and ${input2CfIddate} OR You can log out the value of output that way you can see what the results are at that point in your code and if the data structure is a datetime type…

The library has an example code on how to create issues here, you should try that out first. Also, the official Atlassian documentation for create issue has a php example. Probably worth checking if you want something basic. I believe the best place to check when it comes to video guide is to search on Youtube. However,…

Yes, you most definitely need to be on a premium plan to use Advanced roadmap. Good luck with your configuration.

You can use a different API of jiraone to get a report of attachments on each issue called PROJECT.get_attachments_on_projects That API returns the total number of attachments based on JQL with a direct URL to where those attachments are on your instance. See an example code of how to request the API from this article. In…

You will need to store the binary data of the attachment temporarily before pushing the data into your external API (i.e download then upload). I believe Scriptrunner limits in-memory usage, so you might not be able to simply just do a transfer except, you simply just want to post a string of the attachment location.

That endpoint will return all custom fields within Jira. Are you able to count the total number of custom fields that is returned and compare with the number you have on your instance?

I think the problem might lie with substitution. Probably you need to wrap the --data argument within double quotes and escape the double quotes within the data that is passed. --data "{\"fields\": \"$1 at $2\" } "

You can download or rather I would say, fetch ticket information using JQL search api if you want to be precise. The API supports any number of data manipulation, so your use case is very much achievable with the API.

Yes, that would most probably be it. The datetime value should be a string in UTC or probably any other compatible datetime format rather than that. Try changing the value and perform a single import to be certain.

Advanced roadmap mostly works well with Jira software. However, you can use it across other Jira applications to plan your projects at a higher level by creating a plan. The issues are sourced from a filter that you have on Jira and those issues are then rendered on the Advanced roadmap plan. From what I understood from…

The error seems to be that it cannot convert the datetime that you're using on a field on that TDP-28 issue key. You have to check out the kind of data that's there and probably change it so it is something that Jira can understand. A list of acceptable datetime follows this mechanism in Java format. 

I think you must be using the non-admin CSV importer from the on-set. Probably the one used from the Advanced issue navigation search page (i.e. Advanced filter search screen). The CSV importer from the Jira administrator settings under system has a 1K limitation. 

Before calling the LOGIN alias since you're connected to a Jira server instance do the below # previous login variables LOGIN.api = False LOGIN(user=user, password=password, url=link) As Jira server still uses v2 of Atlassian API. The attribute `LOGIN.api` changes the endpoints from api `v3` which works on cloud to…

If you're on cloud, you might be surprised that as a Jira Admin if your project uses project role in the permission scheme, you might not have as much permission as you might think. Especially if you're not added as a default member on those project roles. I think the error speaks for itself when it mentions does not exist…

Hey Andrew, Great question. To get the authentication to work, you need to instantiate the LOGIN alias or class once hence the call # previous login variables LOGIN(user=user, password=password, url=link) Once that is done, you can access all the objects accessible to that class from anywhere within the code. The LOGIN…

Is it affecting all users or only a small set of users? However, looking at the image, this seems like a local network issue rather than a Jira problem. Are these users connected to any vpn or proxy that might be contributing to this issue? I believe you should check that out first.