Is there any updates on this issue?

The below call could help get the Sprint IDs:
https://<Your Instance Name> .atlassian.net/rest/greenhopper/1.0/sprint/picker

It is unacceptable that we must search the id and specify the id.

This must be changed

This needs to be updated! I'm trying to do an integration using FixVersion and this is essential to that workflow.

This is important

I meet this issue frequently, and as the Sprint ID is not readily available without using some kind of hack (such as searching under issues, and writing sprint = "sprint name" and waiting for Jira to auto suggest the sprint ID) this should be prioritized as it is a UX disaster!

Great work on improving Jira over the years though, nothing else comes close 

We found that if you enter the wrong ID into the field it is difficult to undo the effects of the operation. In other words, the ramifications of errors due to a weak UI are fairly pervasive, especially since a bulk operation affects many issues.

It is also the case that the value can be saved to a sprint that is already closed, but if you later edit the issue to remove the closed sprint, you can't...because the sprint is closed. So some conflict in rule scope seems to exist here.

Do we have a roadmap as to when this issue is going to be resolved? It's such a small issue with major ramifications. As Eric said above when using numbered sprints it can get very confusing and you can only get the sprint ID from using the JQL editor as mentioned in GHS-12599.

To add further insult to injury it seems if you go to bulk change in your browser then open up another browser tab to find out the sprint ID and then switch back to the bulk change tab you will bulk change issues which were never originally part of your bulk change

Bulk Edit needs to be made consistent with all of the rest of the places where Sprints are updated (add JIRA, update JIRA, etc), where the Sprint name is used due to the fix of GHS-7573.

Also, as noted it is very difficult to track down the Sprint ID. Nobody is going to remember to do that.

Also this makes using numeric Sprint names problematic. For example, we have sprints named 066, 067, etc. The problem is that it is impossible to use the bulk edit feature with these sprint names because it interprets the numbers as Sprint IDs.

Another problem is that, if you accidentally use a Sprint ID of an old, closed Sprint in bulk change, you cannot remove that sprint from the JIRA. It is stuck on that JIRA forever. You can only add the proper Sprint.