-
Enhancement
-
Resolution: Done
-
Major
-
None
-
False
-
False
-
Yes
-
Undefined
-
User Story
As an API Provider, when I want to create a new Application, I want to find a CTA in the most relevant places of the UI.
Requirements
Everything that is explained in the mockups, plus:
- 'Account' select details:
- typeahead
- 20 most recently created {items} displayed in the dropdown menu (sorted by most recent)
- If the sum of all {items} available is higher than 20, display link button to "View all {items}"
- When "View all {items}" is clicked, open a modal dialog that includes a paginated table listing all {items}
- display 5 {items} per page
- sort table by last updated by default
- make table filterable by {item} name
- When 'Application plan' select is clicked, display all Application plans for the selected Product in the dropdown menu (sort them alphabetically)
- If no Application plan exists for the selected product:
- disable the select
- and display an inline warning text with following copy: "An Application needs to subscribe to a Product's Application plan, and no Application plans exist for the selected Product. Create a new Application plan", where the "Create a new Application plan" portion of the text is a link to the {Product} > Applications > Application plans > Create Application plan page
- If Service plans are enabled,
- If the Account already subscribes to one of the selected Product’s Service plans:
- disable the input field and display the name of the Service plan the Account is currently subscribing to
- add a helper text with the following copy: "This Account already subscribes to the selected Product’s Service plan. If you want this Account to subscribe to a different Service plan for this Product go to Service subscriptions", where the "Service subscriptions" portion of the text is a link to the Audience > Accounts > Accounts index > {Account} > Service subscriptions page
- If the Account does not subscribe to any of the selected Product’s Service plans yet:
- the input field will be enabled and will be a typeahead select, displaying all Service plans for the selected Product in the dropdown menu (sort them alphabetically)
- add a helper text with the following copy: "In order to subscribe the Application to a Product’s Application plan, this Account needs to subscribe to a Product’s Service plan.”
- If the Account already subscribes to one of the selected Product’s Service plans:
Resources
- Path: Products > Product > Applications > Listing
- Marvel
Acceptance Criteria
- All requirements have been implemented
- is blocked by
-
THREESCALE-7914 Account search in create application forms returns only few records
-
- Closed
-
- is cloned by
-
-
- Closed
-
- is related to
-
-
- Closed
-
[THREESCALE-6879] [3scale][2.11][HI-prio] Add 'Create new Application' flow to Product > Applications index: Part 1
amackenz@redhat.com sure, and I don't think there is any strong disagreement on that (apart from the possible difficulty of classificating a changing UX/UI/product behavior as enhancement or bug, but that's a slightly different conversation). I guess what I was trying to say is:
- if the Jira issue classification has been defined already in the workflow, then this information didn't reach UXD. If anybody could point us to that, UXD would implement that classification from now on when creating/handing over Jiras
- if the Jira issue classification has NOT been defined already in the workflow, then maybe it could be worth it to do so in order to avoid any confusion/double work moving forward
cc tmaas-1
Andrew Mackenzie
added a comment - At the risk of repeating myself, I think if we are asking for “special treatment” and a different workflow for Tasks (as championed by Thomas and others in the Workflow discussions) then we totally need to care about an issue being a task or not.
I suspect that any issue that “needs handing over from UXD to Eng”… is not a task, but is intended to change the product in some way.
For me example of Tasks would be:
- delete this user from SaaS
- send me these … logs
- refactor class X
- improve test Y
Not things changing UI, or product behavior.
Andrew Mackenzie
added a comment - At the risk of repeating myself, I think if we are asking for “special treatment” and a different workflow for Tasks (as championed by Thomas and others in the Workflow discussions) then we totally need to care about an issue being a task or not.
I suspect that any issue that “needs handing over from UXD to Eng”… is not a task, but is intended to change the product in some way.
For me example of Tasks would be:
delete this user from SaaS
send me these … logs
refactor class X
improve test Y
Not things changing UI, or product behavior. acontini and amackenz@redhat.com, engineering really doesn't mind what this is classified as so, if you two can agree on how to classify it, let me know and we'll do that from now on.
Andrew Mackenzie
added a comment - For me, if it changes the product behaviour it should be either a Bug (fixing something that is broken), an RFE (improving an existing feature) or Feature (adding a new one).
Task should be reserved for something we have to do, but doesn't change the product behaviour (maybe a code refactor, or removing old files, or renaming a file, etc etc) and that is used mainly to skip the standard workflow as doesn't need new tests or docs.
Andrew Mackenzie
added a comment - For me, if it changes the product behaviour it should be either a Bug (fixing something that is broken), an RFE (improving an existing feature) or Feature (adding a new one).
Task should be reserved for something we have to do, but doesn't change the product behaviour (maybe a code refactor, or removing old files, or renaming a file, etc etc) and that is used mainly to skip the standard workflow as doesn't need new tests or docs. Andrew Mackenzie
added a comment - This sounds like it's an RFE not a TASK
jgallaso Tested on cand2, but unfortunately, there are few problems I have found.
1. Account plan searching looks at first that it does it's job as its supposed to:
but if we add any number to the search, it stops searching and returns and empty list.
2. Alphabetical order is not present for both types of plans.
dhlavacd@redhat.com I think that should be fixed as well. It should disable the select only when there is a subscription OR there are no plans.
Since the problem described in this issue should be resolved in a recent advisory, it has been closed.
For information on the advisory, and where to find the updated files, follow the link below.
If the solution does not work for you, open a new bug report.
https://access.redhat.com/errata/RHSA-2021:5191