Major Tracks migration to PatternFly of the Accounts Listing page UI.
Check sub-tasks for ticket progress status.
Dev notes
There's data that we need to pull from Porta DDBB that we need to specify. In order to tackle this, we will define it in an OAS that will be reviewed with a few options. The component will crafted using at the beginning with the mocked data from the examples section of the spec, but later will be replaced with the real implementation either with an existing Porta API endpoint or will be requested a new one.
Specification on current view
DISCLAIMER: This is not the FINAL specification. It is started from an analysis of what we have now.
It will evolve based on decision that will be documented here.
Simple assumption: We are going to replace this screen made in Rails view by a React component
In order to do so, we will extract this screen in different components, where the main one is a list of Account component represented by a row.
Fields/information used in this component
- account.id (for the links at least)
- account.org_name
- account.admins.first.display_name
- link to {{admin_buyers_account_path(account)
- account.created_at
- account.bought_account_plan.name
- account.bought_account_plan
- current_user.accessible_cinstances.bought_by(account).count
- link to admin_buyers_account_applications_path(account)
Can we retrieve all those elements from our current MT API endpoints?
Accounts list /admin/api/accounts#index
Fields provided
- account.id
- account.org_name
- account.created_at
{
"accounts":[
{
"account":{
"id":1,
"created_at":"2020-03-23T08:28:54Z",
"updated_at":"2020-03-23T08:28:55Z",
"admin_domain":"master-account.example.com",
"domain":"master-account.example.com",
"from_email":"no-reply@example.net",
"site_access_code":"",
"credit_card_stored":false,
"monthly_billing_enabled":true,
"monthly_charging_enabled":true,
"state":"approved",
"links":[
{
"rel":"users",
"href":"http://master-account.example.com/admin/api/accounts/1/users"
}
],
"org_name":"Master Account"
}
},
{
"account":{
"id":2,
"created_at":"2020-03-23T08:28:56Z",
"updated_at":"2020-03-23T08:28:56Z",
"admin_domain":"provider-admin.example.com",
"domain":"provider.example.com",
"from_email":"no-reply@example.net",
"support_email":"admin@provider.example.com",
"finance_support_email":"admin@provider.example.com",
"site_access_code":"256bc724a5",
"credit_card_stored":false,
"monthly_billing_enabled":true,
"monthly_charging_enabled":true,
"state":"approved",
"links":[
{
"rel":"users",
"href":"http://master-account.example.com/admin/api/accounts/2/users"
}
],
"org_name":"Provider Name"
}
}
]
}
Users list /admin/api/accounts/1/users
Field provided
- user.display_name
- user.role (can be used to filter for the first admin, WARNING this might not be sufficient to have 100% sure the account.admins.first)
{
"users":[
{
"user":{
"id":1,
"state":"active",
"role":"admin",
"created_at":"2020-03-23T08:28:55Z",
"updated_at":"2020-03-23T08:28:55Z",
"links":[
{
"rel":"self",
"href":"http://master-account.example.com/admin/api/users.1"
}
],
"username":"master"
}
}
]
}
Issues
The list is conditionally tied to the current user, so not all users will see the same data. Depending on wether they have the right permissions or not.
There is no filter to get the first admin straight
- current_user.accessible_cinstances.bought_by(account)
- can? :see, :multiple_applications
