We have a requirement that the user can create a custom object but not allow them to edit it. The Create right includes the navigation and edit rights. So, I am thinking of not to display both ‘Save’ and ‘Save and Return’ buttons when editing an instance of custom object.  

Is this possible? if so, please advise me.

Thanks

Rama

Does anyone have an answer for Rama?

Thanks

Not to display ‘Save’ and ‘Save and Return’ buttons when editing custom object

Ramana Chinnapapannagari May 4, 2015 9:13 AM

We have a requirement that the user can create a custom object but not allow them to edit it. The Create right includes the navigation and edit rights. So, I am thinking of not to display both ‘Save’ and ‘Save and Return’ buttons when editing an instance of custom object. 

Is this possible? if so, please advise me.

Thanks

Rama

Yes Rama,

It is possible!  By granting Create Rights, you will not be able to stop users from editin the instances of a custom object, but there is a work-around.

1. Create a Custom Object & Grant Create Rights to the users via Group

2. Configure the List Layout in such a way that all the important fields of the Custom Objects are listed in the ist Layout Itself

3. Remove any link from the List Layout which will take the users to the Edit Layout, this will stop the user from viewing the Edit Layout, which means you are blocking the users to edit the attributes from the Edit Layout

4. Now uncheck the "Allow Editing" checkbox for all the attribute from the "Object >> View >> List >> Field" screen one by one

Now the users will not be able to edit anything from the list layout neither will they be able to access the edit layout.

If you insist to keep the edit layout open for the users, there is another way,

1. Make the Custom Object "Event Enabled"

2. Create a process on the Custom Object which Auto-Starts on Creation of Instances

3. Create an System Action inside a step with option "Lock All Attributes"

As soon as the user hits save in the Create Layout, all the attributes will be locked and hence the users will not be able to edit any attributes.

Let me know if this helps!

Regards,

Mathan

Another option would be to mark all subpages of the object as secure, and grant only the visualization right to the subpages.

An admin or super user can still edit the objects if you give him the edit rights to the object subpages.

Regards,

Roberto Barra

@Mathan(Matt114),

   Thank you for your suggestions. Already I tried both options/workarounds. First option, still displays the empty edit layout pages when you click 'Save' button on the create screen (but it won't display edit pages when Save and Return button is clicked). That's why, removing 'Save' and 'Save and Return' buttons is better option on edit page.

The custom object has 'Multi Valued Lookup' attribute and the process is not locking this multi-valued lookup attributes but locks others.

@Berra,  Thank you, still the edit page will be displayed with 'Save','Save and Return' and 'Return' buttons without any sections even though all subpages of the object are secured.

The better option is to hide the "'Save' and 'Save and Return'" buttons on the edit page. 

Thanks

Rama

Users with Create rights cannot view content created by others, unless given the instance view right to it.

When a user creates a custom object instance, they are also given the instance edit right to it.

So in a process, you could have a XOG call that checks the user's edit permissions to the object in question and replaces them with view permissions instead.

Then the data will show, but it will be read only to that user, and the only button that will show will be Return.

Due to the nature of process execution this behaviour happens asynchronously, so the user may first be returned back to a page with save / save and return buttons until the process can perform the operation, but it should be a short window of time and may even kick-in before the user can make further changes and click those buttons (just no guarantee that they won't get a minute or two grace period to make changes if the process engine is currently busy).

Alternatively you'll need two objects, one for creating only, which then gets itself copied via process to the other object that users can then edit/view as per the permissions they are given.

There isn't a way at this time to selectively prevent instance creators from configuring the rights an object has post-create in a synchronous (non-process) fashion.