Skip to content

Conversation

@aditi-kantata
Copy link

Enable the support for v2 search as well, as for some clients using on-prem server for jira, v3 is not yet supported. The client can call jql_v2 and the gem would hit the v2 search api.

@aditi-kantata aditi-kantata changed the base branch from IE-1122-new_jira_apis to master August 1, 2025 11:46
@aditi-kantata aditi-kantata changed the base branch from master to IE-1122_update_deprecated_jira_apis August 1, 2025 11:49
@aditi-kantata aditi-kantata requested a review from a team August 1, 2025 11:52
@aditi-kantata aditi-kantata self-assigned this Aug 1, 2025
Copy link

@ajitkantata ajitkantata left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@ajitkantata ajitkantata requested a review from a team August 8, 2025 04:59
Copy link
Collaborator

@b6b b6b left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like bringing back the old implementation 👍

@mavenlink/integrations-solutions The one thought I have is that this unfortunately just moves old behavior to a different method instead of keeping it fully compatible. It will be a bit of an annoyance changing things again, but what does everyone thing of preferring to keep this self.jql and updating the v3 search to be self.jql_v3?

Copy link

@ananta0799 ananta0799 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@aditi-kantata
Copy link
Author

I like bringing back the old implementation 👍

@mavenlink/integrations-solutions The one thought I have is that this unfortunately just moves old behavior to a different method instead of keeping it fully compatible. It will be a bit of an annoyance changing things again, but what does everyone thing of preferring to keep this self.jql and updating the v3 search to be self.jql_v3?

Thats interesting, but why I kept the v3 as self.jql is because, going forward that will become the default and v2 could be mentioned explicitly holding only for a few calls.

@Theotata
Copy link

Theotata commented Aug 8, 2025

I like bringing back the old implementation 👍
@mavenlink/integrations-solutions The one thought I have is that this unfortunately just moves old behavior to a different method instead of keeping it fully compatible. It will be a bit of an annoyance changing things again, but what does everyone thing of preferring to keep this self.jql and updating the v3 search to be self.jql_v3?

Thats interesting, but why I kept the v3 as self.jql is because, going forward that will become the default and v2 could be mentioned explicitly holding only for a few calls.

I understand that v3 will be the default for search but reviewing the pattern on your other PR, I think self.jql_v3 makes it clearer that this is part of the phased migration to v3 rather than being part of the "baseline/majority" version. I'm kinda ok either way but slightly leaning on self.jql_v3
from PR

@aditi-kantata aditi-kantata merged commit ba6db83 into IE-1122_update_deprecated_jira_apis Aug 8, 2025
1 check passed
@aditi-kantata aditi-kantata deleted the keep_v2_support_for_search branch August 8, 2025 15:53
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Development

Successfully merging this pull request may close these issues.

6 participants