Are flags stupid or is my workflow?

I have a Planning custom perspective that shows me all of my choices to work on Today. Each morning, I review the Today perspective and flag the items I want to work on today and those items show in a custom Today perspective that includes flagged items. This works great except for one problem: when you flag recurring items, the flag is applied to all recurrances and not just the current instance (i.e., after you complete the current instance, the next recurring instance is auto-flagged).

The behavior of flags with recurring todos makes no sense to me. There should be a way to set whether a flag is applied to all recurrances or only to the current instance.

Am I missing something or does OF condemn me to life of unchecking flags on recurring items during my reviews? Or will the new Planned date feature be a more elegant way to plan for today?

1 Like

Do these perspective settings work for your use case?

Thanks for the reply but I do not understand your proposed settings. Since the recurring todo is flagged in my process (i.e., I flagged it in the Planning view and than completed it in the Today view), the next instance of the todo is automatically flagged and would appear in my Today perspective as soon as it is available. What I end up having to do is unflag recurring items during my Review so they don’t automatically show up in my Today view when the todo becomes available.

Gotcha. I was thinking of rebuilding the Today perspective to show all available repeating actions without having to flag them. That way your built-in “Flagged” perspective could be uncluttered by repeating tasks and the need to toggle the flag for them each time.

Good idea but I don’t use the Flagged perspective. I just don’t understand how anyone picks tasks to do Today without using flags and running into this problem.

It’s a broader problem with repeating tasks. Most actions apply to the entire series of repeat instances. Except when you drop a repeating task, it defaults to “Just this instance”.

I find this just as frustrating as you. In my opinion, the default should be the opposite: any change should always only apply to the “head” of the series and there should be an option to force it to apply to the entire series or an entirely different action to do so. This would be easy to implement with a simple toggle in the inspector “apply to all”. Assume that any edits in a perspective (not the inspector) only applies to the instance shown, not the class.

There is a plugin called “Detach head” from Paul Sidnell I use to work around this but that clutters your database with extra instances.

It’s just one of these things where I find OF unnecessarily yet stubbornly unable to support the way I work. (I’ve been looking for the “perfect” setup for > 10 years and frustratingly there is always one or two things that, for no reason whatever, you can’t do that prevents you from setting it up the way you want. That’s why I’ve been clamoring for years to give us simply a pretty UI language with an SQL-inspired query syntax. That would solve all problems.)

1 Like

I would add in a couple of my own pet peeves here - the fact that Next Actions always inherit flags, tags and due dates of the parent - as being in the same category of problem here.

I don’t think your workflow or your use of flags is silly at all—this is actually a tricky issue, and I think recurring tasks are hard for all task managers to handle cleanly.

That said, here are a couple ideas that might help:

  1. Try the “Duplicate and Drop” plugin. It’s really useful for situations like yours. Basically, it creates a copy of the task for today (with no repeat), and drops the original. The repeat logic stays intact on the original, so the next instance will still show up in a few days like normal. You can then flag the new copy without messing up future occurrences.

  2. You might also consider how you’re using flags. Personally, I use flags more as a way to keep items on my radar that don’t have a hard date. So during my review, I flag things that feel important or that I want to keep visible—not necessarily things I’m committing to do that day.

But honestly, if your system works for you and this flagging issue is the only hiccup, “Duplicate and Drop” is probably the easiest fix without changing your whole setup.

I don’t know if anyone in this thread is a member of the Omni Slack channel, but I think a breakthrough was posted by a kindred spirit:

// COPY & PASTE into editor app. EDIT & SAVE with ".omnifocusjs" file extension.
/*{
	"type": "action",
	"targets": ["omnifocus"],
	"author": "Robert Opitz",
	"identifier": "com.opitz.of.complete-unflag",
	"version": "1.1",
	"description": "Completes a flagged task and sets the repeat to unflagged (only for repeating tasks)",
	"label": "Complete and Unflag Repeat",
	"shortLabel": "Complete and Unflag Repeat",
	"paletteLabel": "Complete and Unflag Repeat",
	"image": "powerplug.fill"
}*/
(() => {
	const action = new PlugIn.Action(async function(selection, sender){
		try {
			// selection options: tasks, projects, folders, tags, databaseObjects, allObjects
			selection.tasks.forEach(task => {
				// Only complete and unflag tasks that have a repetition rule
				if(task.repetitionRule){
					task.markComplete();
					task.flagged = false;
				}
			})
		}
		catch(err){
			if(!err.causedByUserCancelling){
				console.error(err.name, err.message)
				//new Alert(err.name, err.message).show()
			}
		}
	});

	action.validate = function(selection, sender){
		// selection options: tasks, projects, folders, tags, databaseObjects, allObjects
		return (selection.tasks.length > 0)
	};
	
	return action;
})();

Hat tip to Robert Opitz and the great @Sal !

I appreciate everyone’s suggestions. It is nice to know that I am not the only one that finds recurring behavior a little frustrating. I will try the plug-in, perhaps adjust my flag usage (the planned date feature may be a better way), or just live with the occasional annoyance of unflagging recurring todos.