[Scenario] Activity Type and Tag containment

[VWoeltjen]

Activity Type and Tags should have special rules for how they can be contained. Specifically, they should always be contained by one (and exactly one) template repository (e.g. "My Activity Types", "Mission Tags", etc)

Dragging from one template repository to another should move the Tag or Activity Type. Dragging into an Activity or similar should be a link (as it is now)

Remove Manifestation should not be available when selecting an Activity Type or Tag from within a repository, in order to preserve the exactly-one relationship.

Tag or Activity Type should not be available from the Create menu, except in a Create menu operating on a repository of the appropriate type. (If this is hard to suppress, then allowing Create in the context of an Activity is probably okay if the object additionally gets placed in an appropriate repository.)

[tdayton]

If you make this change, it will be critical to change pointer shape to indicate whether the pending operation from dragging is Add Manifestation or Move Manifestation. It is unrealistic and unreasonable to expect users to know which operation will result, based on the type of object being dragged, its source containing object, and its destination containing object.

[VWoeltjen]

Agreed on the underlying concern. I would propose to use a more explicit notification (dialog box?) to clarify what has happened, at least until nasa/mct#179 has been implemented (rationale being that user won't understand what the change in pointer shape means if it only occurs in this one circumstance)

[tdayton]

Sorry, I should have been clearer that pointer shape must be global, not just in this particular case. I forgot that MCT#179 existed to cover this case. If mct#179 is not going to be done yet, then yes, an alert box should be displayed, though it will be really, really annoying.

[VWoeltjen]

Boils down to four or five specific subproblems:

• Remove Manifestation should be disallowed for Activity Type or Tag in a Repository
  • Distinction is fuzzy in this case, but electing to grey out, as Remove Manifestation is allowable in principle for Activity Type or Tag objects, just not in the context of a Repository.
• Created Activity Type or Tag objects must appear in one repository (User Activity Types, or User Tags) in addition to the location where they have been created, or Create must be suppressed when parent is not a repository.
• Dragging a tag to a Repository should trigger its removal from all other Repositories
• If removal from all other repositories occurs, an alert should be shown
  • In principle, this should have an OK/Cancel; this may be hard to implement around current drag-drop, which doesn't seem to have any good hooks to cancel, so at least let the user know they can undo the operation by dragging it back.
• Maybe: Repositories cannot be deleted. (Need to think this through; restriction may not be necessary. Leaving here for reference when testing.)
  • This is already the case.

("Repository" above is a shorthand for the object types for User Tags, Mission Tags, etc...)

[VWoeltjen]

One potential circumstance not clearly addressed in design:

• User A has an Activity Type named "Driving (shadow)" in their own User Activity Types repository
• User A also uses the same Activity Type in a Timeline which they have made available under the Shared folder
• User B sees the Timeline under Shared, sees "Driving (shadow)" and decides this is something others should work with
• User B drags "Driving (shadow)" to Mission Activity Types

(Note: The above uses object names from the current top-level structure for clarity/reproducibility; these will change with #134)

According to the description of this issue, "Driving (shadow)" should then appear in Mission Activity Types and should no longer appear in User Activity Types (for User A). However, this presents a contradiction: User B has violated the ownership rules (since User A owns User Activity Types).

Possible ways to reconcile this:

• Simply allow this to happen, under the rationale that User Activity Types is somewhat of a special collection and ownership rules should not necessarily apply in this specific case.
  • This is the easiest solution, at this point, from an implementation perspective.
• Add "Driving (shadow)" to Mission Activity Types, but do not remove it from User Activity Types.
  • This may raise other design issues; e.g. how does User A remove it from User Activity Types, since we have previously stipulated that Remove Manifestation is disallowed for those repositories.
• Disallow the drop in the first place.
  • This is hardest from an implementation perspective, as it necessitates some changes to the platform (there is not enough information available to the policies involved in drag-drop)
  • This also raises workflow issues - only the owner of an object can promote it to the "mission" level, which restricts other current and future workflows (e.g. what if later we choose to restrict permissions on Mission Activity Types?)

Pursuing the first option (simply allow it to happen) for the present, as it has the fewest ramifications on other work.

[VWoeltjen]

Regarding previous comment, "ignore it" is fine for now; in the future, should be given the chance to copy instead of move the object. (This depends on Mission Tags having exclusive permissions, which it does not right now.)

If this has not been addressed at time of issue closer, spawn a follow-up issue.

[VWoeltjen]

Self-verified on Windows 7 using hackathon db, March 6 2014

Activity Type does appear in Create menu for non-repositories, but created Activity Types show up in My Activity Types automatically.