We've gotten to the point where we need to introduce a basic implementation for tool placements, so that we can start to properly build out some of the placement-specific functionality.

Some examples of issues that start to touch on placements are:

• MDL-83954 (the tool placement needs to be passed through deep linking and core needs to ask the placement implementation to participate in access control checks)
• [MDL-83509, MDL-81864]: Soon, resource links will be tied to specific placements (or, at least will be created via them). We need the relevant placements data structures to support this link between resource links and placements. Backup and restore also needs to be aware of the placement structures so it can properly restore placements when restoring course tools (site tools are not backed up nor restored).

This issue is scoped with adding the initial placements implementation.

At the high level, this involves adding the foundations for the 'placement type' and 'placement' concepts:

• • A 'placement type' is just a unique string, e.g. 'mod_lti:activityplacement' and represents the potential use of the LTI tool somewhere. Somewhere the LTI tool appears, basically (e.g. as an activity, in course navigation, in the editor, etc). Components can advertise placement types if they use LTI somehow, and core can also advertise placements for any tool uses that may live in core code.
  • A 'placement' is a mapping of tool:placementtype and can be thought of as additional configuration for the tool. A placement is configured as part of tool configuration as a way to say "This tool can be used in <some area>". A tool can support many placements, depending on where it's expected to be used.

More specifically, this includes:

• New tables for placement type and placement
• Add the mechanism for components to register their placement types with core_ltix
• Add the placement type 'mod_lti:activityplacement' to mod_lti (+ make sure it's registered with core_ltix)
• Add an upgrade step to add a placement (a tool:placementtype map) between every tool and the 'mod_lti:activityplacement' placement type. This is essential because, up until now, a tool is assumed to have been usable as an activity, and we need to maintain this. This is a data-only change. No UI needed yet.

I think there's also a few separate pieces of work needed to:

• Add some minimal UI, allowing placements to be configured at the tool config screens.
• automatically enable/check the 'mod_lti:activityplacement' for any new tools being created (or provide form defaults during creation).

but I think these can be done in related issues. For this issue, it's more around the data structures and basic registration mechanism.