Have an attribute to mark tasks as 'hidden'

[pjf]

For things like tasks imported from RTM, you may not wish for them to show on hrpg displays automatically. We can check for a property on the object (we can set arbitrary ones with PUT) and simply not display tasks which have it for hrpg tasks, hrpg todo, etc operations.

Of course, there would a hrpg tasks all command to show everything.

This can allow for things like RTM tasks, or tasks which are activated by bots, from cluttering up the display, but still provides all the benefits of having them around (aging, history, etc).

For added points, this could hide tasks in the web interface, too.

cc/ @wizonesolutions, @lefnire

--- Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/1388376-have-an-attribute-to-mark-tasks-as-hidden?utm_campaign=plugin&utm_content=tracker%2F433776&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F433776&utm_medium=issues&utm_source=github).

[wizonesolutions]

@pjf I think step 1 would just be on the command-line. @lefnire's side comes in on the web interface stuff.

I think the concept of filtering comes in here, and that all we need is a source parameter.

Perhaps api_source? So I would set mine to "rtm".

I think you'd need configurability on the filter in the INI. Maybe something like

[hide]
exclude = rtm beeminder

What do you think?

[pjf]

I like the idea of .ini configuration. That means that other extensions don't need to do anything, and users can control what gets hidden and what doesn't.

However I do like the idea that a task can explicitly be set to hidden by the user. Perhaps it's something they no longer do, but they want to keep the history. Maybe they're going on holidays and want to hide all work-related things while there. Maybe the hrpg client wants to hide its konami cheat-code task. This obviously has upstream potential, hence the cc of @lefnire in on this. :)

I love the idea of api_source. It also has long-term value in that if a task ever looks odd, one can figure out where it came from. :)

I'm sure there was an issue/trello card somewhere for discussing extensions to habit tasks, but I can't seem to find it. (Simply because this should be linked to/from it.)

[wizonesolutions]

hrpg link

[pjf]

Thanks! GH #21

[wizonesolutions]

So there is an example of api_source. Threw it in since I could :)

[lefnire]

The approach we were going to take on the web interface for hiding items is Tags: https://trello.com/card/tags-categories/50e5d3684fe3a7266b0036d6/43 & https://github.com/lefnire/habitrpg/tree/tags . The idea is there are custom (standard) tags like "work" "home" "morning" "evening" etc. There are also dynamic tags which grok info about tasks - like "active" (which would exclude anything that has all days toggled off, which may play into this thread). It wouldn't actually be a tag on the task, but a calculated tag. Others would play with the interface, like "Todos" (which when un-clicked would hide the whole Todos column), "today" (due dates), header (hide the header), and so on.

With this in mind, is there a way we can marry this ticket with our current tags ideas?

[pjf]

@lefnire: Hell yes we can. Using tags would be ideal, because then users can adjust them using the web interface and other tools. As long as they can be retrieved and set via the API, we're golden.

On the hrpg side of things, I'd just add a section to the config file, maybe something like:

[tags]

; Always hide tags with these tags, unless --show-all is specified.
hide = #foo, #bar, #baz

; Always show tasks with these tags.
show = #qux, #frobz, #gratz

; Add these tags to new tasks.
add = #hrpg

LIkewise I can add cmdline options: --hide=foo,bar sort of things (hashes are optional/implied).

I still think having an api_source or similar property makes a lot of sense for tasks, since it means one can more easily figure out how they got there, but tags are definitely a better way to allow hiding/showing things from a user standpoint.

I presume calculated tags would be accessible via the API as well?

Many thanks,

Paul

[wizonesolutions]

No issues here. I don't think I will have to be concerned with tags in my tool. It might be nice to sync down RTM-side tasks.

On Sun, Apr 14, 2013 at 1:52 AM, Paul Fenwick notifications@github.comwrote:

@lefnire https://github.com/lefnire: Hell yes we can. Using tags would be ideal, because then users can adjust them using the web interface and other tools. As long as they can be retrieved and set via the API, we're golden.

On the hrpg side of things, I'd just add a section to the config file, maybe something like:

[tags]

; Always hide tags with these tags, unless --show-all is specified. hide = #foo, #bar, #baz

; Always show tasks with these tags. show = #qux, #frobz, #gratz

; Add these tags to new tasks. add = #hrpg

LIkewise I can add cmdline options: --hide=foo,bar sort of things (hashes are optional/implied).

I still think having an api_source or similar property makes a lot of sense for tasks, since it means one can more easily figure out how they got there, but tags are definitely a better way to allow hiding/showing things from a user standpoint.

I presume calculated tags would be accessible via the API as well?

Many thanks,

Paul

— Reply to this email directly or view it on GitHubhttps://github.com/pjf/WebService-HabitRPG/issues/28#issuecomment-16343167 .

[lefnire]

Awesome, I might ping y'all once we take a second stab at tags. We had to take a break due to derby bugs On Apr 14, 2013 5:35 AM, "Kevin Kaland" notifications@github.com wrote:

No issues here. I don't think I will have to be concerned with tags in my tool. It might be nice to sync down RTM-side tasks.

On Sun, Apr 14, 2013 at 1:52 AM, Paul Fenwick notifications@github.comwrote:

@lefnire https://github.com/lefnire: Hell yes we can. Using tags would be ideal, because then users can adjust them using the web interface and other tools. As long as they can be retrieved and set via the API, we're golden.

On the hrpg side of things, I'd just add a section to the config file, maybe something like:

[tags]

; Always hide tags with these tags, unless --show-all is specified. hide = #foo, #bar, #baz

; Always show tasks with these tags. show = #qux, #frobz, #gratz

; Add these tags to new tasks. add = #hrpg

LIkewise I can add cmdline options: --hide=foo,bar sort of things (hashes are optional/implied).

I still think having an api_source or similar property makes a lot of sense for tasks, since it means one can more easily figure out how they got there, but tags are definitely a better way to allow hiding/showing things from a user standpoint.

I presume calculated tags would be accessible via the API as well?

Many thanks,

Paul

— Reply to this email directly or view it on GitHub< https://github.com/pjf/WebService-HabitRPG/issues/28#issuecomment-16343167>

.

— Reply to this email directly or view it on GitHubhttps://github.com/pjf/WebService-HabitRPG/issues/28#issuecomment-16348413 .