signature recording needs to tie-in to backend and count constituents / non-constituents

[davidmooreppf]

Issue for 8(c) on dev roadmap. Currently, on a Q page, adding your signature in the right-hand column just redirects to staging site homepage.

Goal is to have signatures actually count and be reflected in a timely way on various question listing pages.

There are a couple wrinkles here, but the first one is - from the user's street address, we seek to differentiate two types of signers: constituents and non-constituents.

For a Q to a MA senator, any MA street address signer is a constituent. For a Q to mayor of Boston signed by a resident of Worcester, or San Francisco, signer is a non-consituent obvs.

On the front end we may not display this diff. in progress bar, but it's necessary on back-end. Some elected officials will require this info when responding to Q's and we need to have it accessible in the database: how many constituents have signed this Q. Some elected officials may only respond to Q's where 51% of signatures are from constituents.

We maybe only need to generate this query upon request by elected official, as opposed to every time a signature is added, but it needs to be possible - open to input. Can break this into two stories if you prefer Walter.

[davidmooreppf]

My second line in the above is 8(d) in dev roadmap, can break this out if that's advisable.

[walter]

What the backend does now is record the signer's address at the time of signing in the signature data itself.

I believe this will allow us to do a query later that splits constituent signers vs non-constituent signers. @davidmooreppf is this sufficient for the moment?

My feeling is that we should get collecting of signatures in place and then circle back to how to determine constituents vs non-constituents later since our data gathering looks to handle it.

[walter]

Whether we do this now or later, it would be good if @derekeder or @evz tackles getting the frontend signing form working.

[derekeder]

@walter sounds like a good task to tackle next. Don't see an issue for wiring up the frontend 'sign on' button. Shall I create?

[walter]

@derekeder 👍

[walter]

@derekeder I think the last thing remaining here is to make sure that questions index page's listing of number of signatures perhaps takes into account threshold and have the link simply go to the question's page.

Long term something color coded (and actual working sorting) would be great, but that is for down the line for another issue.

[derekeder]

@walter cool, I'll add that in

[walter]

I've merged the previous pull request to master already. Just do the work on this issue rather than opening a new one. Once that bit is finished, we'll close this.

[walter]

@derekeder is the questions#index work done on this?

[derekeder]

@walter reviewing this again. A few notes:

• do we want an acceptance test for rendering the signature_threshold on question#index?
• the 'Sign On' button is not displayed on the listing page for users that aren't signed in. I removed it since signing on unauthenticated requires requires a registration form. Should this be replaced with a link like 'Read more and sign on'?

[walter]

do we want an acceptance test for rendering the signature_threshold on question#index?

Yes. I would do a targeted acceptance test for it on questions_spec.

the 'Sign On' button is not displayed on the listing page for users that aren't signed in. I removed it since signing on unauthenticated requires requires a registration form. Should this be replaced with a link like 'Read more and sign on'?

So you are saying that the "Read more and sign on" would be a link to the question page? I would think that is acceptable for now. Wording wise maybe "Read more" would be enough if space is tight. Might be worth speaking to @acacheung about it.

I actually think after the functionality is done a quick confab w/ @acacheung to give her a tour and ask if there needs to be any UX changes is worth doing.

[derekeder]

questions#index sign on spec implemented in 43b6d67

Looks like we've settled with 'Sign' for the button language

@walter think we're good to close this one?

[walter]

The core of this issue is implementing a comparison of constituents to non-constituents.

The backend work has been done (capturing questions signers' addresses at point of signing in signature model), but a way of seeing in the web UI hasn't.

Normally I would say we close it and create a new issue for the web UI if and when we get a request for it, but I think we can just keep around for moment as "nice to have".

[derekeder]

Good call. We did kind of re-purpose this issue for implementing basic 'sign on' functionality. As the initial issue was described, agreed - lets keep it open.

[davidmooreppf]

Yeah, this feature - a way for verified responders to see constituents vs. non-constituents signing Q's to them - will be necessary shortly after launch, if not nec. from day one. So keeping this open is good, Walter. But it's a bit of a toughie, depending on how we implement special views for logged-in verified users.

Barring a more-complex /admin interface for verified responders, having simple stats under the threshold bar of individual questions would be sufficient implementation, for when a verified responder is logged-in to her account and viewing the Q page on AskThem. So a second threshold bar isn't really necessary for the verified responder or for the public viewing - but adding in the number of constituents under the progress bar would be required.

[walter]

I would go "lean" and "fake it until you make it". Once someone requests this, we can do some manual work to get the data from the console. Then we can judge what is useful from them.

It's way better to base our implementation on concrete user need rather than guessing. Let's do it manually until we have a better understanding of what would be useful for verified responders.