Bug 524

Summary:	(resid) DirXMLScript (Enhancement): When changing actions, maintain content where possible
Product:	[Identity Manager] Identity Designer	Reporter:	Nathan Jensen <Nathan.Jensen>
Component:	Policy Builder	Assignee:	Forgotten User C1r2QIwDyb <forgotten_C1r2QIwDyb>
Status:	VERIFIED FIXED	QA Contact:	Brady Rogers <brrogers>
Severity:	Enhancement
Priority:	P2 - High	CC:	dgersic, norbert.klasen
Version:	2.0.0 Designer	Keywords:	Built, Provo
Target Milestone:	3.0 M2
Hardware:	Other
OS:	Other
Whiteboard:
Found By:	Beta-Customer	Services Priority:
Business Priority:		Blocker:	---
Marketing QA Status:	---	IT Deployment:	---

Description Nathan Jensen 2004-12-10 00:23:16 UTC

DETAILED DESCRIPTION:
From the DirXML BootCamp (12/4/2003):

When changing the selected action, maintain content 
where possible.

BUILD NUMBER: 
Oses/CONFIG: 
STEPS TO REPRO: 
RESULTS:
EXPECTED: 
WORKAROUNDS: 
CUSTOMER IMPACT: 


NTS entered defects should also include:
Additional debug info like screenshots, screencams, 
log files, trace files,
packet traces, memory coredump location.
Accurate customer information so that proper 
prioritizing of the defect is
possible (mainly for NTS defects)

Comment 1 Bill Street 2005-03-10 23:39:35 UTC

This is an enhancement.  Marking Resolve Later.

Comment 2 Bill Street 2005-08-02 17:48:07 UTC

Reopening bugs for determination of fixing bug or adding enhancements for
Milestone 1.1.  

Bill

Comment 3 Nathan Jensen 2005-08-19 23:53:34 UTC

*** Bug 86807 has been marked as a duplicate of this bug. ***

Comment 5 Nathan Jensen 2005-08-25 15:46:50 UTC

This one isn't fixed so removed the keyword Built

Comment 6 Nathan Jensen 2005-09-19 20:55:21 UTC

This will tie into the next version of the policy library and catolog service

Comment 7 Bill Street 2005-12-12 18:54:34 UTC

Changing resolve later bug milestones to future.

Comment 8 Lee Lowry 2006-01-12 19:59:08 UTC

Re-open

Comment 9 Brady Rogers 2007-02-05 23:56:26 UTC

This is from David Gersic. He is currently running Designer 2.0 M5.1.

This one's been driving me nuts, but I've forgotten to mention it until just
now.

Say I have a rule that looks like:

  if operation attribute Blah is changing to reg-ex(something)

and I want to change it to say:

  if attribute Blah is equal to reg-ex(something)

there's no easy way to do that. If my reg-ex is especially long and
complicated, I do *not* want to recreate it. But as soon as I change
op-attr Blah to attr Blah, the whole form is cleared and I'm supposed to
start over.

Usually I end up figuring out what needs to be changed, dropping to the XML
source to change it myself, then going back to the pretty UI to make sure I
didn't screw up the changes.

How about just invalidating whatever actually needs to be changed, without
throwing out what might really still be ok? So I changed op-attr Blah to
attr Blah, so what? The rest of the form would still be valid.

Comment 10 Norbert Klasen 2007-04-16 16:50:31 UTC

The same should be done for if-xpath: Currently, when changing the operator in an xpath condition from "true" to "not true" or vice versa the "value" field is always wiped out.

Comment 11 Forgotten User C1r2QIwDyb 2007-08-09 21:25:44 UTC

This is implemented now. The context is maintained while you change actions or conditions.

Comment 13 Brady Rogers 2007-08-10 21:20:27 UTC

Regressed in build 20070810_0300_3.0M2. This seems to be working well in old and new policy builder.