I am creating a new employee registration form that must be completed by the manager.
1. the manager fills in the form
2. a request is created
3. the request is shared to few users
The manager must provide all information, such as name, address, AND salary...
However, there is a problem because as i said - after the form is submitted, it is shared with some users – few of them can see the salary, while others cannot.
I have an idea to create a second task (accessible only to authorised persons) alongside the main task (they are linked) - and in this second task in comment leader will place salary - but I am not sure if this is too complicated :P
Is there any option to hide this form field for some users? Or is there any other way to get around this problem?
Community moderators have prevented the ability to post new answers.
Hi @Tomasz Karliński ,
Thank you for your question.
Out-of-the-box is not possible to hide a field depending on user / user roles in a single work item.
The way to create a linked work item, with a specific work type, could work; using the security schema levels you can restrict the access of that kind of work item to selected users.
An alternative way is using Scriptrunner Behaviours from marketplace: https://docs.adaptavist.com/sr4jc/latest/features/behaviours
Hope it helps.
Regards
Behaviours can do this, but they don't work from portal side. They only work when an issue is created from then backend by an agent.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Yes @Marc -Devoteam- , I confirm it. Despite of hiding the salary field in the agent view, it remain visible from the portal view and all the agent with access could see it.
As you mentioned in your reply, probably it is better to separate completely the employee data from the sensitive data.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi Tomasz,
If you have the ScriptRunner for Jira Cloud plugin, then the Behaviours feature can achieve this use case.
Using behaviours, you can hide fields using the setVisible() method on the create view or issue view, and you can do this based on whether users are in a specific group or project role.
We have some examples of making fields read-only based on groups and roles here and here that you could use as a reference to help create the script that you require.
It is worth mentioning that currently, behaviours in Jira cloud do not work for Jira Service Management projects, but support for these will be coming in the near future, so keep an eye on the release notes to see when this is released.
I hope this information helps.
Regards,
Kristian
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi @Tomasz Karliński ,
As Mateo mentioned, you could use security levels. Additionally, and specifically related to forms, you could use forms restrictions. But, this wouldn't restrict Jira fields (as displayed in the notice at the bottom of the article).
There are a couple of feature suggestions that might be relevant to your requirement:
But yeah, mainly people use Marketplace solutions to achieve field-level security.
Cheers,
Tobi
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
For me personal it would be the question, why aks/store salary?
Isn't this GDPR information only for the employee/manager and HR?
I would not store this in Jira.
As a solution you could create a linked task where issue security is set or create a different project where this task lives and issue security is set.
Then you can even have issue security and project related permissions to prevent unauthorised people to get access. You could even base the permission scheme of the project on groups and not on roles, to even tighten security.
But I still wonder why store this personal GDPR related info in Jira?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Creating a second restricted work item technically works, but if you want to keep everything in one work item, you could try our field security app, Protected Custom Fields.
You can use it to restrict specific custom fields to specific user groups. It’s completely free and very simple to set this up:
1. Create a new protected number field for salary (Work items > Fields > Create new field, then select the Protected Custom Fields number type).
2. Give your relevant user group (e.g., HR, finance, line managers) access to that field in from the app's settings screen.
If you have access, you can reveal the field:
If you don't, you can't see what's stored in the field:
Naturally, you can have multiple protected fields assigned to multiple user groups on one work item, so it's as flexible as you need it to be.
Hope this helps and happy to answer any questions if you try the app. 💪
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Community moderators have prevented the ability to post new answers.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.