-
Notifications
You must be signed in to change notification settings - Fork 344
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
DS creation - behaviour should be consistent when an associated field is deleted before DSR fulfillment #3723
Comments
For scenario 1 these are the delivery service types: and although TP and the TO api allows you to create new delivery service types, you really shouldn't because without other code changes, your new "type" will have no effect. These types are static in nature. Can you check in the browser's dev console to ensure that an error isn't being returned and maybe the UI is simply failing to display it because fulfilling a ds without a type (because you deleted it) should DEFINITELY return an error. ^^ really, an issue here (in addition to the missing error message) is that TP/TO API should not let you create/edit/delete "static" types. On the other hand, creating/editing/deleting "dynamic" types is mostly OK. i.e. creating EDGE_FOO or MID_FOO is fine because creating anything that starts with EDGE or MID are the only 2 types that you can create dynamically. i'll created an issue for that - #3728 |
@lbathina - i tried scenario 1 -
and when i try to fulfill the ds request, i'm getting this error in the browser's dev console:
that is why "nothing" is happening. the error is preventing the UI from navigating to the fulfill page but the error is silent. I'll get a PR in for this. |
re: scenario 2.
the real problem here is that the system should have never allowed you to delete a profile (AAA) that is associated with something. in this case the AAA is associated with an active ds request. the issue is really that you should not be able to delete any of these things (type, profile, cdn, tenant) if they are attached to an active (state=draft or submitted) ds request. |
Sure. Will spin a new ticket for #2 |
Scenario 1 -> tracked in #3728 |
Scenario1:
Expected: some kind of error that type doesn't exist
Actual: Nothing happened!!!
On discussion with team it seem to be a static type that user is not supposed to create. In such case, the appropriate thing would be to restrict creation of types only to allowed ones.
Scenario2:
Expected: Some kind of error that associated DS_Profile doesn't exist should be displayed
Actual: DS_Profile is unassociated from the DS and no notification/message is displayed. Able to fullfil the DSR
The text was updated successfully, but these errors were encountered: