Details
-
Type:
New Feature
-
Status:
Closed
-
Priority:
Major
-
Resolution: Incomplete
-
Affects Version/s: 2.0
-
Fix Version/s: None
-
Component/s: MNet
-
Labels:None
-
Difficulty:Difficult
-
Affected Branches:MOODLE_20_STABLE
Description
As discussed with MD, and documented at
http://docs.moodle.org/en/Development:mnet_phase2
Attachments
Activity
- All
- Comments
- History
- Activity
- Source
- Test Sessions
Thanks Petr,
Despite appearances the upgrade was tested in general, but not the specific path which contained the old 'update_record' I had missed. Existing mnet code in 2.0 which creates the records the upgrade was intended to deal with is broken for postgres, -> no data -> no error in testing -> 
Sorry for the trouble, thanks for the time you spent rolling this back.
I'm still keen to see if your concerns can be addressed, so I'd like to explore some of them a little further:
I'm not sure what you mean by problems with localized strings - can you give me an example?
I wasn't aware of a drive to move mnet specific fields out of core tables, but I can see that this makes sense. With a little work my patch could be changed to neutralize this concern.
It makes sense to avoid changes that I will need to rework after enrolments changes, but I expect all enrolment plugins will need very similar changes, and I will have good examples to draw from.
If I recall correctly, my patch did not change underlying mnet transport mechanism, so I didn't think this patch moved us either toward, or away from web services implementation.
At present I'm trying to think my way through a plan as to if and how this patch, (and mnet enrolment/auth generally) could be dual-implemented so that it continues to work with moodle 1.9 remote peers over mnet, and can talk over web services to 2.0 remote peers, (under various scenarios). (the mnet channel could be fully removed later - 2.1?). Do you have any thoughts on this front?
Under what conditions could we proceed with an improved patch, later performing the necessary changes to accommodate changed enrolment structure?
PetEr
Sorry for the trouble, thanks for the time you spent rolling this back.
I'm still keen to see if your concerns can be addressed, so I'd like to explore some of them a little further:
I'm not sure what you mean by problems with localized strings - can you give me an example?
I wasn't aware of a drive to move mnet specific fields out of core tables, but I can see that this makes sense. With a little work my patch could be changed to neutralize this concern.
It makes sense to avoid changes that I will need to rework after enrolments changes, but I expect all enrolment plugins will need very similar changes, and I will have good examples to draw from.
If I recall correctly, my patch did not change underlying mnet transport mechanism, so I didn't think this patch moved us either toward, or away from web services implementation.
At present I'm trying to think my way through a plan as to if and how this patch, (and mnet enrolment/auth generally) could be dual-implemented so that it continues to work with moodle 1.9 remote peers over mnet, and can talk over web services to 2.0 remote peers, (under various scenarios). (the mnet channel could be fully removed later - 2.1?). Do you have any thoughts on this front?
Under what conditions could we proceed with an improved patch, later performing the necessary changes to accommodate changed enrolment structure?
PetEr
Interface allowing an administrator to control how local user role assignments should map to remote role assignments.
Local administrator links local roles to either nothing, or a role that is published by the remote administrator.