How do I hide the ability to edit SKUID pages?

Hi Joseph, there’s a few things we’ve done that might help:

- make the Skuid app not visible (uncheck the box) in the user’s profile settings.
- remove the tab visibility for that user profile
- remove the ‘edit’ gear button on production pages using this snippet: https://community.skuid.com/t/remove-gear-page-edit-button-for-oem-customer-system-adm…
- Put your production pages into a module, and then prevent pages in that module from being edited with the triggers & classes outlined here: http://help.skuidify.com/m/11217/l/121145-packaging-your-skuid-pages

Ultimately a system admin is still going to be able to put all these settings back on, but if you remove the visibility for the package and tabs, then at least its ‘out of sight, out of mind’.

The reason that your users can still edit Skuid Pages is that their Profile has Edit rights on the Skuid Page object.

There are only two ways in Salesforce for a user to grant a user Edit rights on a type of object: via the user’s Profile, or by assigning the user a Permission Set. Since you don’t have Permission Sets assigned to these users, their Profile must be granting them Edit rights on the Skuid Page object.

It’s very easy to remove this permission from a user’s Profile — go to the Profile in Salesforce Setup, find the Page object’s properties, and un-check the box next to Edit. 

To do this en-masse for multiple Profiles, add the Page: Edit permission to a Profile List View, and then un-check this box en-masse:

Greg / Zach thank you for your suggestions. They were very helpful.

Hi Zach, I’m finding its not possible to remove the ‘edit’ permission on the page object for the System Administrator Profile, and as we are distributing a managed package, our customer will always have a user who has the System Administrator profile. So we can’t remove the edit permission for this user. I’m just wondering if there is another way to override this edit permission for the Admin?

Correct.  The Profiles provided by Salesforce cannot be edited.  If the one user has to use this profile then I’m not sure there is anything we can do. 

You would have to create a custom profile for the system administrator if you wanted to adjust the security profile.  That probably has unwanted implications in other places. 

What I did was hide the gear (similar to the snippet suggestion offered in the top response). I added a CSS Resource called HideSkuidGear, set it to inline and then used this CSS #skuidEditBtn { display:none; } I tested in Chrome and it seems to do the trick of hiding the gear on the production pages. Admins can still edit the SKUID pages by going to SKUID page tab but its good enough for my purposes. Thanks everyone for the help

To follow up on this - is there anyway to hide the skuid pages completely in our managed package from being viewed by users who install it (even the admin in that org)? A lot of the value of our package comes from our Skuid pages, and we would like to be able to protect that in a similar fashion to apex classes in a managed package that show up as hidden when a user tries to view them.

Hi Craig, I’m not sure that’s possible if the admin has full access in that org - if your package is an ISV package then definitely not, but if it’s built as an OEM package (where you sell the core Salesforce license) then there is an argument that you should retain the admin license for that org for yourselves, and then users just have standard user licences and no access to any ‘back-end’ functionality (Assuming your contract with the customer allows for you to retain the Admin license).

If lots of your functionality is done with snippets and custom components then you could use a ‘minifier’ to confuse the visual appearance of the javascript (I haven’t done this myself but have been told its possible) without affecting the functionality of it.

Ultimately I guess it depends how savvy your end user admins are. The Skuid guys might have something else to add here but I don’t think its possible to ‘protect’ skuid pages in the same way Apex is protected in a managed package. Although it would be very awesome if that was possible… 

Thanks for the response Greg. That’s pretty much where we’re at. 99% of our customers will never go into the Skuid editor, its more of a concern of protecting our IP if someone were to try to copy it.

We do have an OEM package but do not retain the admin license for two reasons: 1) we would still have to pay Salesforce for the license and 2) our customers would not look kindly upon us always having access to their org.

I’m always hopeful one of the Skuid wizards will pull some magic out of their hatand come up with a genius solution I had never thought of 🙂