Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Patch management features #414

Open
Jaymassena opened this issue May 8, 2016 · 2 comments
Open

Patch management features #414

Jaymassena opened this issue May 8, 2016 · 2 comments
Assignees
Labels

Comments

@Jaymassena
Copy link
Member

Just wanted to capture patch management features I’d like to see eventually surface in the clients. I think we have discussed most/all of these. Not in priority order.

  • Change ownership of a patch.
  • Allow messages from everyone or just owners.
  • Block membership requests from all or specific users. This supports multiple scenarios: membership request spamming, make membership by invitation only.
  • Mark patch visibility as secret so it is only visible to current members in lists and search. I know this likely has list performance implications.
  • Manage multiple users as owners.
  • Control whether other group members can see your phone/email.
@georgesnelling
Copy link
Member

Change ownership should work now, I believe.
Allow messages from everyone or just owners is implemented as 'locked'.

@Jaymassena
Copy link
Member Author

If we switch to Patchr modeled more to match Slack then here is a revised prioritized list of management features:

Roles

  • Users have a role based relationship to patches: user or admin.
  • A patch can have more than one admin but must always have at least one.
  • Admins have what we have always called owner permissions.
  • Only admins can add/remove other admins or users.
  • Patch creator is automatically added as an admin.

Patch visibility

  • Mark patch so that it is only visible to current members in lists and search. I know this likely has list performance implications. This would be used to support private channels.

Inherited membership

  • Patch can inherit members from a parent patch. This would be used to support channels. All open channels inherit membership from the parent patch. Private channels have their own membership that must be a subset of the membership of the parent patch.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants