Limit changing of start and end date to specific users/roles

[Marco Trosi]

Hi everyone,

we have the use case that the team lead is doing the task and release planning. And from time to time it happens that my colleagues accidentally or intentionally change the start and end dates (and maybe due dates). If you ask "how can this happen accidentally - it might happen in the graphical timeline view like in Big Picture I guess.

So there was the idea to allow only specific people/roles to change these start/end/due dates.

I'm not aware of being able to configure such permissions per field, to my knowledge it can be done only for the whole item/issue type.

How are others handling that? Are there solutions already available? Is this something for a feature request?

Thanks in advance to everyone

--marco

[Moses Thomas]

@Marco Trosi  

You can consider doing the following:

1. Create a new project role called Sprint Manager.

2. In the corresponding permission scheme, assign the 'Manage Sprints' permission to the Sprint Manager project role.

3. Associate the permission scheme with the corresponding projects in your instance.

4. Add the appropriate users to the Sprint Manager project role.

The 'Manage Sprints' permission (only available to Jira Software users) is a project permission that allows users to perform the following sprint-related actions:

• Creating sprints

• Reopening sprints

• Start/Complete/Edit

• Reordering future sprints

• Deleting future sprints

• Moving the sprint footer

The start/complete sprint  and Edit sprint have their own permission in latest version (Server/ DC)

Kind regards,

Moses

[Marco Trosi]

Hello @Moses Thomas , 

thanks for your reply. But I guess it wont work. I also forwarded your answer also to our IT, and they told me that it doesn't help because I only want to restrict editing the start/end/due date fields.

Unless we are not fully understanding your proposal.

Thank you anyway

--marco

[Moses Thomas]

@Marco Trosi  Do you have the  Adaptavist script runner plugin?

Kind regards,

Moses

[Marco Trosi]

@Moses Thomas I asked IT and they said yes, yes we have this plugin.

[Moses Thomas]

@Marco Trosi  I think the easiest way is to limit the Edit sprint permission to certain  role

[Marco Trosi]

okay, so what I hear is that it's not possible. Of course I want that users are able to edit their tasks, and epics etc. , so it's either all or nothing via the role you proposed, but single fields can not be disallowed to be edited.
Thank you @Moses Thomas for your support, I think we can close this thread.

Task failed successfully :D

[Moses Thomas]

@Marco Trosi  If you limit the edit sprint role this will prevent users from edit the start end end dates which are the main fields on the Edit sprint interface.  This will not block users from Editing task, and epics....etc   since we have a separate permission for that which is the Edit permission.

[Marco Trosi]

@Moses Thomas I know that it can be done for sprints, tasks, epics separately. That is clear.
But I need that within one type, for example for tasks, one user can edit everything including the start/end date (the team lead that is doing the planning), and the developer can edit the task too except for start/end date.
And from your explanation I can hear it is not possible. Because I can set the permission per type and role, but not for single fields within that type of issue e.g tasks.

[Marco Trosi]

and I'm really sorry if I'm constantly explaining badly or misunderstanding your ideas.

[Moses Thomas]

@Marco Trosi   Aha now i see ..  I think it could  be possible but with  Behaviours from script runner i will need some time to look, which i have less.

[Marco Trosi]

@Moses Thomas I'm still interested in your script runner solution, but I also came up with a potential weak workaround.

First I thought that Baselines in the BigPicture Gantt are something like checkpoints to which I can go back to, just in case we messed up the planning.

But it turns out that Baselines are just a kind of visual reference to see the initial planning. I learned there are possibilities to export Baselines as CSV and re-import them etc., but we won't go down that rabbit hole.

So my workaround is to create a Baseline and to display only tasks which deviate from their Baseline date. But I couldn't make it work.
This is my quickfilter query ...

"Baseline start date" != "Start Date" OR "Baseline end date" != "End Date"

The query itself gets accepted but it doesn't work when selected in the Gantt View. No tasks match which leads to an empty board.

I also noticed there is "Start date" with lower case 'd', but I don't know what the difference is or if this is something we created in our config or if's coming from Atlassian.

Can you make it work on your side?

thanks

marco

[Marco Trosi]

Hello @Moses Thomas 

regarding my previous message and the filter workaround

I was able to run the following search query in BigPicture

issueFunction in dateCompare("", "Baseline start date < Start date") OR issueFunction in dateCompare("", "Baseline start date > Start date")

But the same query doesnt work as Quickfilter in BigPicture. It gives me the error message "this field can't contain HTML tags".

Also I had to use < and > instead of != as it didn't give results.

do you know why the filter is not accepted as Quickfilter in BigPicture, and works only as search filter? What is the difference between a search and a quickfilter?

thanks

[Marco Trosi]

hello @Moses Thomas 

is the period mode set to "locked" something that would fix our problem?

https://wiki.softwareplant.com/doc/all/box-modules/cross-module-features/scheduling/manual-and-auto-scheduling/period-mode

I'm still interested in the filter from my previous message

[Marco Trosi]

hello @Anna-BigPicture 

I saw you around here. Would you be able to make the filter work from my previous message (7. Feb) ?

I was only able to run it as a Search but not as a Quickfilter, due to the error message  "this field can't contain HTML tags"

Any input is appreciated

Thx :-)

[Anna-BigPicture]

Hi @Marco Trosi ,

I took a closer look at this unexpected behavior. 

Please be informed that it results from an error already identified by our Dev Team.

We fully understand the urgency of the situation, and therefore currently, we are intensively working on a fix.

You can expect the fix in the next bugfix release.