Moodle

FWIW, I think the correct solution is to add a list of fields that are sent/received by both the IDP and the SP, and then use the intersection.

Here's how I think this should work:

• New setting (multi-select): profile fields to send
• New setting (multi-select): profile fields to receive

In the config screens, a notice that the intersection of these two will be used.

This could either be:

1. Global (in networking settings)
2. Per networked host

I don't think it belongs to either auth/mnet or enrol/mnet, because both of them create users on remote hosts.

I'm leaning towards making this a global setting, even if it's less flexible, purely because otherwise it's a real pain to set up for sites with multiple hosts

The question remains: what to do about custom profile fields? I think this should be an extra setting in the "profile fields to receive" page with the following options:

• import custom fields and map them by name, discarding any non-matches
• import custom fields and map them by name, creating any non-matches (harder?)
• ignore custom profile fields

The 'sending' page can just add them into the multi-select with a "Custom: " prefix.

Or we could just refuse to send/receive custom profile fields.

So: questions -

1. Where do we think the new setting pages should go? Global or per host?
2. What do we think about custom profile fields?
3. What fields should the upgrade to 2.0 add as the default?

watcher ping - ideas please!

Hi,

1) About the global / per host lists of fields, which is the rationale (or use case) to have it per host? Does have sense something like some hosts being more "friendly" or "safer" in order to populate them with, say, institution, while we want to keep that info not pushed to other hosts? If the answer is yes (i.e. if there are reason to have different "field profiles" - uhm!! - then per host).

2) About the lists themselves, I think it's ok to have two. One for user fields and another for custom fields. In any case, I'd never be creating new custom fields automatically. Just the matching intersection strategy always (note that, perhaps, you'll need to match name + type in custom fields, at least it sounds to me I had some problems with that on restore).

3) User tags? Any other user information?

Ciao

Thanks Eloy for commenting

1. Yeah, different friendliness or safeness for different hosts. I think it would potentially be a pain to fill out multiple times though. The most flexible is probably to have a global list, but then have a setting PER HOST to override it from what the global settings are.

2. Yes, I'm sure you're right about the custom profile fields. I wonder actually, if in reality there's any point actually sending them. What do we think of the use-case - can we imagine a case where we'd either want to automatically create custom fields, OR have two sites with the same custom field definitions?

3. Argh, I hadn't thought of that

sorry for the late comment... just got back from leave.

what happens if the field name is different in each host?
eg a NZ based host with "Country" as the customfield name
and a German based host with "land" as the customfield name
(or a Moodle and Mahara host with differing names for the same thing)

it would be nice if we could obtain via mnet - a list of the available fields and allow them to be mapped to an existing field?

edit - which would require seperate config per host - with sensible default settings.

For the meantime, I'm not doing custom fields. I agree that would need to happen.

Can someone do some testing on this for me? I put it in HEAD today.