Tuncay Senturk _Snapbytes_ Community Champion

You are correct; analyzing the log can be challenging, especially when there are numerous other log items within the same interval. I didn't find anything in your issue history that would cause problems with the indexing in Jira. I apologize for not being more helpful on this matter. It seems that it requires further…

Thanks! Can you share the History tab of the issue to view the status changes over time? Based on the information provided, it is challenging to comment specifically, but there are a few factors to consider regarding Jira's SLA conditions. Sometimes, these conditions may not update due to indexing delays. Recalculating the…

Hi @陈诗 To better assist you, it would be helpful if you could provide the SLA definition and the issue change history for those issues. It would be very helpful to use your browser’s translation option to English before taking the screenshots, as this will allow you to reach more people who can understand the issue.

I’ve never been to a camp, but I believe when I go younger I will :D 

HI @Андрей Atlassian Developer Community is the best place to ask this sort of questions. You'll find a lot of experienced developers there who can provide insights specific to Forge and Jira integrations.

Hi @Marina Maznikova Welcome to the Community! The error message in your screenshot indicates that the JQL query is failing because the project with ID '10028' does not exist. It might no longer be valid or accessible in your instance of Jira. Check your project access or if the project was deleted. If the automation is…

Hi @Ladislav Szalai I trust the Atlassian Developer Community is a better place for this question where you may find more responses.

Hi @Tridev Welcome to the Community! Basic Authentication over HTTPS is generally accepted as secure because HTTPS encrypts the entire communication. So, there shouldn't be anyone intercepting a request and decode. However, for added security, it’s worth exploring OAuth or other token-based methods. As for NDL or other…

Hi @Alban Gueguen Welcome to the Community! I'm not entirely sure I fully understand what you're asking, but if I haven't misunderstood, here's what I would do: To modify the ticket assignment based on the fields filled in the form, - add a branch with a branch rule for the Current Issue and retrieve the field value (edit…

Hi @yuki_shikano Welcome to the Community! The API does not seem to explicitly provide a parameter to set the member's authority (role) as "Admin" in the request body. They are assigned a default role (usually "User"), and I wouldn't expect to assign a user with a default admin role.

Hello @lapacquah_bryant Without an app, it’s nearly impossible to handle out-of-office assignments effectively, as it requires a system to track availability and intelligently assign tickets. That said, @Lucas Modzelewski _Lumo_ 's comment is helpful! I also wanted to mention SnapAssign - Smart Assignments for Jira, which…

Hi @PR23 I don't know if you had any answers to your question but here is my two cents on this. Changing the date format in Jira from d/MMM/yy to d/MMM/yyyy will resolve the issue related to dates beyond 2039. However, as you've mentioned, any existing scripts, project automation rules, or third-party integrations that…

Hi @Ankit kharola Welcome to the Community! What error are you getting? Could you elaborate please? At first glance I'd say, React requires a unique key. You should add a key to the Row component inside the .map method. Also make sure that you're using the issueglance module properly in your manifest file. Last, I'd…

Hi @Simon Larson Your manifest.yml configuration seems fine, and I couldn't see any reason for authentication problems (except for the accountSid and authToken, which are obtained via environment variables). I suggest trying to temporarily hardcode the values to check if the environment variables are the issue. I'd…

This is the updating version REST API, isn't it? 405 means that you are using an Http method which is not allowed. In this case it should be PUT (as documented here). Please make sure that you are using the correct URL and HTTP method.

No problem! I'm glad it worked!

Hi, You can use REST service if you have the ID of the group https://<your-domain>.atlassian.net/rest/api/3/group?groupId=9ebcd482-7683-43d8-add6-5a54528030a4 Please let me know if I am missing any point!

Wow, driving from Utah to Nebraska with just two stops, wow!! My longest car trip was around 14 hours as well, approximately 725 miles. We traveled from Cambridge (UK) to Bournemouth, then to Land's End (Cornwall), followed by Bristol and Bath, and finally back to Cambridge. We made four stops along the way, taking the…

resolutionDate is a special field which is set automatically (not manually unlike other fields) and clearing it will also clear some history. This is what I know about it :)

As far as I remember issue.store is an internal method which you should avoid using, and it is deprecated meaning that it will be removed in the upcoming versions.

I'm glad it helped.

Let's hear from @Ram Kumar Aravindakshan _Adaptavist_ I am inquisitive about it.

Sorry, have you tested https://your-domain.atlassian.net/rest/api/3/version/{{version.id}}

To be honest, that was my expectation. I knew that Jira does not allow the resolutionDate to be cleared. However, after reading the comment by @Ram Kumar Aravindakshan from Adaptavist, I thought I might have been missing something and shared the code without testing, sorry. I'm curious about how Scriptrunner's HAPI…

No problem! :) Yes, that will do the trick.

issue.setResolution(null) if (issue.resolution) { The problem is here. You already set resolution to null, then you check if resolution is not empty. It won't return true.

Hi @Aisha M In Jira, when you clear the resolution field, the resolutiondate field does not get cleared automatically, as this behavior is by design. The resolutiondate field is intended to keep a record of when an issue was resolved, and clearing the resolution field does not affect this historical timestamp. That's why…

You are correct; I overlooked that part. Add advanced branching to iterate over the web response. new action, choose Advanced branching smart value: {{webResponse.body.fromJson}} variable name: version then add if condition in which first value: {{version.releaseDate}} condition: equals second value:…

Hi @Jeff Boon It is tricky but here is what I'd do to automate the release of a fix version based on the scheduled release date. Since it is not straightforward with Jira Cloud's built-in automation features (afaik there is no direct access to the release date), we can use Jira's REST API within the automation rule. - Set…

That's strange; As far as I know, there aren't any limitations in that section. The users with the necessary permissions should be listed there. I apologize for not being helpful.