Feature Request: User Level differentiation for releasing and requesting conversations

[ryanjcrump]

Problem
We would like for new texters to keep their assigned Active, Closed, and Opted-Out conversations while our guides review those conversations, but it would be best for Vetted Texters to be able to release all conversations.

Furthermore, we only want Vetted Texters to be able to pick up replies mid-conversation.

Solution
Create an option to limit "release all conversations" and "Take a batch of conversations" to only Vetted-Texter level and above.

[schuyler1d]

What's the reasoning behind this feature? I.e. if/when it was added when would we recommend to campaign admins to set it up this way?

If this is implemented, either internal to WFP or in this project, the easiest thing to do is copy (or modify) the default-releasecontacts texter-sidebox extension:
https://github.com/MoveOnOrg/Spoke/blob/main/src/extensions/texter-sideboxes/default-releasecontacts/react-component.js
in the existing or new extension, you would:

1. Add an option to enable this feature in the Admin schema and a toggle field:
   https://github.com/MoveOnOrg/Spoke/blob/main/src/extensions/texter-sideboxes/default-releasecontacts/react-component.js#L189
   and here is a toggle "Switch" field that you should copy (and change the field name):
   https://github.com/MoveOnOrg/Spoke/blob/main/src/extensions/texter-sideboxes/default-releasecontacts/react-component.js#L222-L231
2. Once that is done, you can add a check above in the texter sidebox code. To decide whether to show it at all in the showSidebox() function, you add currentUser to the list of input arguments (it's already sent in, but this extension didn't currently use it, so it wasn't on the list):
   https://github.com/MoveOnOrg/Spoke/blob/main/src/extensions/texter-sideboxes/default-releasecontacts/react-component.js#L30
   and then add logic to decide when to show it similar to the take-conversations textersidebox
3. Possibly change the conditions for whether to be showing the "release all conversations" button here:
   https://github.com/MoveOnOrg/Spoke/blob/main/src/extensions/texter-sideboxes/default-releasecontacts/react-component.js#L90

[ryanjcrump]

The reason for limiting the assignment of replies to vetted texters is simply that we provide lots of support for new texters (user level ="Texters") while they are active in spoke, so we like to limit that to particular events where we shift volunteer moderators. So, we don't want them to have access to this feature. But our vetted texters are on a separate team and slack channel and are working in between events to respond to contacts, so they should have access to the feature.

The reason for limiting the release of conversations is connected to a current limitation in our Guide View / Sweeper View, which is that this feature ONLY displays conversations that are currently assigned to the user. If a new texter releases their conversations, we cannot use the guideview/sweeper feature to review their conversations and give feedback. It strikes me that this should be a feature enhancement, so I will add a request. If this feature was changed to instead show conversations that originated with a particular texter (or more specifically, where a particular texter sent the first response) then I would be open to allowing texters to release their conversations, feeling confident that we can still use the guide view feature to review their work.

[ryanjcrump]

Thanks for taking a look at this and making recommendations @schuyler1d ! hoping someone is interested in working on it!

[schuyler1d]

So this could definitely be easier, and you may know about this feature already, but it's possible to setup Spoke so that initial texts auto-unassign messages and then only vetted texters can dynamically get replies.

It's also possible to disable contact releasing altogether (and then possibly at a different stage, e.g. after replies have been reviewed, allow conversation release).

The above workflow might not work for other reasons, but it might be worth unpacking why (it's definitely more complex than it could be).

I'm not trying to push back on the feature, so much as understanding fully what does/doesn't work about existing workflows.