created a pull request on github

could you ask on the mailing list for feedback?

Already did. No response so far. I'm using it now for two weeks and it works like a charm for me (after some minor bug fixing which is already included in the pull request on github).

Finally got around to upgrading to master (commit bc529f7baa06750af3d0a95f051edd5279d66ce8) . Found some issues with the 'review' functionality:

1. The routes for the 'set_reviewed' functionality need to be of the form: http://devel/tracks/projects/21/set_reviewed (note the 'projects'). That seems to work if I reach the 'reviewed' button via project/edit settings link from an individual project's page. However, when I click on the pencil icon in the project list or in the review list, then the review button has a route of e.g., http://devel/tracks/21/set_reviewed. Note it's missing the '../projects/.....', and hence I get a routing error:

ActionController::RoutingError (No route matches "/1/set_reviewed" with {:method=>:get}):

2. You mention a 'review_date'. Where should I find that?
3. Lastly a suggestion, can we also show the projects that are current at the bottom of the review view, rather than just the ones that are problematic?

Oh, one other thing. On Linux CTRL-R is reloading the page, so the access key doesn't work. Am I missing something?

@routing problem: There's a pull request in git that fixes the routing problem. I have no clue, why the problem didn't occur in my development version.

@review_date: go to the preferences, there you can set the review interval

@suggestion: what do you mean by 'can we also show the projects that are current at the bottom of the review view'? They are shown in the review view, aren't they?

@access key: In linux, the access key is mapped to alt. So 'ALT-R' should access the review mode, however, in Firefox, you might have some other key mapped to it.

@review date: got it. Wasn't obvious to me that that's the project review date, we could rename it to 'Project review interval'
@routing: o.k. Will check again when Rainier gets a break from changing diapers
@access key: ALT-Capital R works for me on Windows Firefox, will test on Linux tomorrow (no big deal either way)
@suggestion: Here's what I see:
I currently have 32 projects, 30 in progress, 2 completed (from the projects page)
On the review page I see 27 dated projects and 15 stalled projects, for a total of 42 (obviously some projects are both dated and stalled).
When I now open one of them (say 'Oktoberfest) and set it to reviewed, and then go back to the review page I see 41 projects, 26 dated and 15 stalled, in other words a project that was just reviewed and therefore current is not in the view. I suggested adding a category 'current' or 'up to date' at the bottom of the list that shows those projects.

@review date: added the English language description as suggested
@suggestion: fine with me; implemented in the open pull request that also fixed the routing problem

Have fun at the Oktoberfest!

I've merged all pull requests

If have a few "problems" with all of this

• set_reviewed is now a GET in routes.rb. I'd like that to be a POST or PUT, because calling set_reviewed will change the state of the project and changes should always be done using PUT/POST. I couldn't get it working quickly, so for now I restored the GET
• does the button need to be in the project_form or do you want it to be on the project page. When I review a project, currently I need to first click "Edit this project" and then mark it reviewed. Do we need the first click?
• we need tests for this new feature (unit tests for the model changes and cucumber tests for the interaction)

It would be nice to display the button right aligned next to the 'Edit Project Settings' as it saves one click.

Is there some documentation how to write test cases and what the database looks like? It should be straightforward, however, I don't know where to start. Glancing through /test didn't help that much.

in /test you can find the unit tests. I think it is best to start at test/units/project.rb and try to add some tests for blocked and stalled

in /features you can find the cucumber tests to create scenarios for doing review.

I can help of course

We we check this off as fixed?

I thought of a couple of test cases, however, I don't know how to program them:

1. Check new project needing review
2. create a new project
3. assert that project needs a review


1. Check review button
2. create a new projcet
3. invoke 'review' button in gui
4. assert that the project needs no review


1. Check review need
2. create a new project
3. set the last_reviewed field of the project to last year
4. assert that the project needs a review


1. Check stalled
2. create a new project without todos
3. assert that the project is marked as stalled


1. Check blocked
2. create a new project
3. add one todo to the project
4. set the show_from field to 7 days in the future
5. assert that the project is marked as blocked

You can look at some of the existing .feature files under the features directory in order to see how you might test those with cucumber.

For example, for your first test case, you might write:

Scenario: Projects require review when they are created
Given that I have not created a project
When I create a project
Then it should be marked as needing a review

You can then implement code in features/step_definitions that will do the Given, When, and Then steps in your test case. Running cucumber after adding the scenario but before doing anything to implement it will give you some boilerplate code to add to one of the files in features/step_definitions

Moved to 2.1. I think we need at minimum add some tests and move the button out of the edit-project form.

Can you please check I'm doing this the right way?

git clone git://github.com/Popsch/tracks.git -b review_test

I added a three scenarios. While they check whether the project occurs in the response page, the test doesn't check whether the project is in the right category.

tests got merged https://github.com/TracksApp/tracks/pull/62