Maintain tasks & participations

[IanMayo]

🐞 Overview

Analysts need to add and maintain the tasks and participations that are used to indicate which platforms are tasking part in which tasks.

While we have a document format that sometimes can be used to populate the initial data, the nature of naval wargames means that we can expect a number of daily changes. Pepys will also be used to record undertakings where the initial document isn't available. The complexity of this task justifies the provision of task-based editing environment (form).

This form would be accessed via (9). Maintain Tasks.

Design

Original here

🔗 Feature

601

🔢 Acceptance criteria

[robintw]

(Not urgent at all, I'm about to stop for the week)

What are the uniqueness criteria for a Task entry? Do they all have unique names? Or is it unique across (name, parent), or do we have to consider dates as well?

[IanMayo]

The tasks are unique for that parent.

It is quite likely that successive Joint Warrior exercises have serial called 05100.

[robintw]

Current progress on tasks GUI shown in video below. Includes the TreeView widget I've written, plus loading the Tasks from the database, and adding a new entry to the TreeView (this doesn't yet add a new entry to the database, and you can't yet view information on the task).

Still lots more to do (including styling and lots of UI stuff), but I've made progress.

[IanMayo]

Great progress @Robin. One comment - we have the user's endorsement to restict the data to 3 tiers. So, we won't need the children of ADEX 324.

The presence of this constraint means we may be able to make other assumptions on the data, assumptions that let us change the UI according to level - such as:

• tasks in Tier one don't take a start/end date, or participants
• tasks in Tier two have start/end date and participants
• tasks in Tier three have start/end dates and a subset of the parent participants

[robintw]

A few questions @IanMayo:

1. How is the force that a participant is part of represented in the database. I see there is a string force field in the Participants table - is it as simple as just setting that to "Blue" or "Red"? Can the force ever be anything apart from Blue or Red?
2. In the UI mockup, there is a Comments field when editing a Participant. There isn't a comments field in the schema - does this need adding?
3. There are a few fields missing from the UI mockup - do these still need to be edited? The missing fields are privacies for the Task and the Participant (does the Participant inherit from the Task if it isn't set?), and environment and location strings for the Task.

[IanMayo]

Hello @Robin,

1. In discussion with the clients they were quite sure there was only a requirement for Red/Blue. For more than that we would probably need a Forces table. Suggestion: Maybe stay with string for now, and switch to foreign-key table if we need to in the future. Our UI can force it to be values of "Red" or "Blue" - so we know we have clean data in case we ever need to transition to the Forces table.
2. Comments. Yes, this is probably related to the extra data which is available in the MS-Word doc. I've just checked. The client put in this comment:

So, while Celine saw the column and supported it via "Comments", at that point in time the clients were clear they didn't need it to be capture. So, no comments field :-)

3a. Privacy Sadly we do need privacy for Task and Participant, but we can provide sensible defaults. For a task we should use the privacy of the parent task (or the lowest privacy for a top level task), and for participant, let's take the highest value of either Platform or Task. 3b. Environment and Location. Let's leave these for the future. They are present in the CET_FIT document that the clients expect to receive next month, but we may/may-not choose to support import of that. If we do implement import then we'll insert the data (since no-one has had to type it). But, if we don't do import, then let's ignore the field - the analysts can always refer back to the CET_FIT.

[robintw]

I'm continuing to make progress with this - you can now save and load values for Tasks. Next step is integrating Participants, and I have a few questions @IanMayo:

1. What are the uniqueness constraints for Participants. Can you ever have the same platform participating more than once in one Task? For example, as both Red and Blue (I note in the mockup screenshot, HMS Nelson is in both Red and Blue)? Or twice as the same force, but with different start/end times? The simplest uniqueness constraint would be on task_id and platform_id (so you can only get each Platform participating in a single Task one time) - but I'm wondering if that will be too restrictive.

2. I see you want to be able to filter the TreeView by typing in a text box above the TreeView. When some text is typed in the filter, do you want to just show the matching entries, or show the matching entries plus all their parents. That is, if we type ADEX, should we just see the ADEX entry by itself, or should we see the Joint Warrier and Joint Warrier 20/02 entries above it too (to give context to the entry)?

3. You can see in the screenshot below that an 'Add' button appears to the right-hand side of an entry when it is selected - and that button will add a new child to that entry. However, the question is: how do we add a new top-level entry? As suggested in one of your previous comments, I'm using a 'hidden root' - so the top-level entries do have a parent, a hidden 'Tasks' entry - but because it is hidden we can't see the Add button next to it. We could put an 'Add' button below the TreeView, and use that for anything we want to add - or we could have just an 'Add top-level' button (with better wording) and use the 'inline' Add button for doing all other adding. What do you think?

[IanMayo]

Afternoon @robintw - I did try to have a play this afternoon by downloading the artefact. But, it's not in the admin gui yet - and I could come up with the python to start your example. Never mind - I don't want to interrupt your progress.

1. Participants. Let's go for the simple solution first. A platform can only participate once in a task. I can imagine scenarios where a participant takes part twice in a really long serial, but I don't know if that actually happens in real life. I'll double-check that though.

2. Yes, I think we do have to show the parent tree - to give context, as you say.

3. Ok. An Add task button at bottom of the list, on a line of it's own? I think it's worth adding Task. For the existing Add we have the context of what appears to the left of the button. But when it's on a line on its own we should give a little more context, IMHO.

[robintw]

Ah yes, I haven't integrated it into the Pepys Admin interface yet. That won't be hard to do, so I'll do that shortly so you can have a play.

Responses to questions all sound good - just one more question about number 3: Do you want the Add task button instead of the 'inline' Add button, or as well as the existing button?

[IanMayo]

3. Keep the inline Add button next to a task, but include Add task at the bottom of the listing, to add a new top-level task.

[robintw]

@IanMayo You should be able to download a build artifact from the PR now, and access the GUI through the Pepys Admin menu. Participant editing isn't yet implemented, but you can now select Tasks from the tree, edit their data, save or delete them etc. There is also filtering in place for the tree view (though see question below). Have a play!

I have a question about filtering. Currently, when you type to filter, it displays any entries that match, plus all their parents. So, for example, when I type AD, I get the following: However, this means that if I type 20/02, I get the Joint Warrier 20/02 entry, but none of it's children are displayed. Am I correct in assuming that we want to display any children of the matched entry too? I thought I'd check before implementing it, as it will require a bit of a conceptual change to how the recursion works. I automatically expand the parents of the entries that match, so you can see the matching entries. I can keep the children of the matched entries collapsed, so it still looks clean.

Also, would you like the matched entries to be highlighted? At the moment I've got different colours for different levels of the tree (partly to help me with testing, partly to show that it's possible, in case you wanted the top-level ones to be a different colour). Obviously we'd need to decide what colour meant in the tree, and if we had a different colour for top-level entries, plus a different colour for matched entries, then it might get confusing.

[IanMayo]

Morning, good questions...

Yes - I think it's unavoidable to show the collapsed children of matching fields.

Highlight matching entries: It would be "fancy" if we could highlight text snippets within titles that match - but I don't know if we have that level of detail in formatting. If we can't highlight the snippet then I guess we highlight the whole name.

As for style of highlighting - I'd be interested in hearing how you get on with just marking it as bold.

Colors in general. Since we have quite bold colors, IMHO it could be overkill to shade each level differently.

[IanMayo]

Note: text in entry boxes can't be seen on MS-Windows:

[IanMayo]

I know it's new code - so I'm bound to be testing paths that haven't been followed before :-)

I got this while adding a second top-level task:

[robintw]

@IanMayo Thanks for the answers to the questions - and the comment on Windows colour issues, I'll turn on my Windows machine later and investigate.

I've just tried to reproduce the crash you got, and adding a second top-level task seems to work for me. Can you try and reproduce it and let me know exactly what you have to do to trigger it?

[IanMayo]

Separate work-flow. I added a child task.

When I re-selected the parent task, I got this:

[IanMayo]

I tried to save a third-level task that didn't have start/finish dates, and got this:

[robintw]

Are you sure you're using the artifact from the latest version? I was pretty-sure I fixed all the bugs with 'Task is not bound to a Session'. Again, I can't seem to reproduce here:

[IanMayo]

When we add a new child task, could the new (blank) one be selected in the right-hand side please?

[IanMayo]

Sure - will check I'm on newest release.

[robintw]

I tried to save a third-level task that didn't have start/finish dates

Yes, that's expected at the moment: validation of data all being present when saving isn't implemented yet - it's on the todo list.

[IanMayo]

(will pause on playing until we have the font colors sorted) Added third-level entry. Then I selected second-level parent entry, and got this:

[robintw]

Added third-level entry. Then I selected second-level parent entry, and got this:

Can you send a short screencast of you doing that? I really thought I'd fixed all those bugs...

[IanMayo]

Note: I'm connecting to the tracstor database - so you should be able to connect to it, too.

Screencast. When I select the tier-two task it repeatedly fails. https://i.gyazo.com/fe2839ea974409566a5a2275502ecdec.gif

[robintw]

Right, I managed to reproduce that bug, and I've fixed it.

I've also changed the styles so that the text is visible on Windows:

I wouldn't say it is "pretty" yet, but it is at least useable. I'll work on better styling once I've got more functionality working.

[IanMayo]

Great. Popping out - will give feedback later.

[robintw]

Fixed in a combination of PRs - clients are now using the new Tasks GUI.