-
-
That's what the "user" query parameter is for ;)
-
Oh, I missed that. In that case, can we change it to accept a URL of /status_report/<user>/ (or <user>/status_report/ might be better). Should make for a cleaner URL. I would actually really like to minimize query parameters, so something like /reports/<user>/status_report/<period>/ would be ideal, imho. More natural, easier to remember, and we can set up a matching JSON API path at some point to get the information.
-
OK, I've updated it to be /reports/<user>/<report type>/<format>/ Period is still a query string since I want to eventually rework it to be a lot more flexible (right now it's just "n days in the past from right now"), and I'm not yet sure what the final thing will look like.
-
-
Initial stab at reports
Review Request #151 — Created Sept. 6, 2007 and submitted
| Information | |
|---|---|
| david | |
| Review Board SVN (deprecated) | |
| trunk | |
| Reviewers | |
| reviewboard | |
There's a lot unfinished here, but it's good enough for my purposes ;) The report selector, in particular, needs a lot of love. At the moment it only allows selecting the report and a format. The user and period fields are wired up, but there's no UI.
-
-
/trunk/reviewboard/reports/views.py (Diff revision 2) Out of curiosity, any reason why we don't rearrange reports to be a dictionary with 'report_review_requests', 'report_reviews', and 'report_status_report' keys? I suppose it's for the template, though that should be able to work still and auto-sort alphabetically unless we want to preserve a specific sort order. Anyhow, food for thought. On a similar note, it might be nice to use dictionaries instead of tuples for things like the template name and format and such, to improve code readability in the report function.
-
Awesome, looks good!
-
/trunk/reviewboard/reports/views.py (Diff revision 3) We should at some point write some middleware to always output charset=UTF-8. Though I wonder if we get this already, since diffs and all show in UTF-8.