Actions

Difference between revisions of "Developer Area/Specifications in Development/Groups csv create"

From Mahara Wiki

< Developer Area‎ | Specifications in Development
(extra csv format, and member types)
Line 30: Line 30:
 
===CSV to enrol users into groups===
 
===CSV to enrol users into groups===
  
This file will need to have group shortname, user studentid
+
This file will need to have group shortname, user studentid, member type
  
 
* The studentid will be focused on to start with, then other ways of identifying the user
 
* The studentid will be focused on to start with, then other ways of identifying the user
 
may be created, such as username or email
 
may be created, such as username or email
 +
 +
The member type will show either admin tutor or user
 +
 +
This would need to keep track of all the users in this file for each group, and remove extra users from groups listed
 +
in this file, but don't have that username.
 +
 +
 +
===Alternate CSV Format===
 +
 +
Use one CSV, will have the following in it
 +
groupname, groupshort, groupdesc, grouptype, adminusers, endofadmins, tutorusers, endoftutors, normalusers
 +
testgroup,test,a test group showing csv strut,controlled,admin1,admin1,!,tutor1,tutor2,!,user1,user2
 +
 +
Here we have a list of all users, seperated into member types, between each type is a ! to delimit them
 +
This can be processed by a loop that runs til it gets a ! and changes user type
 +
 +
This allows for the functionality of removing users that aren't in the file, though
 +
it has the side effect of having group metadata and users all in one file.
 +
 +
I (Hugh) would suggest the first two formats, and have two seperate files for creation and population/updating

Revision as of 16:07, 24 May 2011

ToDo

The following changes would need to be made to allow this.

  • Create a groupid or shortname which is unique (but can also be null)
  • Create a csvfile structure for uploading csvs to create groups
  • Create a csvfile structure for uploading csvs to enrol users into groups


  • Aspects of the work:
1. A CSV file that contains the group name and the group members (a unique ID that also exists in Mahara, e.g. their email or their login 
if  they cannot change that -> still to be determined which one is the best). 
2. When the CSV file is imported, a controlled course membership group is created if it does not already exist and members are added. 
3. If the group already exists, its members are only updated -> new ones added, old ones removed. 
4. The CSV file also determines which members are admins, tutors and regular members. Maybe in order to do this we need 2 CSV files (still 
to  be determined). 
5. Groups that are not listed in the CSV file are not changed.


Group idnumber

The group idnumber will be a unique field that holds a shortname or groupid which is different from the already present id field (which is only for the database)

We could either have a nullable field in db, that we enforce uniqueness on or we could have a unique non-nullable field in db, and provide some unique default to store (which can be changed).

CSV to create groups

This file will need to have group name, group shortname, group desc, group type

CSV to enrol users into groups

This file will need to have group shortname, user studentid, member type

  • The studentid will be focused on to start with, then other ways of identifying the user

may be created, such as username or email

The member type will show either admin tutor or user

This would need to keep track of all the users in this file for each group, and remove extra users from groups listed in this file, but don't have that username.


Alternate CSV Format

Use one CSV, will have the following in it groupname, groupshort, groupdesc, grouptype, adminusers, endofadmins, tutorusers, endoftutors, normalusers testgroup,test,a test group showing csv strut,controlled,admin1,admin1,!,tutor1,tutor2,!,user1,user2

Here we have a list of all users, seperated into member types, between each type is a ! to delimit them This can be processed by a loop that runs til it gets a ! and changes user type

This allows for the functionality of removing users that aren't in the file, though it has the side effect of having group metadata and users all in one file.

I (Hugh) would suggest the first two formats, and have two seperate files for creation and population/updating