Happy New Year Reiner! I hope that all is well and that you have a prosperous 2011!

Can we put this in terms of the "story" that we are trying to achieve? Are there even stories in the tests already that cover these hidden states? My first reaction was that do we even need to assign a "hidden" state to a todo if real state value is stored in the project / context?

Personally, I have tried to use the hidden features as follows:

1. I have a @somedaymaybe context that is hidden that I sometimes through todos into if I want to retain something I want to get done, but don't plan to work on it now. The reality is though that I am more likely to use the defer option to temporarily get it out of the way. I fact, on my personal installation of tracks, I have added more defer options to the drop down menu - 1, 2, 3 or 7 days. That way, I can stash something way for the weekend or to the weekend depending on the situation.
2. I have used the hide a project feature as well, when I have a project that is dormant. If I am behaving right, I will review these projects weekly to see if they should get unhidden.
3. The last scenario that I tried was for a shopping list. I have been using tracks to track stuff we need from the grocery store. I have a project call groceries with a default context of @errands. Originally, I wanted to hide the project so that I could add items I needed to get, but not have to look at them all the time. When I was at the grocery store, I could pull up the list on my mobile and get what I needed. The problem that I ran into was I could not add a todo to the grocery project from the mobile interface as the grocery project did not show up on the list. I ended up just un-hiding the project, figuring somedaymaybe, I would look for how to show the project in the drop down list.

So, here is how I see it:

• If the project is hidden, the todos in the project should not show up on the home page list. The project should appear in the list of projects, but separated into a grouping below the active projects. If you visit the hidden project's page, it should render as if the project was not hidden. You should be able to add todos to a hidden project from the home page form or the mobile add/edit form.
• If the context is hidden, the todos in the context should not show up on the home page list. The context should appear in the list of contexts but separated into a grouping below the active contexts. If you visit the hidden context's page, it should render as if the context was not hidden. If you visit a project page, hidden context should be displayed with other todos (Not sure about this last one, maybe they should segregated visually).

I am not sure that what exists in tracks today, follows the logic above.

Unless it is easier from a coding standpoint or for performance, it seems more efficient to not track the hidden state in the todo record itself. It is probably a trade off. If hidden-ness is not stored in the todo, then un-hiding a context or project would be quicker as you don't have to update all the todo records in the db, but if you do store hidden-ness in the todo, then home page might load faster as it does not need to check the state of the project / context. One potential issue with storing hidden-ness in the todo record is if you have a todo in a hidden context and a hidden project, and you unhide one of them, the code needs to know not unhide the todo...

Hi Tim

Happy new year to you too!

The stories for hidden stuff is like you described. I think it was put in there for Someday/Maybe and dormant projects. I use it for both too. I'd like to create a separate state for Someday/Maybe so you can review them more easy from the project view instead of the hidden-context-view...

The ticket is about the current messy implementation. Currentyl the todos are marked hidden_project if the project is hidden, but it is not marked hidden if its part of a hidden context. I'd like this to be more consistent. If you maintain the state on the todo it is because of performance (less complex SQL query). I agree that it does not need to be maintained on todo. Perhaps it is even better to first remove the state from the todo and see if the performance penalty is big. I agree on the complex logic if a todo is both in a hidden project and a hidden context

I'm currently migrating and refactoring to jquery (fully) and getting cucumber stories ready to test the outside behavior. After that, refactoring stuff like these states is more easy...

The messy implementation led to a bug in #1196. Currently, you cannot view dependencies (state: pending) from a hidden project (state: project_hidden) although the dependencies can be set (datamodel)

I'd like to work on the task of removing the state from todos and instead computing everything based on information stored for contexts and projects. Is that still a good idea? What are your (current) thoughts on this? As far as I know, this might fix #1421 #1423 #1424 and should also make it possible (when also applied to projects?) to work on the dependency model (#1425).

See the mailing list for my reply

Be aware though that you are touching the central model of Tracks: Todo. It is not for the faint of heart :-)

Migrated to GitHub issue #1082