[Building Sakai] Promoting non-provided users to being provided

[John Norman]

Is this a good time to ask about general assumptions? What I have in  
mind is that the SIS provision could simply be regarded as providing  
information (who is registered for the course) and how that  
information is processed could be variable by site policy. So you  
could have a 'strict' membership policy which means only those with  
current membership in the external provider have access, a 'loose'  
policy that means all who have ever been added to the course are  
visible with an indication of registration status and the site owner  
manually maintains active status or responds to changes in  
registration status, and 'intermediate' which automatically de- 
activates or activates a registered status and access but leaves  
historic information for manual intervention. It could be an  
institutional configuration option to enforce a site membership policy  
for all sites of a certain type (or not).

This is probably not the best scheme, but I have often wondered what a  
good general solution would look like.

John

On 31 Aug 2009, at 14:31, Sean DeMonner wrote:

>> This would carry the risk that a manually added student could find  
>> themselves dropped from the site if they registered for a course  
>> and then dropped it, but that seems more of an edge case compared  
>> to the more common query above.
>
> That seems like a reasonable risk to me -- typically if they're  
> being manually added before the Provider picks them up it's because  
> the instructor wants them to have access *right now* and can't wait  
> for the SIS to sync. Presumably if they drop the course later, they  
> really no longer want to be part of it and should be removed by the  
> provider. Worst case, they'd have to request to be manually added  
> again.
>
> SMD.
>
>
>
>
>
> On Aug 31, 2009, at 9:18 AM, Stephen Marquard wrote:
>
>> Hi all,
>>
>> We had a query today which was basically "I want to see which  
>> students in the course site are not registered for the course".
>>
>> In the course in question, a number of students were added before  
>> the official registrations came through, so they started out non- 
>> provided, but subsequently became officially registered.
>>
>> However, in Site Info, those users don't have the course code  
>> showing up in the 'Enrolled' column because they are non-provided  
>> users. If you delete them, they come back as provided users.
>>
>> So currently there's no good way to answer the question.
>>
>> It seems to me it might be useful to have non-provided users get  
>> promoted to provided users when the realm is updated, if their  
>> provided role is the same as their non-provided role.
>>
>> This would carry the risk that a manually added student could find  
>> themselves dropped from the site if they registered for a course  
>> and then dropped it, but that seems more of an edge case compared  
>> to the more common query above.
>>
>> Any views?
>>
>> Regards
>> Stephen
>>
>>
>>
>>
>> Stephen Marquard, Learning Technologies Co-ordinator
>> Centre for Educational Technology, University of Cape Town
>> http://www.cet.uct.ac.za
>> Email/IM/XMPP: stephen.marquard at uct.ac.za
>> Phone: +27-21-650-5037 Cell: +27-83-500-5290
>>
>>
>>
>> _______________________________________________
>> sakai-dev mailing list
>> sakai-dev at collab.sakaiproject.org
>> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>>
>> TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe at collab.sakaiproject.org 
>>  with a subject of "unsubscribe"
>>
>>
>
>
> SMD.
>
>
> ==========================================================
> Sean DeMonner, IT Senior Project Manager, CTools Implementation Group
> Digital Media Commons @ The Duderstadt Center, U-M      (734) 615-9765
> Pub Key 24DD6B09
>
>
>
>
>
>
>
> _______________________________________________
> sakai-dev mailing list
> sakai-dev at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>
> TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe at collab.sakaiproject.org 
>  with a subject of "unsubscribe"

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai-dev/attachments/20090831/eba090b4/attachment.html