Bug 1021905 - [oVirt] [provider] It's seemingly possible to add a provider with the same name
Summary: [oVirt] [provider] It's seemingly possible to add a provider with the same name
Keywords:
Status: CLOSED UPSTREAM
Alias: None
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine-webadmin-portal
Version: 3.3.0
Hardware: Unspecified
OS: Unspecified
medium
low
Target Milestone: ---
: 3.3.0
Assignee: Lior Vernia
QA Contact: Meni Yakove
URL:
Whiteboard: network
Depends On: 987949
Blocks: 3.3snap2
TreeView+ depends on / blocked
 
Reported: 2013-10-22 10:10 UTC by Lior Vernia
Modified: 2016-02-10 19:49 UTC (History)
10 users (show)

Fixed In Version: is22
Doc Type: Bug Fix
Doc Text:
Clone Of: 987949
Environment:
Last Closed: 2013-11-10 07:04:05 UTC
oVirt Team: Network
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
oVirt gerrit 20568 0 None None None Never

Description Lior Vernia 2013-10-22 10:10:34 UTC
+++ This bug was initially created as a clone of Bug #987949 +++

Description of problem:
Can do action is not propagated to UI


Version-Release number of selected component (if applicable):


How reproducible:
Always


Steps to Reproduce:
1. Go to external providers
2. Add some provider with name "test"
3. Add another provider with name "test"
  
Actual results:
There should be an error shown to the user that the name is unique


Expected results:
There is no error shown, the dialog closes


Additional info:
In log you can see:
2013-07-24 15:52:09,261 WARN  [org.ovirt.engine.core.bll.provider.AddProviderCommand] (ajp--127.0.0.1-8702-1) CanDoAction of action AddProvider failed. Reasons:VAR__ACTION__ADD,VAR__TYPE__PROVIDER,ACTION_TYPE_FAILED_NAME_ALREADY_USED

--- Additional comment from Lior Vernia on 2013-10-21 02:28:51 EDT ---

Einav, is this something that should be fixed? As far as I know, all frontend validation nowadays only checks that the input is technically valid, not if names are already taken.

--- Additional comment from Einav Cohen on 2013-10-21 12:26:49 EDT ---

(In reply to Lior Vernia from comment #1)
> Einav, is this something that should be fixed? As far as I know, all
> frontend validation nowadays only checks that the input is technically
> valid, not if names are already taken.

indeed - client validations are currently not checking name uniqueness - we are relying solely on server validation to do that.

the problem described in this bug is not that there is no client validation; the problem is that the server validation (namely, CanDoAction) results are not propagated properly to the UI (namely, no dialog with the CanDoAction details pops up, as should happen with any CanDoAction failure).

we had a bug that prevented any CanDoAction dialog from appearing after engine restart [http://gerrit.ovirt.org/#/c/18729/, Bug 968362], but it has been fix.
[the fix was merged (Sep 4) after this bug has been reported (Jul 24)].

@Mike - can you please test to see if the problem is still reproducible on latest master? If so, it means that the problem is not related to Bug 968362 and further investigation is required in order to find out why the CanDoAction failure dialog is not popping up as it should.

Thanks.

--- Additional comment from Lior Vernia on 2013-10-22 02:42:23 EDT ---

Yes, upon more careful reading I see you are perfectly correct. I checked, and while there's an error popping up now, it does pop up only after the dialog closes, so that should still be fixed.

Comment 1 Shai Revivo 2013-11-10 07:04:05 UTC
This bug was fixed and is slated to be in the upcoming version. As we are focusing our testing at this phase on severe bugs, this bug was closed without going through its verification step.


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