Admin tool of some sort for creating open and restricted (scoped) groups

[seanh]

As a Hypothesis admin I want to be able to quickly and easily create an open and restricted group for a publisher.

Done when:

• [x] There's a quick and easy way for a Hypothesis admin who isn't a technical user to create an open or restricted group that a publisher has requested
• [x] The admin can specify a name for the group
• [x] The admin can specify the origin or origins (multiple) (e.g. http://www.cnn.com, https://www.cnn.com) on which the open or restricted group should appear
• [x] Admins should be able to create either an open group or a restricted group
• [x] The admin can specify the group creator Note: The application treats a group's creator as its "owner". The UI for this may be janky in first release (i.e. requiring an admin to type in a userid or something).
• [x] The Admin should be able to declare which authority the new group belongs to, with a default to the default authority (hypothes.is)
• [ ] Suitable validation and error messages (listed below)
• [x] The Admin should see a message if the user entered to be the group's creator does not exist
• [ ] The Admin should see an error message if the origins entered for scope are invalid
• [x] The Admin should see an error message if core group fields do not validate (e.g. name)

[dwhly]

Possibly groups could have been created already, i.e. "self-serve": https://github.com/hypothesis/product-backlog/issues/428

[ajpeddakotla]

Edited this to reflect that we can work on both the open and restricted groups admin interface (as it is the same interface) at the same time. There is only 1 additional requirement for restricted groups: adding group members - that has been pulled out into a seperate card: #494

[lyzadanger]

Hi @ajpeddakotla ! Thanks for breaking these cards out. I think there are a few acceptance criteria on this one that are going to need to wait until we make further progress on publisher/"organization"-related feature planning. Might I suggest the following:

• [ ] There's a quick and easy way for a Hypothesis admin who isn't a technical user to create an open or restricted group that a publisher has requested
• [ ] The admin can specify a name for the group
• [ ] The admin can specify the domain or domains origin or origins (multiple) (e.g. cnn.com) (e.g. http://www.cnn.com, https://www.cnn.com) on which the open or restricted publisher group should appear
• [ ] The admin can choose what named publisher the group belongs to Note: we don't have a plan yet for how we're handling "publishers"
• [ ] The admin can provide an icon for the publisher Note: Same as above.
• [ ] ~~The admin can specify what Hypothesis user account will be the moderator / creator of the group~~ Note: We haven't addressed permissions/relationships between users and groups beyond what is already in place. This feature is obviously necessary for restricted groups, but right now the app doesn't have the ability to "grant" these types of privileges to anyone but the group's creator, so we may need to table this for this iteration. Note that this is also a partial duplicate of an item below about creator/owner that I've left in place.
• [ ] Suitable validation and error messages
• [ ] The groups shouldn't be preconfigured. Admins should be able to choose from a list of permissions. Admins should be able to create either an open group or a restricted group. Note: Unless team members disagree, I think we should expose the ability to create open or restricted groups only at this time (in the admin panel, that is).
• [ ] The admin can specify the group owner creator Note: The application treats a group's creator as its "owner". The UI for this may be janky in first release (i.e. requiring an admin to type in a userid or something).
• [ ] The admin can update details of the group when needed. Note: I think we need a separate card for managing/editing a group. The rest of the tasks on this card fall into creating a group.

I'm wondering if we should add:

• [ ] The Admin should be able to declare which authority the new group belongs to, with a default to the default authority (hypothes.is)
• [ ] After creating the new group successfully, the Admin should be taken to a panel to manage the membership of the group (add/remove members) <-- Is this a good idea?

I'd also suggest expanding the Suitable validation and error messages bullet into:

• [ ] The Admin should see a message if the user entered to be the group's creator does not exist
• [ ] The Admin should see an error message if the origins entered for scope are invalid
• [ ] The Admin should see an error message if core group fields do not validate (e.g. name)

Reason: This will help devs itemize some of the validation work needed.

[seanh]

I've deleted this one:

• The groups shouldn't be preconfigured. Admins should be able to choose from a list of permissions.

Preconfigured types of group (private, open and restricted) is the architecture that we've been building so far. We don't have a system at any level (service, API, activity pages, client, ...) that's able to deal with arbitrarily chosen group permissions and it's not clear to me yet that that would be a good direction.

(As Lyza already pointed out)

[seanh]

• [ ] The admin can update details of the group when needed. Note: I think we need a separate card for managing/editing a group. The rest of the tasks on this card fall into creating a group.

Agree - lets move this to a separate card. This may overlap with the admin page for adding members to and removing members from a group which is already on its own card (both features may belong on the same page)

[seanh]

I'd also suggest expanding the Suitable validation and error messages bullet into:

• [ ] The Admin should see a message if the user entered to be the group's creator does not exist
• [ ] The Admin should see an error message if the origins entered for scope are invalid
• [ ] The Admin should see an error message if core group fields do not validate (e.g. name)

Looks good!

[seanh]

• [ ] After creating the new group successfully, the Admin should be taken to a panel to manage the membership of the group (add/remove members) <-- Is this a good idea?

I think that's probably a good idea because I think we might add any other group edit controls that we want admins to have (like editing the name of the group, its scopes, etc) to the same page?

[ajpeddakotla]

Agree w/ all comments made, and updated the acceptance criteria in the top comment to reflect. Old Acceptance Criteria (kept for record)____

• [ ] There's a quick and easy way for a Hypothesis admin who isn't a technical user to create an open group or restricted that a publisher has requested
• [ ] The admin must specify a name for the group
• [ ] The admin must specify the origin or origins (multiple) (e.g. https://cnn.com) on which the group should appear
• [ ] The admin can choose what named publisher the group belongs to (Deleted because we don't have named publishers in h yet, will have to do this on a later card)
• [ ] The admin can create a new named publisher if necessary (Deleted because we don't have named publishers in h yet, will have to do this on a later card)
• [ ] The admin can provide an icon for the publisher (Deleted because we don't have named publishers in h yet, will have to do this on a later card)
• [ ] The admin must specify what Hypothesis user account will be the moderator / creator of the group
• [ ] Suitable validation and error messages
• [ ] The groups shouldn't be preconfigured. Admins should be able to choose from a list of permissions. (Deleted as this isn't what we're implementing, see comments below)
• [ ] The admin can specify the group owner (Deleted because this is the same as (The admin must specify what Hypothesis user account will be the creator above)
• [ ] The admin can update details of the group when needed.

[lyzadanger]

Work is proceeding here. There are a bunch of pieces almost ready to be plugged into each other. Here's what needs to happen next if anyone else picks this up:

• There is an extant "add a group" admin panel already merged into master with a form and some validation
• Ideally, the origins field in the form would be updated to integrate the work happening in https://github.com/hypothesis/h/pull/4876 (patch included) and URL validation would be added to the values that get entered into those fields
• The view's POST handler needs to be hooked up to the group service and invoke the appropriate "create" method depending on the type of group

[dawachan]

UX/UI Feedback for improving the 'Create New Group' admin form.

(I've created a new card for UX/UI improvements #https://github.com/hypothesis/product-backlog/issues/534 to be picked up in the future. It is recommended some of the improvements be pushed out with the initial release e.g character limits and required field affordances) to avoid unnecessary user errors.

1. The form is appearing stretched and longer the data/options being displayed e.g Group Type and text fields are excessively long. Recommendation: Follow the form field widths presented on the create group: https://hypothes.is/groups/new no need to centre align - keep as left aligned as per the rest of the admin UI form fields.
 (Suggested width: 570px)

2. Consider making the authority field non-editable, if so make the text look disabled - as I understand it, this is pre-populated and immutable.

3. Are there any character limits for group name, description etc? There will probably need to be, so let’s add the character count in the bottom right corner as per create private group UI: https://hypothes.is/groups/new. Adding the character count from the get go will prevent the ‘exceeding character’ limit error showing when the user clicks ‘Create new group’.

4. On Scope Origins field ‘i’ tooltip let’s change the text from: ‘Origins where this group appears (e.g. "https://example.com' to: ‘Origin URLs where this group will appear (e.g https://example.com)’

5. Expose the origin form field input field from the ‘get go’, so it’s not hidden behind a click, add water mark to this text field ‘e.g. www.example.com’

6. Scope Origins: Do we want to enforce entry of either ‘http://’ or ‘https://’ before the URL? At the moment, this form submits with only ‘www….’ If we do want to validate against protocol, we should include in the watermark as well e.g ‘http://www.example.com'.

7. Add a label to the subsequent origin fields and make the ‘required affordance’ only on the first scope origin field.

Mockup for initial form view with 1st add origin field exposed and shown as a required field:

Mockup for displaying multiple origin fields:

Note: there are additional ways to design multiple input fields but I kept the same model @robertknight has already implemented to make it simpler.

For an alternative way to handle multiple form inputs in one text field - see the following 'email to: field' example

[ajpeddakotla]

Closing as issue is completed.