Clarity

Hi Team,

There is requirement such that -

    a) For group "ABC" users "Delete" button of custom object "X" should be visible and they should be able to edit the data of custom object X.

    b) Whereas users tagged to other groups should not be able to see "Delete" button, but they should be able to edit the data of custom object X.

I tried below options but they never helped to meet my requirement.

Option 1) Delete button can be disabled from UI themes but that will disbale "Delete" button for entire application, so Delete button would not be visible to group "ABC" users also whom it should be visible.

Option 2) By removing "custom object name - Edit all" rights from groups for which "Delete" button should not be shown, this would restrict users from editing the data of object X.

Any ideas friends?

Br,

Sandeep

There's an existing idea (under review):

https://communities.ca.com/ideas/103017974#comment-233929512

NJ

Thanks a lot NJ for quick response.

I have voted for this idea.

Still is there any other workaround we can implement to achieve such requirement now? OR we have to live with it. And ask non ABC group holders not to delete any custom object instances?

Br,

Sandeep

I think so, if the tool does not offer any other option.

NJ

Hi,

I'll voice another option for you that you might want to ponder, I think it has been offered in conversations before, and we've used something similar for our customers.  Did you know that you can't delete a custom object instance if it has an existing sub-object instance?  I think if you gave this "security" sub-object edit rights to the group that you want to allow to delete the master object you'd have a type of work around that you are looking for.  The other group that can only edit the master object would then be 'blocked' from deleting it until the sub-object is removed.

Depending on your needs you could likely setup a process to e-mail / notify people that have the rights to somewhat automate things...

Hope that helps,

B

EDIT - It's not elegant, and I recall there being some other issue with this approach but I can't recall it at this moment, but I figured it might give you something...

see this:

Re: RE: Remove 'Delete" Button from Custom Sub-Object List View

This being said, if you have an on premise system, it can be done through a XSL stylesheet change (XML and XSLT knowledge required). Search for the following file in your Clarity installation:

META-INF\odf\vxsl\custom\subObjectList.xsl

 

Look inside for a line looking like :

<action id="delete" type="button_submit" actionId="odf.deleteObjectInstancesConfirm">

 

Comment the action NODE and ALL delete buttons in ALL sub-object lists are gone.

It is a good idea to include the action-node in an "xsl:choose" construct and test which Sub-Object you have ( /data/odfSubObject/@code = '<sub-object code>') and maybe you should allow the delete button for the admin user ( /data/header/userSession/@userId = 1).

Is it a sub object or master object?