We strongly recommend to get the rank issue permission separated from Due date connection because in our project, we are using Due date as mandatory field in create screen for custom issuetypes such as Action, Decision, Deliverable, which uses kanban board (no use of ranking) and we do use Story & Task issuetypes that uses scrum board (ranking permission is needed for few users) within the same project.
We want to keep Due date accessible for entire project and allow only scrum master's to rank the backlog issues.

In the Atlassian requests there is JSWSERVER-6887.
This is in a board name 'AlpTest'.
This board seems to contain requests from as far back as 2012, with things like 'Allow backlog to collapse', which is something that was implemented years ago but is still in 'Gathering Interest'
This suggests that the board is an old test board and the suggestions are not being looked at.
It would be good if JSWSERVER-6887 could be looked at, as it was created in 2012.
Currently we restrict the 'Schedule Issues' permission to certain managers so that developers cannot change the rank order of issues.
But this stops developers moving issues in to sprints, which means more work for the managers moving issues in to sprints for the developers.
Moving issues in to sprints and changing ranks need to be 2 separate permissions.
JSWSERVER-6887 covers this request, but has not been looked at or responded to for many years.
Users need to be able to put their issues in to a sprint without changing the rank. By restricting rank, we are also restricting users from putting issues in to a sprint. They are unable to manage their workload for current and future sprints.

We absolutely need a separate permission for ranking. No dependencies. It is ridiculous, Users who create Issues in our project shouldn't be able to rank just because they can set a due date. 

Scenario:

I have a feature request needed by May 4th, 2024. Therefore I create an issue, rank set the due date and (now the logic breaks apart) accordingly to my importance I rank it higher ignoring all previously ranked issues, to ensure it will be done next week.

We need Product Owners / Project Leads to be able to rank issues. Others should be able to submit a due date but not to consider in which order the issues will be planned and worked on.

Don't neglect this as a small deficit Jira has,...

My company has a Client Services rep who needs to be able to rank issues on the kanban board set up for managing her client's requests.

However, she should not be able to Schedule an issue. (She shouldn't be able to Resolve one either; however, when I tested giving her user that permission, it didn't allow her user to rank issues anyway.) 

So I have to give her the ability to change Due Dates, just so she can rank her client's requests. Really unfortunate!

Definitely need a separate permission - or better yet, a change in the permission required to rank issues to something that more team members already have.

I totally agree that we need to separate the permission to add stories to a sprint from ranking the backlog. We only want Product Owners to rank the backlog but we don't want them adding stories to sprints. Dev Team members should be adding stories to sprint but should not be able to rank stories. Due to the interface it is actually quite easy to change the ranking by accident so another reason to limit this permission to a small set of users.

The ability to split these permissions would really help to build confidence in JIRA and I would say it is the highest priority change in JIRA that I am currently aware.

Now with the new Manage Sprint permission and the agile integration in JIRA Software, it really makes sense to continue to sever the permisisons needs for agile feature from the traditional JIRA ones, such as distinguishing the ability to Schedule Issues from the ability to Rank the backlog.

I need to allow our software developers to create or remove subtasks, but they should never be able to change the order of the stories in the backlog. Currently it's very easy for someone to accidentally drag/drop a story out of order. I have no way to control this. I also need this ability to be limited to a specific board.

with larger organizations the assumption that anyone who can schedule permissions can also rank the backlog is troublesome. If a team has adopted the standard Scrum process whereby the Product Owner gets to rank the backlog and other in the team follow it, then who can rank should be allowed to be controlled separately from the other permissions.

I want to put this out there, implementing this permission correctly is key to extending the usage! This must be associated to the global rank field titled Rank.

Currently the Schedule Permission is associated with the operation of ranking issues, literally the dragging and dropping of issues on Scrum and Kanban boards. However, this doesn't work well with the custom rank fields we can use, per the implementation of GHS-3723. If the new Rank Permission is tied to the global rank field titled Rank instead of the ranking operation, then we can extend Boards in JIRA further. My 2¢.

This is a serious issue as we'd like our engineers to have the ability to add/remove tasks, but they should not be able to change the ranking of them. Currently adding to a sprint is also based off of this permission.