Visibility
Context
Sunbird currently allows assets to have the following visibility attributes:
Public
Private
Parent
Definition of these visibility as per the current implementation:
Asset Visibility | Creation Experience | Consumption Experience |
Public - visible to everyone | Public assets are visible to all the creators across organizations for re-use. | Public assets are visible to all users. |
Private - restricted visibility | Private assets created within an organization are visible only to the creators within the same organization. | Private assets are not visible to any users. |
Parent - visible only in the context of the parent | Assets with Parent visibility are not visible to any creators. | Assets with Parent visibility can be consumed only in the context of the parent hence not visible as individual assets. |
Sunbird also allows for interlinking of assets with different visibility properties. For example, a collection with ‘private’ visibility can have content with different visibility properties - private or public or parent or a combination of all of them. In the current implementation, the specific behaviour for these combinations isn’t defined and hence these combinations are not currently supported by Sunbird Knowlg & inQuiry building blocks. This restricts the usage of this capability for a variety of use cases powered either by SunbirdEd consumption apps or other consumption apps.
Behaviour
The below table calls out what should be the ideal behaviour for the various possible combinations.
Parent’s visibility property - Collection/Question Set Asset | Child’s visibility property - Collection/Question Set/Individual Content/Question/Media Asset linked to the Parent collection/question set | Behavior |
Public | Public | Valid. For ex, if the parent is a collection and the child is a content then the parent collection is accessible through Search, Read of Collection APIs. Individual Content is accessible through hierarchy read of Collection, Search, Read of Content APIs. |
Public | Private | Invalid. |
Public | Parent | Valid. For ex., if the parent is a question set and the child is a question then the parent question set is accessible through Search, Read of question set API. . Individual question is accessible through hierarchy read of question set. |
Private | Public | Valid. For ex., if the parent collection is private and the child content is public then the parent Collection is Accessible through Private Search/Read of Collection Individual Content is accessible through hierarchy read of collection, Search, Read of Content |
Private | Private | Valid. Collection Accessible through Private Search/Read of Collection Individual Content is accessible through hierarchy read, Private Search, Read of Content |
Private | Parent | Valid. Collection Accessible through Private Search/Read of Collection Individual Content is accessible through hierarchy read. |
Parent | Public | Valid. Collection creation can happen only with reference to a parent collection under which this will be present. Collection Accessible through hierarchy read. Individual Content is accessible through hierarchy read, Search/Read of content |
Parent | Private | InValid. (Here we do not know what is the visibility of the Parent Collection) |
Parent | Parent | Valid. Collection creation can happen only with reference to a parent collection under which this will be present. Collection Accessible through hierarchy read. Individual Content is accessible through hierarchy read. |
Public | Public + Private + Parent | Invalid |
Public | Public + Parent | Valid. |
Public | Private + Parent Or Private + Public | Invalid. |
Private | Public + Private + Parent | Valid |
Private | Public + Private/Public + Parent/Private + Parent | Valid |
Parent | Public + Private + Parent/ Private + Public / Private + Parent | Invalid (Again we do not know the visibility of the parent collection) |
Parent | Public + Parent | Valid |
Note:
The thumb rule is that ‘Private’ children will be allowed to be linked to ‘Private’ parents. For ex., a collection with visibility attribute as Private can have private content but a collection with visibility of either ‘Public or Parent’ cannot have private content linked to the collection.
For ease of implementation, we have considered nesting at two node levels - parent & child.
Scenarios:
Following are some sample scenarios explaining how adopters can potentially use this capability:
Scenario 1:
Adopter wants to use inquiry capability to roll out exam papers. These ‘exam papers’ should not be visible for consumption but should be visible for other creators within the same org. These ‘exam papers’ can have questions from previous exams/public question banks and new questions. The new questions created for this exam paper should be private. After the exams are over, creators will make the exam paper public - the expectation is that the exam paper and the questions within the exam paper should be available for public consumption.
Scenario 2:
Adopter wants to use knowlg capability to roll out special training courses. These ‘special training courses’ should not be visible for consumption but should be visible for other creators within the same org. These ‘training courses’ can have content from previous training courses/public courses and new content. The new content created for this special training course should be private. After some time, creators will make the training course public - the expectation is that the exam paper and the content within the training should be available for public consumption.
Scenario 3:
Adopter wants to create question banks. These question banks should be visible for everyone but the questions have to be consumed only from the question set and cannot be independently consumed. When creating the question banks creators should be able to search and add other public question sets and questions as well.
Note: Here the adopter can be using either the SunbirdEd consumption or their own apps for consumption.
Technical Design: