Moon-Jumper Tasks - Revision history

Adamcolton: /* Label */

2017-10-25T12:08:18Z

Label

← Older revision		Revision as of 12:08, 25 October 2017
Line 104:		Line 104:

	Label points could be done with conditionals too. Say a Label has a default point value. You can attach conditions. The highest value condition will be returned.		Label points could be done with conditionals too. Say a Label has a default point value. You can attach conditions. The highest value condition will be returned.

			Should let people give Labels a color and an icon.

	== Special Views ==		== Special Views ==

2017-10-24T15:56:39Z

Tools

← Older revision		Revision as of 15:56, 24 October 2017
Line 122:		Line 122:
	* http://arborjs.org/		* http://arborjs.org/
	* https://github.com/d3/d3/wiki/Gallery		* https://github.com/d3/d3/wiki/Gallery
			** https://bl.ocks.org/mbostock/950642

	[[Category:Moon-Jumper]]		[[Category:Moon-Jumper]]

2017-10-24T15:52:10Z

Tools

← Older revision		Revision as of 15:52, 24 October 2017
Line 121:		Line 121:
	JS Graph tools		JS Graph tools
	* http://arborjs.org/		* http://arborjs.org/
			* https://github.com/d3/d3/wiki/Gallery

	[[Category:Moon-Jumper]]		[[Category:Moon-Jumper]]

2017-10-24T15:50:39Z

← Older revision		Revision as of 15:50, 24 October 2017
Line 117:		Line 117:
	* Show all tasks dependent on the tasks in the group.		* Show all tasks dependent on the tasks in the group.
	* Backlog all tasks in group.		* Backlog all tasks in group.

			== Tools ==
			JS Graph tools
			* http://arborjs.org/

	[[Category:Moon-Jumper]]		[[Category:Moon-Jumper]]

2017-10-23T18:02:50Z

Database Model

← Older revision		Revision as of 18:02, 23 October 2017
Line 54:		Line 54:

	=== Database Model ===		=== Database Model ===
	I can ~~go AllConditions → ConditionTypes, but~~ then ~~I need~~ to ~~manage polymorphic sql~~. ~~I can go ConditionTypes → to AllConditions~~, ~~but~~ then it ~~becomes hard to query starting with~~ a ~~condition set~~.		The challenge is that I need something where I can efficiently ask
			select all conditions where condition_set = X
			and then iterate over the results and see what needs to be computed

			Ways to do this:
			* Polymorphic: store type+ID, requires doing one select per table.
			* Unified Table: Can get bulky
			* Binary Table: hold the common fields (id, type, value, permanent) in the table, then gob the rest of the struct and put it in a binary field.

			I think I like the last.

	== Repeaters ==		== Repeaters ==

2017-10-23T17:42:57Z

← Older revision		Revision as of 17:42, 23 October 2017
Line 15:		Line 15:
	* Points: time/energy requirements of the task		* Points: time/energy requirements of the task
	* Label: task context		* Label: task context
	* Active : Condition

	I was going to have an "Expires", but conditions have the permanence flag. If a condition becomes permanently false, the task expires.		I was going to have an "Expires", but conditions have the permanence flag. If a condition becomes permanently false, the task expires.
Line 22:		Line 21:
	* State		* State
	** Active: task can be worked on. It will show up in lists and when the priority is high enough, it will show up in the main list		** Active: task can be worked on. It will show up in lists and when the priority is high enough, it will show up in the main list
	** Backlog: tasks assigned to the backlog will never become active until they are removed.
	** Pending: some pre-req hasn't been met.		** Pending: some pre-req hasn't been met.
	* Date Active: when a task changes from pending or back log to active, this is updated.		* Date Active: when a task changes from pending or back log to active, this is updated.

2017-10-23T17:40:32Z

Repeaters

← Older revision		Revision as of 17:40, 23 October 2017
Line 63:		Line 63:
	=== Task Repeater ===		=== Task Repeater ===
	Title, label, points and priority are all copied		Title, label, points and priority are all copied

			It may make more sense to just have a UI for task group repeat and you can have a group repeat with a single task. Easier than two different UI's for single vs multi tasks.

	==== Notes Repeater ====		==== Notes Repeater ====
	Notes either repeat off a base template or off the last instance.		Notes either repeat off a base template or off the last instance.

2017-10-23T17:38:18Z

Conditions

← Older revision		Revision as of 17:38, 23 October 2017
Line 52:		Line 52:

	It will be really cool if these can show up as red/green indicators in the UI.		It will be really cool if these can show up as red/green indicators in the UI.

			Backlog becomes a condition that always returns non-permanent false. Not sure if I want to display it that way.

	=== Database Model ===		=== Database Model ===

2017-10-23T17:37:16Z

Task Groups

← Older revision		Revision as of 17:37, 23 October 2017
Line 101:		Line 101:
	== Task Groups ==		== Task Groups ==
	We can get rid the of the Group/GroupStage model. Instead, we'll have an actual, simple task Group. A task group has tasks or sub groups. A group can have a condition set. And a group produces two conditions (active, done). A group can have a label, a group can be backlogged. A group can have a priority, but that just sets the default priority when adding a task.		We can get rid the of the Group/GroupStage model. Instead, we'll have an actual, simple task Group. A task group has tasks or sub groups. A group can have a condition set. And a group produces two conditions (active, done). A group can have a label, a group can be backlogged. A group can have a priority, but that just sets the default priority when adding a task.

			There are interesting operations on a group:
			* Show all tasks dependent on the tasks in the group.
			* Backlog all tasks in group.

	[[Category:Moon-Jumper]]		[[Category:Moon-Jumper]]

2017-10-23T17:35:41Z

Conditions

← Older revision		Revision as of 17:35, 23 October 2017
Line 30:		Line 30:
	Under the hood, I think this needs to be a little more complex that True/False. A condition should ternary T/?/F. And it should indicate if it will ever change.		Under the hood, I think this needs to be a little more complex that True/False. A condition should ternary T/?/F. And it should indicate if it will ever change.

	* Date: ~~when a task is given~~ a date~~, it will not be active until~~ after ~~that date~~.		* Date: Takes a date and before/after.
	* Computed: Takes a date repeater and a date event; 3 days after ~~group stage 2~~ is done.		* Computed: Takes a date repeater and a date event; 3 days after this task is done.
	* Date Range: Takes two month/day and returns true for dates in between.		* Date Range: Takes two month/day and returns true for dates in between.
	* Set: creates a set of conditions so that if you want several things to work off the same conditions, they can all be wired to the same set.		* Set: creates a set of conditions so that if you want several things to work off the same conditions, they can all be wired to the same set.
Line 43:		Line 43:
	Values with in the task system itself can be used as conditions. The condition can be linked to the item being either done or active.		Values with in the task system itself can be used as conditions. The condition can be linked to the item being either done or active.
	* Task		* Task
	* Group Stage
	* Group		* Group