Bug 732831 - Drift configuration names could increment to prevent common error creating 2nd drift configuration
Drift configuration names could increment to prevent common error creating 2n...
Status: NEW
Product: RHQ Project
Classification: Other
Component: drift (Show other bugs)
4.1
Unspecified Unspecified
low Severity low (vote)
: ---
: ---
Assigned To: RHQ Project Maintainer
Mike Foley
: FutureFeature, Improvement
Depends On:
Blocks: 707225
  Show dependency treegraph
 
Reported: 2011-08-23 15:22 EDT by Mike Foley
Modified: 2011-11-02 12:00 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed:
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Mike Foley 2011-08-23 15:22:34 EDT
Description of problem:  Drift configuration names could increment to prevent common error creating 2nd drift configuration.  For example, the 1st drift configuration is named "File System".  When you create a 2nd drift configuration, it is named "File System" as well ... and there is an EJB error ... and you have to start all over again.  It would be better if the 2nd drift configuration were named "File System 2" or some other unique name.




Steps to Reproduce:
1.  create 2 file system drift configuration
2.
3.
  
Actual results:
error creating 2nd drift configuration due to the name not being unique

Expected results:
default path thru wizard works every time.

Additional info:
Comment 1 John Sanda 2011-08-25 10:54:17 EDT
I think we may want to change the title of this bug. The problem is that drift configuration names for a resource have to be unique. I do not think we are enforcing that right now. If someone creates two drift configs for the same resource with the same name, bad things could happen particularly on the agent side because the agent already assumes that names are unique. I am upping the severity to high.
Comment 2 Jay Shaughnessy 2011-11-01 16:01:16 EDT
+1 this is working as expected.  Unless there is something we're missing,
please close.
Comment 3 Jay Shaughnessy 2011-11-01 16:03:05 EDT
Whoops, updated wrong BZ, setting back to New...

As an aside, I think the behavior here has been improved already in that
I think you must edit the template name prior to save. Also, template
names have been improved.
Comment 4 John Sanda 2011-11-02 12:00:36 EDT
I had previously set the severity on this to high because I thought that we could wind up with multiple definitions belonging to the same resource and having the same name. That would be bad, but after further testing yesterday, I found that we do in fact prevent multiple definitions with the same name. Given that, I am downgrading the priority and severity to low.

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