-
Notifications
You must be signed in to change notification settings - Fork 32
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
Allow user to specify titles and descriptions on input pages #275
Comments
We already have a login facility, which I recently discovered by looking through the logs is essentially unused. I suppose that since all features of the site are available without logging in the incentive to log in is quite small. This might be our actual first feature that would incentivize people to log in for their runs. So, to start, we want the feature "ability to edit title of results page if logged in and the logged in user was the user who submitted the job." Correct? |
For adding titles, I don't think the user would need to be logged in. That would be the first step. The second step would be to allow logged in users to see a list of their runs. On Jul 8, 2016, at 2:24 PM, T.J. Alumbaugh <[email protected]mailto:[email protected]> wrote: We already have a login facility, which I recently discovered by looking through the logs is essentially unused. I suppose that since all features of the site are available without logging in the incentive to log in is quite small. This might be our actual first feature that would incentivize people to log in for their runs. So, to start, we want the feature "ability to edit title of results page if logged in and the logged in user was the user who submitted the job." Correct? — |
Hmm.. I'm not sure how this would work then. So, someone submits a job and they get redirected to taxbrain/6789. The loading page goes for a while and then taxbrain/6789 is the results page. Then, anyone who views taxbrain/6789 can modify the title of the page? So the user who submitted the job would modify it and be happy. But if anyone else went to the page, he/she would see the new title, but could also change the title to something else? Is that correct? |
That is a bad outcome -- did not think through it sufficiently.
|
On Fri, 8 Jul 2016, T.J. Alumbaugh wrote:
I wouldn't let people edit the results page. Rather I would allow users to dan
|
On Fri, 8 Jul 2016, T.J. Alumbaugh wrote:
Why would the title be treated any differently than any other parameter? dan
|
I agree with @feenberg:
@talumbau, does that sound like the right course of action to you as well? |
This is definitely doable. So, the results page stays static as always. |
@MattHJensen I'll wait for a milestone marker here to understand the priority of this feature. |
Added this to b3 for now. Was tempted to put it in b2, but we already have a lot there. |
RECAP: The goal of this issue is to allow users to specify their own Titles and Descriptions of reforms via fields on the TaxBrain input page. Those titles and descriptions will then appear at the top of the TaxBrain output page. If a user clicks "edit parameter" and changes the title or description, then a new url sequence number will be generated just like it is if the user generates any other parameter. The data should be stored in a similar style as the reform data, so that if/when we get to the point where we can turn input pages into json reform files and json reform files into input pages, the title and description can easily come along for the ride. (Please read PSLmodels/Tax-Calculator#1140 for a long-run view on where this feature is headed.) A standard reform title might be something like:
A standard reform description might look like:
|
@feenberg said via email:
I replied:
@feenberg replied:
I think Dan's idea of allowing the user to enter a title for each output page is really elegant as a first step. @talumbau, would it be difficult to implement? I imagine the title would be public for anyone who goes to that url.
Later, adding a page that would allow logged in users to list their runs would also be helpful, although as Dan says, we should probably think more about how that would work.
Other ideas are very welcome as well.
The text was updated successfully, but these errors were encountered: