In the Publish as LTI Tools menu, the selector for a resource's "Role for teacher" will default to whatever role has the id value of 3 in the roles table; "Role for student" will default to the role with id of 5.

Those values should not be hard-coded, but should be configurable by a site admin since there is no guarantee those values will be suitable or even exist in the table.

Those values could be set on a tool-wide basis, in which case adding them to the user default values in admin/settings.php?section=enrolsettingslti would be simple and adequate.

My preferred solution would be a more complicated one: where arbitrary LTI roles listed in launch or members data would be interpreted and mapped to roles per tool deployment. This would allow different platform integrations to be configured differently and would allow for more granular control: for example, by having specific strategies for handling test students, teaching assistants, and platform site administrators, depending on however the given platform communicates those roles through the combinations of roles from the standard LTI role vocabulary or custom role strings.

An implementation for that would be for adding a configuration menu under enrol/lti/register_platform.php?action=view&regid=XXX&tabselect=tooldeployments#tooldeployments where at least these role mappings would be configured. That configuration could be stored as a json string in the plugin_config or as a row in a new table. It would be read by a function to replace the various role interpretation methods in tool_launch_service and sync_members.

It would be good UX for those methods to be callable from testing forms in the configuration menu so that site admins could paste in known role string lists their platform is sending and confirm that their configuration is interpreting them as intended.

Should enrol_lti support the basic tool-wide configuration or instead anticipate needs for deployment-specific configurations since different platforms may send different roles or different platform customers may want different treatment? Are there other deployment specific settings that should be considered in addition to role mappings?