Key management/tracking

[bgillock]

One part of an operation is managing keys. This usually happens early on and usually is a stealthy action. In large operations, as a team gets closer to the operation, keys need to be distributed to other agents. The ability for a planner/operator to track who has what keys is very important. There is some functionality in place to enter key counts, but that is all. There is even a plugin to automatically add keys from an agents inventory. This is addressed in the first 2 user stories below. Here is a start to a list user stories to help guide the development of this enhancement.

1. As a boot, I want to inform the planner which keys, needed for the operation, I currently have, automatically by looking in my inventory.
2. As a boot, I want to inform the planner which keys, needed for the operation, I currently have, by manually entering the key count.
3. As a planner/operator, I want to assign a task to a key holder to transfer keys to agents who need them to make links.
4. As a planner/operator, I want to assign a task to a key holder to transfer keys to agents who will use them for defense of the portals.
5. As a planner/operator, I want key transfer tasks to automatically change to completed when the receiving agent has the required key in inventory, automatically or manually.
6. As a planner/operator, I want to see the list of defensive keys and which agents have them.
7. As a planner/operator, I want to see which links cannot be made because assigned agent does not have a key.

[cloudkucooland]

(1) "automatically by looking in my inventory" belongs in an external plugin - the rest is in place
(2) this is in place in the webui
(3) yes. currently the "meet agent" marker type is used for this.
(4) defensive key stuff should probably be distinct Feature request since W-D keys is different than op-keys.
(5) "automatically" is hard
(6) W-D keys does this already
(7) This does exist in the webui. My proposal in Wasabee-IITC is to have it on the anchor popup and in the checklist or link dialog. I thought we had it in the keys dialog?

[le-jeu]

Markers don't cover well key transfers. Planner/operator won't define for players a location for every exchanges, specially when the keys travel from agent to agent across a country/the globe.

[bgillock]

The current APIs for KeyOnHand is not designed to handle multiple capsules containing the same key. There are two APIs, one is to get the complete Draw. Proposing this for the keysonhand portion:

The other is an atomic update of the server. Proposing this for the keyonhand POST API:

This API is preferred because it updates the key on hand for the current gid, portal and op to be the content passed. The current API requires the passing of a zero count with a capsuleID to remove the capsule. This behavior can be problematic when left to the client to manage.

• Notice json is passed in the body instead of multipart-formdata to allow for arrays to be passed in the POST.
• The onhand count outside the capsules is to represent the number of keys the user has for the portal directly in his inventory. Better naming may be warranted.

[cloudkucooland]

since the top "on hand" is just the sum of the values in the capsule arrays, isn't it redundant? What purpose does it serve other than what we could get from adding the values in the capsule array?

[bgillock]

It is not the total keys on hand for that portal, but rather the number of keys for that portal that are NOT in a capsule, ie. in Keys list ready to link. I agree poor naming on my part. Any better ideas?

[cloudkucooland]

That's helpful. Do we need to distinguish between capsules and lockers? Or for our purposes are they the same (except lockers cannot be dropped....). What does CORE do here?