The Product team here at KaiNexus is driven by the desire to continuously improve our software - and our best source of ideas for improvement comes from YOU, our customers. Whenever you submit an improvement idea for us via the web or through a person on our team, it’s immediately logged for our Product team to review and consider in future development plans.

Sometimes, we hear the same idea from a bunch of you - and that’s when it’s immediately clear that there’s a no-brainer opportunity to make KaiNexus better, and we have to jump on it.

For example, a lot of you have reached out lately about how a Facilitator is able to delete a Project. We originally thought that more flexibility is better - but when you all started pointing out how you can have these elaborate, long-term, complex Projects that someone can delete willy-nilly, that’s a serious problem… and, you’re right!

The need to delete an item in KaiNexus is rare, because generally, you want to preserve the record of that item and who submitted it even if you don’t intend to implement it. In most cases, the correct action is to archive the item, rather than to delete it.

This prompted us to take a look at how permissions work in KaiNexus, and we found several related areas to improve too, including who can edit Project due dates and what items different people are allowed to nest. In this post I’ll go into the nitty gritty details of how these changes impact different types of Workflows.

Projects

Due Dates

Currently, Sponsors and Leaders are unable to edit dates on Projects. When these permissions changes go into effect in our next release, they’ll join Facilitators in being able to edit dates as well as transition the Project to any status (Active, Planned, etc).

Nested Items

Currently, Project Participants are only allowed to submit nested Improvements and Incidents. We’re expanding their capabilities by also allowing them to submit nested Tasks to Projects.

Deleting Projects and Making Them Private

Ok, here’s where it gets tricky. Stay with me. Currently, there are two avenues for a User being allowed to delete Projects and make them private:

1. They’re a Facilitator on a Project, OR
2. At the System Role level, they have Edit permissions on Projects - enabling them to delete Projects or make them private regardless of their position on the Project team.

This needs to change because it makes it too easy to permanently lose data by accident. It’s impossible to un-delete an item, even if someone deleted it who shouldn’t have - so that permission needs to be more restricted. Similarly, we need to limit the ability of people to make items private, thereby hiding them from people who, in reality, should always have access to them.

Our next release solves these issues by requiring that, in order to delete a Project or make it Private, a person must have

1. Be a Sponsor, Leader, or Facilitator on the Project OR have Project Edit permissions enabled at the System Role level
   
   AND
   
   
2. Have the relevant permission enabled at the System Role level (either Delete or Toggle Private, depending on which you want them to be able to do).

See the difference there? You used to be allowed to make these changes by qualifying in criteria one - but now, you ALSO have to qualify in criteria two. This means that Project Facilitators can’t delete Projects or make them private solely on the basis of their role on the Team. Similarly, people who are allowed to Edit a Project in the system are not allowed to delete Projects or make them Private unless they have the special Delete or Toggle Private permissions enabled at the System Role level.

This could be annoying for people who need to be able to delete their OWN Projects, but not anyone else’s - so we’ve added an extra option in the System Role settings that allows admins to restrict Delete and Make Private permissions to include only the User’s OWN Projects.

Improvements & Incidents

Currently, Collaborators are allowed to delete Improvements and Incidents, if they have a System Role with the Delete permission. This will no longer be the case. In the future, Improvements and Incidents can only be deleted or made private by Users who:

1. Are the Author, Assigner, or Responsible on the Improvement / Incident OR have Improvement / Incident Edit permissions enabled at the System Role level
   
   AND
   
   
2. Have the relevant permission enabled at the System Role level (either Delete or Toggle Private, depending on which you want them to be able to do).

As with Projects, admins are able to enable Users to delete just their own Improvements and Incidents at the System Role level.

Tasks

Currently, Task Authors, Assigners, Responsibles, and Collaborators can all delete Tasks and make them private. With these permissions updates, in order to delete Tasks or make them private, Users must:

1. Be the Author, Assigner, and Responsible OR have Tasks Edit permissions enabled at the System Role level
   
   AND
   
   
2. Have the relevant permission enabled at the System Role level (either Delete or Toggle Private, depending on which you want them to be able to do).

See a pattern here? Collaborators can’t delete Items or make them private, and Users can’t perform these actions without explicit permission being granted at the System Role level.

This pattern carries on to Charts -

Charts

Currently, if you’re the Author of a Chart, you can delete it and make it private. With these improvements to how permissions work, you can only perform these actions if:

1. You’re the Author of the Chart OR have the Charts Edit permission at the System Role level
   
   AND
   
   
2. Have the relevant permission enabled at the System Role level (either Delete or Toggle Private, depending on which you want them to be able to do).

PHEW! That was a lot. Hopefully you’ll notice the improved consistency between workflow permissions, and appreciate the added buffer to prevent Items from disappearing.

Don't Panic

The most common question I expect we’ll see after this release is

“I used to be able to delete XYZ and make it private, but now I can’t! How do I fix it?”

And the answer to that is simple -

Have an admin edit your System Role permissions to select the Delete and/or Make Private checkbox and select the “Only User’s” option. This will enable you to Delete your own items, just like you could before.

For more information about KaiNexus Permissions for each Workflow type, check out this PDF outlining all of the KaiNexus Team Role permissions.