Option to hide subtasks (conditionally)

[Zocker1999NET]

I use Tasks as my tasks app and have used subtasks multiple times. Most of them are without due and start date. However, if I enable e.g. "Show tasks without due and start date at the end of the list", this widget will list all subtasks of tasks already shown elsewhere. So it would be great, if an option could be added to hide all subtasks.

Maybe it could also be useful to have an additional option like "Show subtasks only if they have a date and it differs from their parent(s)". So subtasks, which need to be done before their parent would still be shown, but other subtasks which only serve the purpose of being a checkable list would be hidden.

[yvolk]

@Zocker1999NET We need to figure out first, how to distinguish tasks from subtasks. I suspect that we will need to query some more info from a task app for this.
Could you figure this out?

[Zocker1999NET]

For me as non-Android dev, it seems as simple as retrieving another column from the app's database: The column parent seems to represent the subtask property. From the structure of the database:

          {
            "fieldPath": "parent",
            "columnName": "parent",
            "affinity": "INTEGER",
            "notNull": true
          }

https://github.com/tasks/tasks/blob/6173192e7207d3b1ec553e503a1ba7eb731f0532/app/schemas/com.todoroo.astrid.dao.Database/84.json#L391-L396

Because of "notNull": true, I expect then that <= 0 represents "having no parent" = "not being a subtask". EDIT: After reading more parts of Tasks's code, I'm sure they use == 0 as no parent.

I may be able to implement an option for just hiding all subtasks. I know Java & Kotlin, but don't expect me to write good code for Android, it would be more like "copy what the others have done before me and change names/titles/…". Implementing the second proposal might take some long time if I try that because I also haven't worked on this repository before. But I might be able to test both implementations if Android Studio can compile it without any special tweaks. (EDIT) Should I try the second as well?

[Zocker1999NET]

I think I implemented nearly everything required for a plain simple "hide subtasks" & data extraction from Astrid's fork Tasks (see #105). However, I do not fully understand the reasoning behind the method matchedFilter I assume I should add the filter to:

todoagenda/app/src/main/java/org/andstatus/todoagenda/task/AbstractTaskProvider.java

Lines 45 to 59 in 9be0a48

	protected boolean matchedFilter(TaskEvent task) {
	if (getFilterMode() == FilterMode.NO_FILTERING) return true;
	if (getFilterMode() == FilterMode.DEBUG_FILTER) {
	if (task.getStatus() == TaskStatus.COMPLETED) return false;
	if (task.hasStartDate() && task.getStartDate().isAfter(getSettings().getEndOfTimeRange())) return false;
	}
	if (getSettings().getTaskScheduling() == TaskScheduling.DATE_DUE) {
	if (!task.hasStartDate()) {
	if (task.hasDueDate() && task.getDueDate().isAfter(getSettings().getEndOfTimeRange())) return false;
	}
	}
	return !mKeywordsFilter.matched(task.getTitle());
	}

Which reasoning is behind the different behavior with and without the debug filter? And, if I should add the subtasks filter to this, should it be also applied if the debug filter is enabled?

EDIT: I think I might have understood it by myself. I thought lines 50 and 53-55 check for same properties but just realized they aren't … So I think I can append the filter before the return line, is that correct?

[yvolk]

DEBUG_FILTER mode doesn't filter events (e.g. by event dates...) at a provider's side, so on each request our widget receives ALL events from the provider and the filtering is done inside the Widget's code.
So we can make sure that we don't lose any events, can inspect their properties... primarily for debugging purposes.