First we need to discuss how sorting works in a hierarchical view. Then we can discuss computed score.
Until the current version, MLO allowed hierarchy -or- sorting but no view had both. In MLO v4 we got the ability to sort a hierarchical view. It's a relatively new concept and may not yet be fully mature or debugged. When you create a sorted hierarchical view, it's composed in three steps: 1. Apply the filter to determine which items will be included in the view. Set them up as a flat list 2. Sort the flat list according to the sort specs for the view 3. attach the parent and/or child hierarchies as specified. This doesn't change the order of the original flat list except that any item that appears in a hierarchy under some other item can't appear separately in the list. In the "all tasks" view the flat list from step 2 would be the list of items at the root. As a result, if you change the sort specs for "all tasks" it changes the order of the root level items but everything below the root is unaffected. In the "next actions" view you have been working on, the flat list that gets sorted is *not* (with one exception) the list of projects. It's the list of next actions. The exception is that for a project with no active subtasks, the project itself is the next action. So if you turn off the hierarchy and just make a flat list of next actions, the list should show the next action from each project that has active subtasks, the name of each project that has no active subtasks, the next action from among the active subtasks of each folder, all active actions at the root, and for any task that has active subtasks, the next action among them. Try it and check if this isn't what you get. Then you can turn on the parent hierarchy (no parent filter). For every item that's at the root this should add the project or other parent, together with any other higher hierarchy. Try it and see. You should also be able to turn off the parent hierarchy and set any arbitrary sort sequence, and see the tasks from your flat list, line themselves up according to the sort spec. And then turn parent hierarchy back on and notice that the tasks haven't moved. And that brings us to the most important part: YOU NEED TO SORT THE LIST OF NEXT ACTIONS IN ORDER OF THE PRIORITY OF EACH ACTION's PARENT PROJECT. That's a little weird, as usually when you sort a list it's according to the characteristics of the members of the list. In this case it's according to the characteristics of parents of the list members, and the parents are not even present (for the most part) in the list being sorted. If you look at the list of sort criteria there's no "parent project priority" or anything like it. The only thing that comes anywhere close is computed-score. Which brings us to the discussion of computed-score. First, this disclaimer. I don't like computed-score and I don't use computed-score. I find it too hard to understand what it's doing, and too hard to make it do what I want. My reason for using any task manager is to use less of my mental capacity thinking about my tasks and more of it getting them done. With computed-score a big part of my mental capacity goes to endlessly tweaking the computed-score. However, if you want to sort a list of actions into the order of their parent projects' priority it is your only choice. Computed-score tries to show each action's priority as an absolute number across everything in the database. For the purposes of computed-score the "importance" and "urgency" in of the action are not absolute numbers, but rather show the relative importance and urgency of this task towards accomplishment of the task's immediate parent. And the parent's importance and urgency show the parent's priority towards accomplishment of the grandparent. So the computed-score of each action shows the cumulative effect of the importance and urgency of every item in the hierarchy all the way back to the root. And it's not just importance and urgency, you can include calculations based on how close is the start date and the due date. You can give extra points if the action is overdue. You can give more points if it's a weekly goal. The objective is to sort the list by priority of the parent project. It seems to me that the best way to do that would be to ensure that every subtask has importance and urgency of 100, or normal. in Options, turn off extra points for overdue tasks, and set the weight for start date, due date and weekly goal as low as possible. Be sure to turn on "show computed score values on task statistics" so you can see what's going on. Now you should be able to look at each of your next actions, look in the task statistics, and see the computed score reflecting its parent tree. You probably can't make any actual sense of the computed numbers, but you should be able to verify that the task with a higher priority parent gets a higher computed score. (If this does not work you will need help from someone, either user or staff, who understands computed score better then me.) - then, by setting sort criteria to computed-score you should be able to see your next-actions as well as their parents sorted into the desired sequence. One last point, I believe that the right way to exclude folders and their subtasks from this view is what you did, selecting parent hierarchies to be displayed with a parent filter of (not(isfolder)). Unfortunately this does not work, because as soon as any parent filter is specified, all tasks at the root (ie tasks without a parent) are dropped from the view. I tried thinking of other parent filters to use to try to select for everything but folders, but it didn't matter. Any parent filter, regardless of its settings, excludes all root-level items, even including root level projects that have no subtasks. I can't imagine how this would be correct. I can see how there would be a need for a filter that would reject any item that's at the root and therefore is parentless, but that cannot be the correct outcome for every parent filter regardless of its content. This appears to me to be - can i say it - a bug. I would love to hear from anyone who can rationalize how this might not be a bug. Even better would be anyone who could offer a way to exclude root-level folders without also excluding root-level actions and root-level projects with no active subtasks. If nobody shows up in a couple of weeks to respond to this challenge, then I will presume that this is a bug and report it as such. -Dwight On Thursday, December 4, 2014 12:47:35 AM UTC-5, Dwight Arthur wrote: > > My conclusion is that my treatise on computed-score may still be > necessary. Will attempt to get it out in the next 24h > -Dwight > Mlo betazoid on Android sgn2 > >> >> -- You received this message because you are subscribed to the Google Groups "MyLifeOrganized" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/mylifeorganized. To view this discussion on the web visit https://groups.google.com/d/msgid/mylifeorganized/9efc4464-bb7f-4a82-928f-043785a57f7e%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
