+ Start a Discussion
admintrmpadmintrmp 

Beserk - Permissions have stopped working!

A completely beserk thing has happened on my instance of the DE of Salesforce.

 

The permissions for both new tabs and objects has completely stopped working for Standard Platform users profile. Current tabs and objects are working fine.

 

I have around 8 custom tabs and under 20 objects on my app.

 

I may need more custom tabs at some point but my main focus is to get SOQL queries to work on an object which chooses not to.

 

The permissions are correctly setup as always.

The tab permissions have been fiddled around.

I've deleted and redone entire objects and they still don't work.

 

As a System Administrator, all this works absolutely fine for me and the permissions are set correctly. This is not a code problem but a general salesforce development issue.

 

Anyone have any ideas?

Best Answer chosen by Admin (Salesforce Developers) 
atormanatorman

Thank you Warewolf for responding.

 

@admintrmp - has your DE org been upgraded to Spring '10? If so, you'll find that when you create net new custom objects, the object permissions default off. 

 

The reason for this is that many of our customers were inadvertantly giving full access to all newly created objects to all users which resulted in users having more access than appropriate by default.  To compound that, standard profiles are non-editable which meant that the full access could not be removed from them, only from custom profiles. 

 

As a result, we changed the default behavior for net new custom objects in Spring '10 so that object permissions default off for Enterprise, Unlimited, and Developer Edition (Professional and Group Edition continue to default permissions on since it's not possible to create custom profiles in these editions).

 

Because tab access is tied to read object permissions, if you can't have read on an object, you can't access the tab.  The reason why System Administrator will continue to work is because Modify All Data assumes full access to all objects.

 

I would try creating custom profiles which give you the maximum flexibility configuring permissions.

 

Is there a reason why you would not be able to create custom profiles from your standard ones? Are you using the DE org to package for the AppExchange? Are you running any apex that requires standard profiles to have custom objects?

 

Thanks!

 

Adam

All Answers

werewolfwerewolf
Can you not just make a custom profile, turn on the permissions you want in that, and set your user to that profile?
atormanatorman

Thank you Warewolf for responding.

 

@admintrmp - has your DE org been upgraded to Spring '10? If so, you'll find that when you create net new custom objects, the object permissions default off. 

 

The reason for this is that many of our customers were inadvertantly giving full access to all newly created objects to all users which resulted in users having more access than appropriate by default.  To compound that, standard profiles are non-editable which meant that the full access could not be removed from them, only from custom profiles. 

 

As a result, we changed the default behavior for net new custom objects in Spring '10 so that object permissions default off for Enterprise, Unlimited, and Developer Edition (Professional and Group Edition continue to default permissions on since it's not possible to create custom profiles in these editions).

 

Because tab access is tied to read object permissions, if you can't have read on an object, you can't access the tab.  The reason why System Administrator will continue to work is because Modify All Data assumes full access to all objects.

 

I would try creating custom profiles which give you the maximum flexibility configuring permissions.

 

Is there a reason why you would not be able to create custom profiles from your standard ones? Are you using the DE org to package for the AppExchange? Are you running any apex that requires standard profiles to have custom objects?

 

Thanks!

 

Adam

This was selected as the best answer
admintrmpadmintrmp

Thanks for your reply.

 

Can custom profiles be submitted into a managed package then?

 

This explains why half the options are disabled!

admintrmpadmintrmp

Okay, I've just had a further look into what can be packaged and it seems that custom profile settings can be applied to specified profiles on installation. This all makes sense to me and I'll be working around this from now on.

 

Thankyou for your help.