Sooner or later after you done with your initial implementation of K2 question of restricting access to K2 Workspace being brought up by somebody and though your configuration options are not very flexible here there is a way to do it (KB000291), the thing is that you should not rush into making changes into this area without reading documentation first (don’t tell me that it is what you normally do all the time).
What quite often happens here is as soon as a person charged with this task finds “how” part of it he/she rush to configure it without reading into any details, like those mentioned in “Other Considerations” section of KB000291. I believe that mindset “try first, read manual later” which is very popular in IT, somewhat difficult to resist as it is largely being instilled into you by technology itself (both hardware and software), which is and always was built with “fool-proof” design patterns in mind, trying to be forgiving and allow for rollbacks and easy correction and handling of errors. Anyhow people often configure something first, and then comes that moment of “now what/how do I fix this”?
When it comes to K2 blackpearl Workspace security management you should know beforehand the following about the way that the tabs in Workspace function:
1. With a new installation, no-one has explicit permissions, Workspace will function in optimistic security mode, meaning everyone can see the tab.
2. As soon as a user has been assigned explicit permissions on a tab, it will switch to pessimistic security mode. Meaning that a user will need explicit rights to see the tab. If a user is not on the list, they will not be allowed to see it and this is what is occurring in your environment.
So typical error when customizing K2 workspace security is granting rights only to one user (you should never left your admin account without these rights) which may left the company for example, or what we can deem a “double-mistake” here is granting these rights to only one user which in addition doesn’t have admin level rights on K2 server, thus you are leaving yourself with no opportunity for subsequent corrections via normal, GUI way.
In case you haven’t done double-mistake mentioned above you can easily correct this situation. To fix this, you just need to log in as a user who has been granted permissions and then assign permissions to those that you want to grant access (please grant those to your dedicated K2 admin account), using the Workspace Permissions option in the Security tab.
If case you are not sure which user has permissions, have a look at the ActionPermissions table in K2 databse:
SELECT UserName FROM ActionPermissions
WHERE actionid =
(SELECT ID FROM [action] WHERE [name] = 'Management Console')
Made an epic “double-mistake”? I.e. granted rights to one user without server level administrative rights in K2 and now not able to edit permissions despite this user can access required tabs? This means that you are reached the section of KB000291 entitled “Error Resolution” which you supposed to read before playing around with Workspace security settings. And I’m quote this section:
If this happens, it will be necessary to manually modify the SQL databases to reset all Workspace permissions. It will then be necessary to specify all the permissions again. Please contact K2 Support prior to modifying any of the K2 databases or data stored in them.
So you have to reset your permissions to their defaults (no explicit permission, optimistic security mode). It requires direct edits in your K2 DB which is considered to be thing to avoid whenever it is possible and should only be performed by you in case you know what you are doing and more importantly you know how do you rollback your change if anything goes wrong. So you should use do it with full understanding of risks involved.
It will suffice to issue the following SQL server statement against your K2 DB:
TRUNCATE TABLE Workspace.ActionPermission
But you never do this without doing K2 DB backup first and reading preceding couple of paragraphs, right? I really hope so.
Another frequently asked question around K2 workspace permissions is revolving around the fact that you may see that they are not fine-grained enough and not fully in-line with RBAC ideology/approach. To these questions there is no easy answer with current implementation of K2 Workspace but things should become way better with complete overhaul of this part of K2 which is planned to be released at some point, but real particulars of this change and what we get with it are under NDA at this point.
![facebook]( "Share on Facebook")
![google_plus]( "Share on Google+")
![reddit]( "Share on Reddit")
![pinterest]( "Pin it with Pinterest")
![linkedin]( "Share on Linkedin")
![mail]( "Share by email")
Originally posted on 
) and all conceivable prerequisites were double checked I decided to do what you never ever should do, namely to register SharePoint 2013 service instance using SmartObjects Services Tester Tool. Note (for the sake of redundancy): you should never use this tool to add or edit your SharePoint 2013 service instances all of those should be created from SharePoint interface by means of so called “appify” operation.
