Holger Waschke

Is this implementation only for [Jira Cloud ](https://developer.atlassian.com/cloud/jira/platform/rest/v3/intro/#about) or can I still use the on-premise API with a PAT Authentication?

I can help as maintainer aswell if help is needed. We use jiralert in a large environment.

yes auto_resolve works here, one thing which is a bit tricky you have to define a transition and not a state see[ atl docs here](https://support.atlassian.com/jira-cloud-administration/docs/work-with-issue-workflows/) As far for the error...

I an error `assignment to entry in nil map` ```  ./jiralert -listen-address 0.0.0.0:9099 -hash-jira-label level=info ts=2023-10-18T12:35:04.436816899Z caller=main.go:65 msg="starting JIRAlert" version="" level=info ts=2023-10-18T12:35:04.436879529Z caller=config.go:62 msg="loading configuration" path=config/jiralert.yml level=info ts=2023-10-18T12:35:04.437967933Z caller=main.go:135 msg=listening...

It really was only a missing map initialization `c.jira = map[string]*jira.Client{}`

> this is also important due to upcoming rate-limiting https://developer.atlassian.com/cloud/jira/platform/rate-limiting/ tbh this sounds to me like it will be mandatory to have some kind of back off mechanism to avoid...

> I like this idea, but I'm wondering if we should have a more generic implementation. I'm less familiar with the Jira integration than I should be, honestly. Are there...

@Spaceman1701 I implemented your suggestion. The unmarshalling remains backward-compatible, so nothing breaks — both formats are now supported: ``` # Old/legacy format (just a string) summary: '{{ template "jira.default.summary" ....

Built in more improvements - improved log output when updating existing issues debug output will now print out which labels are being skipped, e.g. > level=DEBUG source=jira.go:119 msg="updating existing issue...

> > This ensures that the resulting hash uniquely identifies an issue based solely on alert labels, independent of the Jira project. > > I'm not sure this is true...