Flows related to joining a community

Setting membership policy to allow requests

Requesting to be a member

Waiting for a decision

Deciding if requester approved or not

(Bonus) Invitation page

See #792

@fenekku Thank you. All screenshots look great. Although the location and text of buttons are subjective:

• In the first screenshot under 'Deciding if requester approved or not'
  I would prefer having separate vertical tabs for 'Invitations' and 'Requests' with the number next to them (the number may not be implemented immediately.) But this 'Request' and Community "Request' in the horizontal tab MAY be confusing for the users.
• If i haven't missed the details, what is the way in which the user who requested membership is notified when the request is declined? Apart from the missing 'Request Membership' button?

• I will go for the separate vertical facets for now, and I agree the "Requests" tab and "Requests" facet is not great. IMHO, invitations/requests should be merged together into the "Requests" tab and have facets there based on the type instead of invitations(+requests for memberships) being in the "Members" tab for this reason.
• There is indeed no real feedback if the request was declined right now. Eventually email would be the way. Or we could have the button disabled with a "Declined" text, but I was thinking that was a bit too "in the user's face".

Set membership flow

The initial mockups were done with v11 on NU's local instance. Now that I started on the implementation and got a stable v12 running locally, I discovered these sections changed a bit. So I adapted the UI. Here is a video of the flow now for this one:

I placed it in this page because of the dependency on the Community's visibility. I think the other pre-existing section should also have this disabling/enabling dependency. Keeping the setting visible but disabled seemed also more transparent in the end to the user.

🚀 Looks great and this is very much requested and needed by many. Thanks a lot for the mockups. Overall flow and UX looks good to me, so below is just specific points

Some quick feedback:

• Take into consideration that “Member policy” should likely allow for more values than open/closed in the future (not necessary in MVP). E.g. on Zenodo I could imagine that there’s variations of “Open” where one is “Open for verified users”
• For restricted communities, I would perhaps keep the “Membership policy” there and simply grey it out and explain you cannot set the membership policy for restricted communities.
• Permissions: Probably require ownership of the community to manage these settings. Manager only manages members.
• What happens when a request is declined? How long do we keep it around (1 year)? What if the manager made a mistake? how do the user request membership again et? What if user cancels and then requests membership again?
• For privacy point of view, we’ll need to expire and remove the requests after a certain amount of time.
• For “Deciding if requester approved or not” I would go with primary version.
• “New invitation” in top community banner: I would probably not do since then I think we open up for putting a lot of different buttons up there as we extend communities. I think “New upload” and “Request membership” are two key things you want to advertise to members and non-members, where new invitation is just for owners/managers. That said, perhaps + button could be contextualised, so that we have a quick link from there with “New invitation for the community you’re currently viewing.

Btw, do you want to show this on the next RDM telecon?

Sure I can present this at the next telecon.

For what happens when a request is declined, I was thinking of just following whatever is done when an invitation/record submission is declined. If that's not a solved problem already, see the discarded approach [1] below.

Requesting to be a member

What mechanisms to use to get appropriate information in order to show the request button UI state is conceptually hard. We need to know if requester...

  <> member of community -(yes)-> don't show button
  | (no)
  <> requested to become a member of community already (request open) -> show requested
  |
  <> been declined to become member of community -> hide button or show declined
  |
  -> show request to join button

but permissions are not the full answer: if we had can_request / can_cancel / can_read_restricted_records we'd still need a "permission" to tell us if the user has been declined for potential UI purposes. Conceptually that doesn't fit [1].

I will be investigating what is done in potentially analogous situations: 1) on the discussion page for an invite 2) as part of the record submission process to a community . These may provide clues as to how to conceptualize and structure that data for usage by the UI. But if you have recommendations please share. I think this will take some time to wrap my head around.

[1]: a stretch to that model (that I dismissed for now because too much indirect work) would be to create a "declined" role for users that have been declined from a community i.e., place those users in the community but with this role that doesn't give them any other permission (in fact it would even remove permission to request to join). That role could be used to determine an answer to the new "can_be_declined" (not great name) action (which isn't a semantic fit but does provide benefits). It would also serve as memory of who was declined even after requests have been discarded. But there'd be additional things to do to make sure it fits well with other permissions/searches that is probably involved.