signature recording needs to tie-in to backend and count constituents / non-constituents about askthem HOT 16 CLOSED

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

from askthem.

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.

from askthem.

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

from askthem.

@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?

from askthem.

@derekeder 👍

from askthem.

@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.

from askthem.

@walter cool, I'll add that in

from askthem.

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.

from askthem.

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

from askthem.

@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'?

from askthem.

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.

from askthem.

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?

from askthem.

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".

from askthem.

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.

from askthem.

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.

from askthem.

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.

from askthem.