Spoke: Admin Panel: Allow monitoring and redistribution of conversations

Created on 1 Jun 2018  路  4Comments  路  Source: MoveOnOrg/Spoke

Volunteer texters are great, but sometimes life gets in the way and they aren't able to keep up. Admins need to be able to ensure that all voters a) receive replies to their questions and b) get taken off the list if they ask (a legal obligation in most states). Admins should be able to view conversations from the admin panel and re-assign them to other texters as needed.

This is related to:

  • 'Ability to 'redelegate' a contact to another texter' (#210)
  • 'Enhance AdminIncomingMessage view' (#546)
A-Admin UUX C-enhancement

Most helpful comment

Assuming the redistribution of individual conversations will be worked on in #546 and #210 I'm going to write out some guidance on how to implement bulk reassignment from a texter that is 'giving up'/leaving and all of their assignments need to be taken on.

Backend:

  • assignTexters code is good reference and in src/workers/jobs.js
  • You'll need to create a backend endpoint in schema.js. Probably a good template for that in this case will be editUser. Here is the definition and here is the declaration/manifest -- you'll need both
  • The function itself should

    • [ ] Verify that the submitter is a campaign owner/admin (see other similar checks in schema.js)

    • [ ] Make sure the new assignee has an assignment record (see e.g. the logic here )

    • [ ] do a knex update to assignment_id on all the campaign_contacts where all the old assignee's assignment_id is there and updating it to the new user's assignment id.

Frontend:

  • The top CampaignAdminEdit form is in src/containers/AdminCampaignEdit.jsx

    • [ ] That will need a new mutation declared at the bottom to your new mutation declared in the backend

    • [ ] You'll want some function on the container that takes input (old userid, new userid) and calls the mutation and responds with success

  • The component that shows the texters is src/components/CampaignTextersForm.jsx

    • [ ] You'll want to add a property which passes the reassignTexterContacts method you defined in the container so that the component can then call that method which calls the mutation in graphql stuff

    • [ ] You'll want to add an interface/button to reassign someone with contacts assigned to them.

All 4 comments

Assuming the redistribution of individual conversations will be worked on in #546 and #210 I'm going to write out some guidance on how to implement bulk reassignment from a texter that is 'giving up'/leaving and all of their assignments need to be taken on.

Backend:

  • assignTexters code is good reference and in src/workers/jobs.js
  • You'll need to create a backend endpoint in schema.js. Probably a good template for that in this case will be editUser. Here is the definition and here is the declaration/manifest -- you'll need both
  • The function itself should

    • [ ] Verify that the submitter is a campaign owner/admin (see other similar checks in schema.js)

    • [ ] Make sure the new assignee has an assignment record (see e.g. the logic here )

    • [ ] do a knex update to assignment_id on all the campaign_contacts where all the old assignee's assignment_id is there and updating it to the new user's assignment id.

Frontend:

  • The top CampaignAdminEdit form is in src/containers/AdminCampaignEdit.jsx

    • [ ] That will need a new mutation declared at the bottom to your new mutation declared in the backend

    • [ ] You'll want some function on the container that takes input (old userid, new userid) and calls the mutation and responds with success

  • The component that shows the texters is src/components/CampaignTextersForm.jsx

    • [ ] You'll want to add a property which passes the reassignTexterContacts method you defined in the container so that the component can then call that method which calls the mutation in graphql stuff

    • [ ] You'll want to add an interface/button to reassign someone with contacts assigned to them.

@schuyler1d @lperson is this issue solved with message review? Or am I missing part of the heart of the feature

If you interpret @bchrobot's original comment as acceptance criteria, they are accomplished in the MoveOn fork and enhanced in the WFP fork.

Ok, closing this cause we seem to have a modern way of dealing with this. We can reopen if we want to reconsider. Thanks for all the input here!

Was this page helpful?
0 / 5 - 0 ratings