Re: [Phpgroupware-developers] RFC Head Features - Elearning

[Dave Hall]

Alex Borges <address@hidden> wrote:

> Okay..... here at the group weve been thinking about how to do the
> elearning trick with phpgroupware.
> 
> Whats been the development so far:
> 
> 
> a) We needed a stronger contacts backend, that supported contact <->
> account hard one-one links, so that we can make very comprehensive
> management facilities (you can now potentially browse and control your
> users through contact categories, organizations...etc.).
> 
> b) We need stuff that is not in other (generally proprietary) 
> elearningsystems because, in general, they suck and dislike 
> actually doing
> anything usefull for the alumnii.
> 
> We are thinking about this:
> 
> We want administrators to be able to group data from any application
> into generic categories. Hell, we want that at the api level. This 
> wouldpermit stuff like a general tree based administration facility 
> that just
> permits you to generate global categories and generally import/export
> data from most apps. 

I like the idea of global cat trees.  probiz's folders app, is good for
visualising this.  Maybe they can provide some screenshots, and we can
import it.

I think some semi global cats would be a good thing - for example have a
cat which is global in some apps but not others, for example projects,
todo and timetrack for project related cats.  Then by using the folders
app you could see it all at once.  This could even be implemented at the
user level too.  An admin option for controlling/modifying the use of
such cats would be a good thing too.

> 
> For that matter weve call this categories, in the tradition of the 
> greatzen masters (ealds idea), tracendental categories (OOOM).

I want a tree hug'n hippy app with a tofu theme ;)

> 
> The point is this. If we have tracendental categories and we can have
> acl's for them (we can choose the users/groups that can see them in
> their apps), and we can choose in which applications where the TC will
> show, we can have a generic templating system for easy building of
> collaboration scenarios. In our particular case, the environment is
> elearning.
> 
> To complete this system, this tracendental categories should have a
> match 1-1 relationship with hard groups, so that we can also map the
> group's acl to the category (if user is in group A, then he can access
> trac. category A as per category acl, but the DATA inside category 
> A, is
> accesible and OWNED by group A)

Ownership by groups could get a little messy.  I think this could be
possible using the existing user based ownerships, with better acl
checking/flexibility.

> 
> For example, administrator creates Tcategory Courses, and Tsubcategory
> CS-I, he then chooses all the contactaccess' that tc. In that 
> second, all alumni in group CS-I can see in all
> their apps they have access to a Category Curses/CS-I. If they go into
> contacts, they can choose it and the kids and teachers of CS-I will
> appear in their addressbook. Same goes for calendar or infolog.
> 
> Now, teacher wants to give homework, he enters a nice wizard, he says,
> kids in CS-I should read this pdf, and they need to deliver an 
> essay the
> 12 of october. In that split second, Tsubcategory CS-I/Homeworks is
> created, kids can see the pdf (in the end, category smart) under the
> CS-I category, they can go into their calendar and under the
> CS-I/Homeworks Tsubcat they will see the date when their hw is due. 
> Butthis new Tsubcategory will have no entry in contacts.
> 
> This is an elearning scenario, but im shure you guys can think about
> your own stuff and your own scenarios.
> 
> Okay, here is another feature. Kid has to do homework for CS-I, but 
> itsa teamwork assignment (in some schools, team solving is forcefull
> -alas...im a little geek and i went to one of those...sigh).

Group assignments are evil.  One person does SFA and gets the same mark
as the one who worked their butt off.  Anyway, we can't solve all of the
worlds problems - this week. ;)

> So, they
> want to invite some friends to solve the homework with him. They get
> together in the classroom and designate him (typical, the geek gets 
> allthe work) 'Hey bro, you make the team in gw and set the date for 
> Oct 11'
> (late night programming homework).
> 
> So, in the geek (or anyone, it does not REQUIRE a geek) goes in, 
> clickson 'new team for CS-I/Homeworks' A contacts ui (the js 
> addressbookperhaps) pops up, he chooses his buddies, clikcs on done 
> and that
> operation generates an entry in the accounts table, type 'T' (Team, 
> thisis mostly skwashd idea, nag him), who owns and has access to a new
> Tsubcategory, called CS-I/Homeworks/Name of team and it ONLY 
> appears for
> the team memebers 

The Teams concept is a good one IMHO.  I think in phpgw we have some
issues with ACL group management.  For example, app access is group
based, as is data acess.  I think we need to seperate them.  

Team are people who work together, Groups are people who are forced to
be together imho.  So we have groups for app access, these are
controlled by the sysadmin.  Teams are more flexiable and can be
optionally created and managed by users.  We already have the Group
Manager ACL option, we could implement a Team Leader using the same ACL
rights level.

This was we can have true seperation of app and data access.

This leads on to my next part of the concept.  News admin has a nice ACL
management screen.  IMHO this should be moved to the api, and made a
simple uicomponent, so we stop reinventing the wheel.  The ACL on cats
can even be done by the API class.  For users accessing this screen,
they would only see teams and the members of those teams that they are a
member of, while the sysadmin would have access to it all.

I would also suggest that we make all apps support n:n category
relationships, using a central cats table.  Something simple like,
cat_id, app, location, app_id, with all 4 fields being part of a
compound key.  Thus making the functionality availble for all apps.

The category management by a sysadmin would also be useful.  So they can
bulk change data from one cat to another.  Add/Remove/Edit categories,
with referential integrity being maintained.  Only the sysadmin would
have the rights to delete a category, while users could 'disable' a
category, and transfer the record to another category.  The sysadmin
would only be able to delete a category when there are no records linked
to it.  If we don't have a central table for this, then we would need a
checking hook in each app, which gets messy.

>(Facilities for rejecting the joining of a team 
> shouldbe provided as well), the user can now click on new 
> assignment which is
> a wizard that sets a calendar entry with a possible infologentry (for
> attaching files), select his team, name of homework, files to 
> associate,and clicks on Done, immediatly, calendar will send emails 
> to his team,
> all team members will have the corresponding calendar entry, under the
> category CS-I/Homeworks/Team I.
> 
> Optionally, the teacher can allways be a part of any team, so he could
> check the progress of EVERYTHING (Big Brother Mode).
> 
> So, to sum it up. New features:
> 
> 1.- Tracendental categories

Yep

> 2.- ACL's that can separate which categories are viewable by whom

Yep with in as a feature of the cats class, reducing repeatative code.

> 3.- TC <-> Group link that can ansure us that we can use the group acl
> to control access in the TC data.

I think groups should just become app access controls.  I know this will
confuse some people, but it will make it simpler for overall management.

> 4.- Teams, which, plus 4 , ensures us user teaming capabilities.
> 
> We want to develop this elearning suite as a phpgroupware GPL
> application and we would like to involve whomever is interested in it.
> Please comment, throw ideas arroung, laugh...whatever...
> 

... and have fun while doing it :)

/me feels a wiki/forum discussion starting :)

Cheers

Dave

dave.hall.vcf
Description: Card for <dave.hall@mbox.com.au>