[ambitions2o]

So I am having a problem with my "Available" and "Remaining" in the Availability Filter. For example I have an action that started this morning and was due in the morning. However I could not see the action when the Availability Filter had been set to "Available". So I would change it to "Remaining" and I could see the action.

Details of the action:
- Located in a SAL
- Double checked the start and due time and there were set correctly

Is there something between the two that I am missing?

In search language terms:

'Remaining': (completed=false)
'Available': (completed=false) and (blocked=false)

('blocked': the task is in a project marked as sequential, and there are earlier tasks which have not yet been completed).

You can free this up by re-designating the project type as 'parallel', using the 'type' section of the project inspector.

(It might also be worth re-visiting OmniFocus > Preferences > Data > Projects & Action Groups and reflecting on whether you would prefer 'parallel' as the default.)

--

[whpalmer4]

It would be worth checking to make sure that you haven't set a (future) start date on the SAL itself, or put it on hold. Doing so would also cause the same behavior you are seeing. If you add another action to the SAL, without any start date, and it behaves just like the first one, then the issue is almost certainly that the SAL itself is not available and thus neither are its actions.

That's a good point :-) I must update the definition of 'Available' in the FAQ and in the Where in OF script abbreviations.

(There may be scope for updating the help file too - at the moment it only seems to explain the filtering of 'available'/'blocked' in terms of sequential projects).

At the moment the Help section Using the view bar to filter and arrange items > Availability filter simply says: "Available actions (things you can actually do, because they aren’t blocked by earlier actions in a sequential project)".

In fact, on reflection, there are a number of unmentioned additional conditions - for a start:

• completed=false
• start date < now
• (its context is missing value) or ((allows next action of its context is true) and (hidden of its context is false)) -- context (if any) neither on hold nor dropped
• (singleton action holder of its containing project is false) or (start date of its containing project < now) -- not contained in an SAL with a future start date
• status of its containing project is active

Any more ?

So far, the search abbreviation might look like:

[Available]->(blocked is false) and (completed is false) and (start date < now) and ((its context is missing value) or ((allows next action of its context is true) and (hidden of its context is false))) and ((singleton action holder of its containing project is false) or (start date of its containing project < now)) and (status of its containing project is active)


--

[ambitions2o]

Here is an example:

Project:
- Sequential
- No start or due date
- Each action is a repeating action
- Start again : 1 day after completion

Here it is on Remaining filter, however when I go to Available I am unable to see the actions. The action on top has already been completed for the day, so shouldn't the next one be in line to show up?

Originally Posted by ambitions2o

- Each action is a repeating action
The action on top has already been completed for the day, so shouldn't the next one be in line to show up?

That is a reasonable expectation, but the interpretation seems to be that a task which is going to repeat at some point in the future is not 'complete' and therefore continues to block any successors indefinitely. (This is probably rational, because as soon as a repeating task is ticked as 'done', its repetition is instantly engendered, and is still in front of any successors ...)

The bottom line is that sequential projects are not currently a natural home for repeating tasks. If you want to make good use of the 'Available' filter you probably need to switch the parent project to parallel ...

(Perhaps a repeating action group would work better ?)

--

[whpalmer4]

Your problem is you are combining sequential execution and repeating actions. If you do this, you need to have the repeating unit be the entire project or an action group containing all of the actions which are to repeat. You don't want the actions themselves to repeat unless you have parallel execution, such as a a parallel project or action group or a single action list. Otherwise, the first item immediately blocks everyone following it when it is completed and the new action created, as you have seen.

If these tasks need to be done sequentially, then use the repeating action group or repeating project approach. Choose the repeating project or repeating action group based on whether this collection of actions is part of a larger project, and whether the ability to review and/or manipulate as a project is important. Action groups do not show up in the stalled filter, cannot be put on hold or dropped, and cannot be independently reviewed.

If they don't need to be done sequentially, the parallel or SAL approach offers the advantage that each completed action will repeat even if you don't get the whole list finished off, and you can have different repeat intervals for different items.