UI for adding users to user group allowed to see closed API

[bajiat]

Definition of done

• Owner can specify a list of users allowed to see the API by their email.
  • Open issue: What if the user is not registered to Apinf? Depends on if we are storing user email or their ID.
• Owner is able edit the list:
  • correct typos
  • change emails
  • add new people
  • remove people.
• There is a collection and schema for storing the allowed users.

Wireframe

[Nazarah]

@brylie : i added the wireframe here. If you wish to discuss about the design, please let me know.

[brylie]

@Nazarah I like the wireframe above. I may have difficulty inserting the 'add users' widget in the middle of the 'API Visibility' field, since they will probably be separate fields.

With regards to the user selection widget, I have started searching and found the following:

• Selectize.js
• Chosen

[brylie]

One thing which is not clear to me, is if we can provide auto-complete suggestions at all. The auto-select widgets need to be fed a list of options to suggest as we type, which in this case would be user email addresses. How should we treat user email addresses in our system?

[brylie]

One idea, after reviewing the wireframe, would be to create a 'dumb' field just to store a list of email addresses, probably with basic validation for structure. The administrator would have to know the email address, e.g. no auto-complete or search suggestions. Then, our authorization function would check a given user's email address matches one from the list.

The above approach would provide a 'loose' connection between the authorized emails and Apinf user accounts. E.g. if an Apinf user were somehow able to change their account email, they would no longer be authorized to access the API.

[brylie]

A second option would be to store the user ID, possibly retrieving it from a server-side function (when the manager clicks 'Add User'). When entering a non-registered email address, the manager could also be informed if the account does not exist. A shortcoming of this approach is that the authorized users must first be registered in Apinf, before manager can authorize them to access the API.

However, the ID link would allow the user to change their email address while still preserving the authentication link. The 'authorized users list' could automatically update with the current user (such as username/email).

[frenchbread]

What if we use same widget as on the dashboard? We populate it with a list of all users in the collection which have user's name & email as display text and user's ID as a unique identifier. In the end, admin can give permissions to users he wishes for, can send notifications (or emails are sent automatically) and as a bonus, if user he wants to add is not registered, there is a button Invite user that is not registered (or smth like that). And this invitation is visible as pending user who has permissions for an API until user himself confirms it by email.

[frenchbread]

And the user will always have permissions even if he changes his email since they are attached to his ID.

[brylie]

What if we use same widget as on the dashboard? We populate it with a list of all users in the collection which have user's name & email as display text and user's ID as a unique identifier.

That is a good idea. I just want to make sure we are considering user privacy. In effect, we would be handing every API manager a list of all user email addresses in our system.

[frenchbread]

Right, then we can still follow that approach but use different widget like this one. And don't show email to the user, but use it in the background.

[brylie]

For clarification, we discussed whether to auto-populate a list of email addresses, and decided not to go that route for privacy reasons.

@frenchbread I also like the Select2 dropdown, since it allows us to use templates for the options. Do we already include Select2 in our project?

[frenchbread]

@brylie Nope, we have just bootstrap-select

[brylie]

Ah, OK.

Quick survey:

@bajiat, @frenchbread, @marla-singer, @manzapanza, @mauriciovieira, @Nazarah, @NNN, @philippeluickx: What are your thoughts on Select2 vs. Selectize vs. Chosen?

[frenchbread]

@brylie After a brief overview, looks like they all are similar to each other. It's more a question of selecting right options for selected widget and writing custom hooks, for example, data fetch while typing (for security, not storing all the data on a client). I would 👍 for select2 since its bootstrap-based & has more options out of the box.

[brylie]

@frenchbread Cool. Also, this is mainly in consideration as a widget to set the API Visibility (public, semi-private, or private), rather than selecting authorized users.

[Nazarah]

@frenchbread

What if we use same widget as on the dashboard? We populate it with a list of all users in the collection which have user's name & email as display text and user's ID as a unique identifier.

about this, when we select an user, should the user ID be shown as Boot strap tag? or we will show only the email?

[Nazarah]

@frenchbread and @brylie : what if APINF has 100 registered users and the API owner needs to add only 5 users to her API. So if you use data population like dashboard, then it would be too trouble some to browse the list of 100 users and so on. So I'd have vote for the auto complete option. You type and matches user name/email populates in the dropdown list.

[brylie]

@Nazarah as per our discussion today, we will not be populating a list of users, even with auto complete. This is to protect the privacy of user email addresses.

Basically, this discussion is more relevant to the Visibility Mode task, which @NNN is assigned to #1622

[philippeluickx]

My opinion is to hold off selecting a more complex select widget. If we can solve our design with standard elements, I consider that a better option.
I am not against the options, but it really needs to make sense. Otherwise it feels a bit like design bloat to me?

[manzapanza]

@brylie these components are quite similar, but I also would choose the select2 since it is based on bootstrap as shown in the wireframe.