In addition to granting your ServiceAccount with permissions to use the privileged SCC, you should add some securityContext.privileged: true to your Pod definition. Otherwise, the restricted SCC first matches your Pod securityContext, privileged would not be considered.
I couldn't find this in 4.x docs, though you'ld have it in 3.11:
Changing priorities could indeed be a way to work around this.
Though probably not something to recommend.
If you made a copy of the existing privileged SCC, then there's good chances you kept its lists of allowed users / groups.
This means that when Pods relying on those SA would next restart, while not including a securityContext.privileged in their definition: they would mistakenly start as root. Rolling this back could require chowning files back on persistent volumes.
While it is unlikely OpenShift core components would include ServiceAccounts running both privileged and unprivileged Pods (not certain/to check), it could still be a surprise for users in your cluster.
This is not a big deal, on a lab, if you're just testing something on your own, ... though I would avoid this on real-life clusters, or warn other admins at least, ideally make sure only your Jira SA may use that SCC.