Description of problem: Duplicate catalog Items can be created Version-Release number of selected component (if applicable): 5.9.0.15 5.8.3.0 How reproducible: 100% Steps to Reproduce: 1.Two catalog items with the same name can be created under one catalog. Actual results: Two catalog items with the same name can be created under one catalog. Expected results: An error message that catalog item with that name is already created. Additional info:
I can reproduced it on 5.10 as well
Agree that PM should comment on this, but in my opinion Catalog Items and Bundles look the same to the end-user that is ordering from the Catalog. This is by design as the difference is an internal detail. Therefore I would recommend that Catalog names be unique across all items regardless of the type.
Agreed, we should not allow to have 2 Services (Catalog Item and bundle) with the same name.
Fixes https://github.com/ManageIQ/manageiq/pull/19142
Name uniqueness validation on UI level? I don't think so. If this is really is a product requirement, then the validation needs to be done on a database / active record level (with all that it takes), just like it is done everywhere else and the bz needs to be routed appropriately. But validation on the level of ui / api controller -- that's not going to happen.
(In reply to Milan Zázrivec from comment #15) > Name uniqueness validation on UI level? I don't think so. > > If this is really is a product requirement, then the validation needs > to be done on a database / active record level (with all that it takes), > just like it is done everywhere else and the bz needs to be routed > appropriately. > > But validation on the level of ui / api controller -- that's not going > to happen. I am not directing the solution here, the requirement is: as a user, I cannot create catalog Item with the same name.
Right. This needs to be fixed and it's not really the reporter's problem if the fix is to be done in the model or in the controller. So, please, fix this by adding the validation in the model or move this BZ to someone from the core/backend groupd who will do it. Regads.
Ok, so looking further into https://github.com/ManageIQ/manageiq/pull/19142 and the discussion here. We have a problem with core -- missing validation. There's a solution proposal: https://github.com/ManageIQ/manageiq/pull/19142 The solution is not liked by the core (due to a missing migration). Adding a migration is not liked by the product management (does not want to migrate data = rename items). From the UI perspective, we are done here. Now the core team need to work with product management and figure what to do.
This needs further discussion before it's actionable. I'll report back here once we have a way forward.
The way uniqueness validations work, if we don't have a migration fixing the existing records, then functionality like modifying an existing record will fail. That is, a user (or even the backend code itself) that needs to modify the record will never be able to moving forward, because when the record tries to be saved it will fail the uniqueness validation. This includes even something as simple as updating a status or a timestamp or anything on the record. This is part of the framework and not something we can change or get around. This means that the only 2 choices are a) no uniqueness or b) uniqueness + a migration to "fix" duplicate records. Loic's choice of uniqueness but without modifying any existing records is not possible. I assume we want uniqueness based on the discussion above, so that implies we must have a migration for the existing records.
Moving back to assigned cause with the questions about visibility re:rbac and how we can't enforce uniqueness outside of a specific region, GM and Tina didn't sound terrible sure what to do with this and thus I'm not actively working on it.
Hi Drew, Based on https://github.com/ManageIQ/manageiq/pull/19142#issuecomment-562610734, I think we can close this ticket. Thanks, Tina