A user can delete a content only when that particular user dont have delete permission assigned to the role given to the user.
As a usecase, checkin a content with admin user, create another user which have just read and write permissions but not delete. Login using this new user and try to delete the content. It wont.
Thanks For intention,
I think you did not get my question, Question is that "In check in form when I selected Read Only field as True " the content must not deleted by any one. But I can delete. So things is that Why it is possible when UCM not give authority as describe on the page
Are you referring to a "UCM" field, or a "URM" flag.
I am not aware of any standard field called Read Only. There is, however, a flag in URM called IsEditable.
As Sonal C wrote even standard fields are influenced by permissions - admins with some permissions are authorized to delete an item even if the flag is set (it could be by mistake), but for other users, the flags will work OK. Of course, custom fields will not affect the system's behavior (calling a new field ReadOnly won't guarantee the functionality).
There is a default metadata field called ReadyOnly and its context of usage is Folders_G component. I'm not aware of its usage and benefits.
I guess it's useful when we use DIS.
Though it's available on check-in page there are no values in dropdown in my instance that's may be because we use FrameworkFolders component
Thank you Jiri machotka Sir,
I read your old discussion about the workflow reject message and you said that you have solution in safe of component. Sir I need your help can you share that component with me by which I can show wfRejectedMessage in workflow history or content/doc history.Please Sir help me out, my email id is firstname.lastname@example.org . I hope you will help me on it.
Thank You sir
Thank you for filling a gap in my knowledge :-)
(in my system there are FrameworkFolders, too, and no ReadOnly field)
I no longer have this component, but it should be easy to build. All you need is:
- modify the WorkflowHistory table to have an additional field to store the reject reason
- modify the service triggered by workflow reject to store the reason into this new database field
- modify the workflow form(s) to display the reason
If you are experienced in writing custom components, it's not more than a few hours work. If not, you may start with a tutorial to learn it first - mine is available at Intradoc Services Tutorial, or you may hire someone who will do this work for you (if it's just an one-off task).
Now this is interesting. I dont know why this field is there in check-in page if it's not appearing in your case when you've enabled FrameworkFolders. Please let know if you find any pointers. I'll look out for the possible reason.
It appears that the documentation is wrong. I tested this scenario, and the content item can still be deleted. Furthermore, I don't even see in code where this could work, as I am not able find any reference to the field actually being read.
If you have a need to keep something from being deleted, your safest bet is to not create roles that have "delete" privileges. As a course of normal practice, I never create a role that has RWD permissions. It's just not that common since most organizations have the same desire and requirement to restrict deletes, and the user that typically needs the delete privilege is almost always an admin anyway.
In that manner, only admins (those with administrator privileges) can delete the items. Note that a document author, regardless of the delete privilege being assigned, can still delete content he/she authored. This behavior can be changed, but depending on your configuration, disabling this functionality may have unintended side effects.
Are you using Folders_G? Is there any value coming in dropdown for ReadOnly metadata?
Yes I am using Folders_g, and the list is populated with true/False as previously described. The advertised functionality just doesn't work, and apparently isn't built to even use the functionality, contrary to the documentation.