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.
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:
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
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.
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:
As with Projects, admins are able to enable Users to delete just their own Improvements and Incidents at the System Role level.
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:
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 -
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:
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.
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.