Auto-fill the presenter name with the info from /me/json

[miesgre]

In the upload dialog, Auto-fill the presenter name with the info from /me/json

Maybe in the settings.json an option to enable or disable de auto-fill and to enable or disable if the user is able to modify it ????

[LukasKalbertodt]

This is slightly problematic, as most actual users will come from an LTI context. The username in info/me is something like not a human-readable name, but LTI_0934204 or something like that. Even /lti does not give us the correct name of the user, unfortunately.

Interestingly, right now I added the feature that stores the last presenter name in local storage. That means if the user visits Studio again with the same browser, that name will be auto-filled. That means that in theory, users only need to specify their name once. Would that help with your use case?

[mtneug]

This is not necessarily true. E.g. in the case of Moolde, if you configure it with a highly trusted consumer key (see [1] and [2]) and in combination with the Moodle user provider, Opencast uses the username passed by LTI and fetches the other details from the user provider. I imagine the same is done for Sakai.

Using the name and if not set username as a default seems like a good solution to me. And even if the username is just an ID, users can overwrite it with #543.

[1] https://docs.opencast.org/r/8.x/admin/#modules/ltimodule/#configure-lti
[2] https://github.com/opencast/opencast/blob/develop/etc/org.opencastproject.security.lti.LtiLaunchAuthenticationHandler.cfg#L3-L19

[miesgre]

@mtneug +1

[LukasKalbertodt]

@mtneug Interesting to know!

Studio could apply a simple heuristic to see if the username is a useful presenter name or not. Maybe just check if the username is admin or opencast_system_account or if it starts with LTI_. In those cases, Studio would treat the username as "not a useful presenter string". Otherwise, the username would be used as default value for the presenter field. Sounds reasonable?

[mtneug]

Sounds good. I think the username for none-highly trusted consumer key actually is LTI:... so I would maybe check for LTI_ and LTI:.

[lkiesow]

Please don't build another weird assumption in. We already have the fix for the other ugly LTI hack on the roadmap (#511). Also, note that LTI is just one way of identifying against Opencast. A lot of people do not use LTI but different authentication methods.

My suggestion would be to ignore the username but use name in case it is available since that field is meant to be a full name.

LTI also suggests fields for transmitting the user's name. Not sure if that is used at the moment, but it would certainly not be hard to support that.:

• lis_person_name_given=Jane
• lis_person_name_family=Public
• lis_person_name_full=Jane Q. Public

[LukasKalbertodt]

My suggestion would be to ignore the username but use name in case it is available since that field is meant to be a full name.

For admin it's "Opencast Project Administrator". I don't think it's a good idea to use that as default value. Even better: when I use our Stud.IP test system to get an LTI session, the name from info/me.json is exactly the same as username (starting with lti:). So much for "that field is meant to be a full name."

But I agree with you, we shouldn't add some dirty hacks here. I'm completely fine with adding this feature if we have a no-false-positive check for a "real name". I'd prefer to keep the field empty instead of filling in a value that is not the user's full name. That's because most users will just keep this garbage value and upload. That's not what we want.

[miesgre]

How about a setting in the setting.json file? so, each institution can configure if the field is auto-filled or not.

[LukasKalbertodt]

I checked for our institution again and neither /info/me.json nor /lti provides any useful name string. The field lis_person_name_full seems like a useful source for the name if it is defined (which it isn't in our case). I could easily implement that, but without system to test it, I'm not comfortable releasing it.

If we were to add a value in settings.json to configure whether to auto-fill, we should probably also make the source for the name configurable. I am not sure if this is really worth it, to be honest. Since the user's name is stored in local storage, we are just talking about typing the name once (per device/browser).

@lkiesow What do you think about the two points above?

[lkiesow]

The LTI values should be automatically picked up in Opencast by now:

• LTI User Data opencast/opencast#1629

This means that we now should be able to use the name from /info/me.json as a default.
It probably still makes sense to only use this as a default, and let users change the name if necessary.
Basically:

• Let users set a name
• Default to local storage, if there is a value
• Default to name from info/me.json

[Rillke]

Apparently this is being addressed in #1037

[JulianKniephoff]

Resolved by 59bea17