Bug 86412 - Approve/Reject shows up in all comment forms
Summary: Approve/Reject shows up in all comment forms
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise CMS
Classification: Retired
Component: other   
(Show other bugs)
Version: nightly
Hardware: All Linux
medium
medium
Target Milestone: ---
Assignee: Justin Ross
QA Contact: Jon Orris
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2003-03-21 17:31 UTC by Jon Orris
Modified: 2007-04-18 16:52 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2003-04-22 03:49:44 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

Description Jon Orris 2003-03-21 17:31:32 UTC
The Approve/reject choice shows up in Comments for finishing Authoring.
This is different from 5.2 behavior. 

Deliberate change or bug?

Comment 1 Jon Orris 2003-03-21 17:31:48 UTC
@28738

Comment 2 Justin Ross 2003-03-21 17:53:20 UTC
It's a bug, *I think*.  I am confused about the approval element of the dialog.
 In the old CMS UI, only tasks of the CMSTask.APPROVE type got the approval
element.  Based on the other ticket we're discussing, 86411, I'm guessing that
the purpose of the approval element is to offer to reenable the prior task, for
example to throw it back to the editor for revision.

(That BTW, opens up another issue: an approval task may have n required
precursor tasks.  Do I reenable all of them?  CMS and workflow need use cases.)

Comment 3 Jon Orris 2003-03-21 18:25:59 UTC
I agree. We need better use cases & requirements for this behavior.
Given that we don't have them, and that it's late in the development cycle, I
think the best solution is to make it behave as close as possible to CMS 5.2.

For the next release, we should then focus on really analyzing what CMS should
do & why.



Comment 4 Justin Ross 2003-03-31 22:49:00 UTC
Fixed in perforce change 29258.  


Note You need to log in before you can comment on or make changes to this bug.