This content has been marked as final. Show 12 replies
There are probably several ways how to implement your requirement, but you should specify in detail who can delete the item during its lifecycle (and why - it is not uncommon that "mere" contributors cannot delete anything at all). The most complete solution would be formal records management, where a released item can be deleted only via dispositions, but I believe it could be an overkill in many situations. Pls. share more details about your use case.
I have a example like that
And Workflow Ending.
UserA(Editor)(Step1) =>UserB(approver)(Step2) => News public on Website(Step3) Step1: User A create news after that sent to User B at step 2 to approve Step2: User B approve news was send from User A. After that the news was Released Step3: News have status Released was publish on Website
Thing I want that When news is at Step 3 User A or User B can't delete the news. It only can be deleted by User A when User B unpublished the news.
Hope it more detail with you and sorry for my bad English
On the news website. If a news is published that mean content of news was shown for end user reading on website. If you allow User A can delete the news which is published on website => end user can't read more. At this situation User A not is the person have right decide which news is still exist or not exist on the news website. Only User B have this right.
I understand what you want to do, but I'm missing details how you do it, and why.
Anyway, I will try to guide you through the lifecycle, following your scheme:
a) Step1 (Content does not exist): User A will need at least RW permissions to create the content. The content will enter a criteria workflow to be approved.
b) Step2 (Content in the workflow): User B will need at least R permissions to read the content and approve it. As soon as approval occurs, the content is released
c) Step3 (Content published to the Website): all users will need at least R permissions to view the document. User B will need permissions to "unpublish" the content. You did not answer my question how this "unpublishing" is achieved. I would recommend you to expire the content. Expired content is no longer present on the site, cannot be searched for, but is not deleted. Expiration may take place when a user sets up the metadata Expiration date (dOutDate - see http://docs.oracle.com/cd/E23943_01/doc.1111/e10792/c03_processes.htm#r5c1-t19 ). You may want to customize your system that i) expiration is one-click activity b) only User B can expire the content. Unfortunately, security model does not allow securing metadata changes - all users with R permissions can modify metadata. You could define a profile that will hide the field to all users, but User B, but to be absolutely sure, you would have to add a filter that will (on server-side) prevent anyone else to do it.
d) Step4 (Content expired) You again did not answer, if there is any particular reason for not deleting expired content. Therefore, I will expect that there is none. You could use the Archiver to delete all expired content for you in a batch (once a day/week/month).
As you see, no one in the scheme above can actually delete the content.
Another possible implementation would be using: http://docs.oracle.com/cd/E23943_01/doc.1111/e10792/c05_security.htm#sthref863 (AuthorDelete=true) where only the user who is marked as the author (or in this context, rather "owner") can delete the document. This would be a bit awkward, though, as you would need to modify the value of dDocAuthor - this would again require customization.
Yet, another implementation would be using ACLs http://docs.oracle.com/cd/E23943_01/doc.1111/e10792/c05_security.htm#CDDBCIDA where User A in Step1 would have RWD permissions, and UserB would revoke User A's WD permissions (via ACLs), to grant them back in Step4. This will not require customizations, but on the other hand this would put much more responsibility (and training issues) to User B. Besides, ACLs can affect overall performance of your system.
The first, thank you very much for your answer
The second,I'm so sorry about my bad English not enough to explain in more detail for you.
In my situation, I not use "Expiration Date" for unpublished a content, I only use it with auto unpublished content type. Instead of this, I create a customize field name xmPublished with True/False value type. When User B want to unpublished the news, he/she only update this field in metadata of this content item. But as you said the big problem in hear, everyone with R permission can modify metadata.
You gave me a solution is
I tried as you said, but I couldn't find the way to filter prevent anyone else to do it.
You could define a profile that will hide the field to all users, but User B, but to be absolutely sure, you would have to add a filter that will (on server-side) prevent anyone else to do it.
Would you show me more in detail?
Thanks a lot!
Profile and Filter are two different things.
A profile - see http://docs.oracle.com/cd/E23943_01/doc.1111/e10978/c04_metadata.htm#DAFIIEEI will modify just the screens. With several rules you may achieve that all, but User B users won't see the field. A disadvantage of this approach is that is GUI is by-passed (someone calls the service directly), profiles won't help you.
A filter, on the other hand, is server-side piece of code. It can be "hooked" to standard events. Recently, there has been a post on a similar topic. I will navigate you to the thread - read namely in the middle UCM-Desktop Integration Suite-
Note that the profile will be iDocScript, the filter will require a custom component and Java programming.
if you do not care about the Author metadata value, In step 2 exit script put..
<$wfUpdateMetaData("dDocAuthor","weblogic")$> [[%I haven't tried it%]]
and User A will have RW permission to the SG or Account.
This way User A can never delete the content unless he is the contributor in step 2 and step 2 is New Revision/Edit Revision step.
wfUpdateMetadata can only be used for custom metadata - see http://docs.oracle.com/cd/E23943_01/doc.1111/e10726/c06_core_ref.htm#CSIDO635
updating dDocAuthor (in a workflow by idocScript) requires customization
so during check-in, in a rule ... add dDocAuthor and check derived field and set the value to weblogic.No good either. If an item is rejected you would like to have an option to return it to the original author (in the contributor step only author can change the document).
I think changing the author is, in fact, quite a lame design if the issue is security bound.