Best practice for private tasks (a user adds issues for himself not necesserely related to projects)

Alex Trebek February 15, 2021

Hello there!

We're gathering information on how to use Jira Software (Data Center) for enterprise-wide deployment in mostly operational business-processes. For around 500 users.

The configuration models for key processes are already defined. Only secondary processes and non-critical requirements now left as open questions.

 

One of them is how to properly organize the configuration of projects, boards, issues (etc) for the ability of a every user to add "private" Issues.

By "private" I mean Issues for Tasks that user wants to add for himself. Those can be related to regular work, but also can be unrelated. I.e. some form of ToDo-list.

 

As far as I understand there are three ways to do that:

1. Set up a new Project for every User with restrictions that only User can add Issues.

2. Set up one Project, but with Security levels. So that any User can add Issues, but you can only watch your own Issues.

3. We are going to use a separate Project for Teams and Departments. Private tasks can be hosted in those Projects, but with more restricted Security Level, so that only Reporter could see them.

 

Could you please help us with advice and opinions on that matter?

Is there any other way to configure the system beside three described options?

Also if the first option is used (Individual Project for each user), would it be detrimental for the performance of the system (as there would be around 500 additional Projects)?

 

3 answers

2 accepted

2 votes
Answer accepted
mogavenasan
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
February 16, 2021

Hi @Alex Trebek,

Jira is not really suited for this scenario. For example, if a user wants a different workflow for their own personal ToDo issues - this will add more maintenance tasks on your Jira Admins. This is just for workflow, imagine the Admin is getting requests from end-users on screens, fields, statuses, Priorities, Resolutions and etc. - this will be a pain for your Jira Admins to be handling. Plus, if you are implementing some of the niche cases on your Jira, the data would be also all over, for example, you might end up with some fields, statuses, Priorities, or Resolutions that are being used by certain small projects only.

The best application I can think of is Trello for ToDo-list - the user can customize it however they want. They have a lot of flexibility in this way.

However, if you really really want to use Jira for this scenario, then I would go for:

3. We are going to use a separate Project for Teams and Departments. Private tasks can be hosted in those Projects, but with more restricted Security Level, so that only Reporter could see them.

You can have a unique issue type, for example; "Personal" and then tie all the schemes around the Issue Type. But yea, you might get some requests to change this and that in the future which you might need to consider.

I hope that this helps.

Thanks,
Moga

Alex Trebek February 18, 2021

Hello @mogavenasan!

Thank you for your answer. It's on point and helpful!

 

Yes, it's quite apparent that Jira is not the best solution for the use-case.

But as I mentioned in the other reply, the plus side is that a user would see the full set of his tasks, not only projects and operations related ones.

 

And yes, for the administrators it could be additional headache. Although I think that it would be reasonable to restrict the customization of those private projects. So that a user could opt to use one, but only in a way the project is standardly configured.

Like mogavenasan likes this
0 votes
Answer accepted
Iago Docando
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
February 16, 2021

Security levels won't work as you intend. They are nested (if that's the correct word).

You would have 500 security levels S1 > S2 > ... > S500 and S1 could see everything, S2 everything but S1, and so on...

Even if you set up a personal project per user, where each user is the proyect leader and only member of the project, site admins could see everything there so it would be " privacy*** ".

Jira is not meant for PERSONAL privacy, it is more centered around TEAM privacy in my opinion. And of course there's no problem having the admins seeing anything regarding any team.

Alex Trebek February 18, 2021

Hello @Iago Docando!

Thank you for your response.

 

I'm not sure why are you saying that security levels won't work.

As far as my experiments go all you need is one scheme with Security Level that restricts view to (for example) Reporter, Assignee and Project lead. A user will not be able to see an Issue if he's not the Reporter / Assignee / Project lead.

Could you please elaborate a little bit on your point about the Security Levels? I'm now slightly worried that I might miss some important side of it :)

 

Also by "private" I don't mean completely private Issues. It's perfectly reasonable if site admin could still see such Issues.

 

 

I totally agree with you that Jira is not really supposed to be used in that way.

But on the other hand it's much more convenient if you can see all of your tasks in one place, not only projects and operations related ones.

And as the system is so malleable I don't see the reason why not try to accommodate the use-case just as an option. In the end it would be a user's choice whether to use it or not.

Iago Docando
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
February 18, 2021

They won't work as you expect because that's not how Security Levels are suposed to work (unless I have missunderstanden you somehow).

You want N security levels for your N users so each user can only see the issues with their security level. Right?

Security levels are actually "tiers" and by "nested" I meant they are in fact a hierarchy, so the higher levels include all the levels below them. That is, if you have the lower security level, X1, and user U1 has that level of privileges he will only see X1 issues... but user U2 with security level X2 (>X1) will be able to see X2 issues aswell as X1 issues.

A project per user doesn't seem quite right... maybe it would be better something radically different like creating a link in jira to an external tool that is actually meant to keep track of this personal tasks. I don't know, the correct decission depends highly on having a deep knowlege about your use case.

Alex Trebek February 18, 2021

>>You want N security levels for your N users so each user can only see the issues with their security level. Right?

 

No. This is not what I meant.

A single Security Level is enough. In a Security Level you can assign permission by Issue roles (Reporter/Assignee), Groups, Project roles and Issue custom fields.

And all you need to make Issue private is to set SL with permissions restricted to Reporter (or additional roles just in case). Once an Issue added with that SL only Reporter will be able to see it. Therefor Issues from different users could be in a single Project in which users can only observe their own Issues.

Like Iago Docando likes this
0 votes
Ilya Gazman
I'm New Here
I'm New Here
Those new to the Atlassian Community have posted less than three times. Give them a warm welcome!
July 25, 2022

How about using Confluence for that? 

I assume that some of your tasks are work-related and some are not. You would probably want a friendly link to the work tasks.

 

With Confluence, you get the nice feature of showing you the task's status, and they have a ton of extensions to manage Jira tasks.

 

And as for the private tasks, you can define them directly on the page, like: "Call Pizza at 7 PM."

Suggest an answer

Log in or Sign up to answer