Open klappradla opened 1 year ago
Hmm, we could also simply exclude the server adapter from any atlassian.net
domain 🤷
After all it felt not too bad to separate them, since they all have their own complexity (the cloud adapter needs to handle the markdown content but does not care about nested server paths e.g.)
I also think like the cloud adapter could live with a way easier regex that the one it has now etc.
Also an option @andreasknoepfle 👍
I just put down the current state of the discussion in the issue. Didn't want to exclude any other options.
As it turns out, Atlassian is discontinuing Jira Server anyways: https://www.atlassian.com/migration/assess/journey-to-cloud
We could mark the Jira Server adapter as "legacy" and at some point completely drop it.
Support for Server products ended on Feb. 15, 2024
Does not say anything about how long people may still be running the software though...
While working on #349 we split out the Jira adapter into two separate adapters,
jira-server
andjira-cloud
in https://github.com/bitcrowd/tickety-tick/pull/354. However, due to tickety-tick going through all adapter for a page concurrently and the deciding factor for thejira-server
adapter also works for Jira cloud, we can't guarantee that thejira-server
adapter will only apply for Jira Server instances, but also for Cloud.This is fine for now, as the extension is not "broken" for Jira any more. Still, it would make sense to fix that with a more deterministic solution. See this comment for some background.
The idea is: combine the two Jira adapters in one and bake the decision for which API to use in there. (Note: this does not mean there can't be two Jira adapters -
search
should just talk to one singular entry point for Jira).