Re: User roles and UI

["Ilya A. Volynets-Evenbakh" <ilya@total-knowledge.com>]

OK. I finally got around to this :-)

Roles are not something user plays within whole application.
i.e. user is not just a "Student", or just a "Teacher". Instead
user is "Student of course A", "Author of course B", "Author of
topic C", "Teacher of course D", etc.

In order to become a student of object X (i.e. get "study" permission
in corresponding ACL table), user has to sign up for a course that contains
said object.

In order to become an author of object X user has to either create
the object, or be given "modify" access to the object by one of other
authors of said object.

In order to become "Translator" of object X user has to be granted
"translate" right by one of object authors.

How does one become teacher of an object isn't 100% clear to me.
I guess one of course authors has to grant this right.

See more comments below..

sergey@total-knowledge.com wrote:
> Another question is about "not logged in" users. Per docs they can't
> browse a Repository:
> http://www.total-knowledge.com/wiki/index.php/UU_Page_Flow#Not_Logged_in
> but can see "Lists of top-level course, through problems and text
> dialogues categories" on the home page:
> http://www.total-knowledge.com/wiki/index.php/UU_Page_Flow#Content_5
>
> What's the criteria for choosing "lists" that should be displayed for not
> logged in users on the Home page?
>   
Guests need to see things that they can sign up for.
> Why can't they browse/search a Repository? Maybe they should see partial
> non-editable versions of the UMOs there?
>   
I don't know (or don't remember) why we decided to make generic object
repository inaccessible to guests. Perhaps simply because average guest
does not need to see separate objects? OTOH, if person is coming to our
site in order to become a course author, access to repository as guest is
important. I guess I'll say, let's make it generally accessible, unless
someone
can remember why it was decided to do otherwise.
>> I forgot to add a Translator. He potentially can be Student/Author/Teacher
>> too and other way around.
>> Per "Database structure requirements" when new user tries to access an
>> UMO:
>> "If the required ACL entry doesn't exist it is created."
>> So what entry will be created? Can it be based on user's choice on
>> registration? If yes, should we have those values saved somewhere in DB or
>> they will be stored in UUServlet object?
>>     
I guess what I have said above should answer this question. If you need more
clarification, let me know.
>>> Also how do you become, for example, an Author or a Teacher if you are
>>> just a Student? Change your role on "My Account" page or something like
>>> that?
>>>
>>>       
>>>> It's not much about this in the specs and I'd like to hear your opinion
>>>> on
>>>> how different kinds of users will change their roles in UI.
>>>> Let's say during a registration user chooses his role from the
>>>> dropdown:
>>>> 1. Student
>>>> 2. Author
>>>> 3. Teacher.
>>>>
>>>> Top and left navigation bars will look exactly the same for all kind of
>>>> users. If Student, for example, clicks on "Create New Course" link, he
>>>> will get user-friendly version of "Permission denied" message.
>>>>         
Of course not. See above.
>>>> 1. Let's say an Author wants to check how his Course looks in Student's
>>>> eyes. I guess he should either change his role to Student or have an
>>>> access to his own Course as a Student. It has to be done within one
>>>> session.
>>>>         
Authors shall have "student view" of their objects, but "passing" their
objects
will not be reflected on their overall scores (whatever those will be)
>>>> 2. Let's say Bill, an Author of Course "A", is a Student for Course "B"
>>>> and Teacher for Course "C". He should be able to enter each Course with
>>>> appropriate role within one session.
>>>>
>>>> 3. Let's say Bill browses Repository. As an Author he should see
>>>> editable
>>>> versions of UMOs and be able to add them to his Course. As a Student
>>>> and
>>>> Teacher, he should see "view only" versions of UMO.
>>>>         
Not quite. Nowhere in the spec it says that author can edit all objects.

-- 
Ilya A. Volynets-Evenbakh
Total Knowledge. CTO
http://www.total-knowledge.com