Related Sakai Requirements Links

Owned by Former user (Deleted)
Last updated: Feb 15, 2006Version comment
12 min read

As requested, I've gone through the current Sakai Requirements list and combed out the ones which seemed most relevant to this Working Group. I left out some advanced "site set-up" features which didn't relate to membership. It's still pretty long, I'm afraid. The Requirements review team will be working to provide a more organized view. When that happens, I'll update this page to match.

The first two requirements are ones I added to reflect the goals of the CM WG.

  • http://bugs.sakaiproject.org/jira/browse/REQ-323
    Ability to customize site ID

    Site ID should follow the format of term-department-number. For example, 1064-CHEM-101-01.
    Currently, site ID follows an unintuitive format to target audience. For example, 52be78bb-2fd4-482d-8071-19ea7a86b5cd.

  • http://bugs.sakaiproject.org/jira/browse/REQ-318
    Creation of Local Administrator role

    Provide administrative staff in individual departments (e.g., chemistry, engineering) and professional schools (e.g., law, medical, business) the ability to locally administer Sakai.

  • http://bugs.sakaiproject.org/jira/browse/REQ-302
    The 'Administrative Workspace' tools need to be consolidated and combined in some cases and include more cababilities in areas where it is lacking

    The 'Administrative Workspace' tools within Sakai need to be improved. In some cases, the tools should be consolidated, for example 'sites' and' worksite setup' have some duplicated functionality. As for needed and improved capabilities, log data should be made available within the administrative workspace. There is no easy way to get a count of the number of users who have logged into Sakai - to get this number, you have to page through all of the users and count them up by hand (this is silly!). There is no way to send a "broadcasted or emergency message" out to all users currently on the system (when for example you need to reboot the server). There is no way to schedule an event on every user's schedule (planned DOWN TIME for Sakai...). There is no logging that tracks the percentage of browsers used ( data is there because it is in the Online tool). The realms tool is very confusing.

  • http://bugs.sakaiproject.org/jira/browse/REQ-289
    Sakai should allow instructors to combine rosters of two or more sites

    Sakai will display combined rosters as separate sections in a site
    Students tab will indicate the course and section number of the site for which he or she signed up, not the site from which the instructor is delivering the combined content.

  • http://bugs.sakaiproject.org/jira/browse/REQ-247
    Need a way to delete dropboxes more easily when 'shoppers' drop a course

    Our students often 'shop' many courses at the beginning of the semester, leaving behind their DropBoxes when they do not sign up for a course. The mess left for the instructor to clean up is problematic.
    The instructor has to print a list of 'registered' students for the course, then go to DropBoxes and delete any non-registered students.

  • http://bugs.sakaiproject.org/jira/browse/REQ-242
    Deleting unused drop boxes

    If many students "shop" a class during an add-drop period, many drop boxes are created; but drop boxes are not automatically deleted when students drop the course. We need a simple way for faculty to delete dropboxes for participants who are no longer in the site participant list; or for participants of a certain role within a course (e.g., retain dropboxes for all "students" but delete all dropboxes for "auditor" or "shopper" or whatever role an institution might create)

  • http://bugs.sakaiproject.org/jira/browse/REQ-222
    Improved Admin tools (Sites and Realms)
    • improve performance; response time is often slow when the system contains a large numbers of sites
    • improve search capabilities
    • improve sorting/filtering capabilities
      The admin tools are often slow when the system contains large numbers of sites. It is hard to find a realm when only some part of the site name is known - site and realm tool each contain search functions that would be useful in the other or are missing useful search capabilities (search for a realm by knowing part of a site title for example, or search for sites a user has created). We need to be able to sort/filter by term in the admin in the admin tools as well.
  • http://bugs.sakaiproject.org/jira/browse/REQ-174
    Administrator tools should allow administrators to search for sites associated with a specific user

    Often our campus and department admins will receive a trouble ticket for a particular user, that has the course number, but not the section number for the course. At IU, a course number an be associated with many sections, so it would not be useful to know just the course number if searching by course. However, if the administrator were searching by username, the course number would be more relevant because most likely the user would only be associated with one course (in the situation of a student). The become user tool is useful to super administrators, but this tool cannot be given to campus and department admins due to the nature of the tool.

  • http://bugs.sakaiproject.org/jira/browse/REQ-123
    Support IMS Enterprise

    This likely will take the form of finishing the IMS Enterprise Provider as a first step. In addition, there may need to be a way to upload an IMS Enteirprise document, parse it and inject that information into Sakai.

  • http://bugs.sakaiproject.org/jira/browse/REQ-121
    Add Hierarchy Capability to the Framework

    This will add a generic hierarchy backbone within Sakai and allow sites, and other objects to be associated with theis hierarchy. The primary end-user visible aspect of this will be the ability to have sub-sites, or sites within sites. Over time, tools may begin to use the hierarchy capability to organize their own objects.
    (Ray's comment: Would it be possible to restate the requirement in terms of its end goal rather than in terms of its implementation? That is: "Add ability to have sub-sites, or sites within sites." I'm concerned that specifying a generic design before the specific functional requirements may interfere with clarifying and optimizing the most common use cases.)

  • http://bugs.sakaiproject.org/jira/browse/REQ-104
    Allow optional auto-create groups using class sections that may be in the site via a provider id

    Along with REQ-40 which adds group control to other tools, as an option it would be useful to allow auto creating groups from the roster for each class section that might be in a site via a provider id. For example, if a site contained 3 rosters because the provider id was
    2006,3,A,PSYCH,100,001,002,003
    it would be nice to automatically create a group 001, 002, 003 with the associated rosters, and have those groups change as the enrollment in the given section changes due to drops/adds etc. Instructors could still add students manually to such groups.

  • http://bugs.sakaiproject.org/jira/browse/REQ-99
    User can restrict profile information based on system role

    A student would like for all of his instructors to have access to his personal information (e.g., email address, phone number). However, he does not want other students to have access to this information, but he doesn't mind if they have access to his public information (e.g., name, major).
    Another restriction might be that as an instructor, I would like to share my info with students enrolled in my course, but not the student population as a whole.

  • http://bugs.sakaiproject.org/jira/browse/REQ-97
    Instructors should be able to disable a user's access to a site without removing the user from the site

    An instructor may wish to disable a student's access to a site for an indefinite period of time because the student has not been participating as expected. It is possible to remove a student from a site, however, for universities that receive a daily load of registered students, this functionality would not satisfy the need in this situation.
    Instructor can disable a user's access to a site without removing the user from the site
    Instructor can include a message to the user indicating why his access has been disabled
    Sakai can display a message to the user indicating why his access has been disabled
    Instructor can enable a user's access to a site

  • http://bugs.sakaiproject.org/jira/browse/REQ-86
    Course Section folders created automatically in dropbox

    When an instructor creates course sections in his course, the dropbox will create a folder hierarchy based on these sections. For example, if the instructor creates Lab 1 and Lab 2, the dropbox will reflect these sections:

    folder SMPL 001 001 W06 dropbox
    subfolder Lab 1
    subfolder Bob Jones
    subfolder Ann Smith
    subfolder Lab 2
    subfolder Joe Jackson
    subfolder Kate Klein

    This will allow TAs and instructors assigned to individual sections an easier and more organized method for accessing the students in their section

  • http://bugs.sakaiproject.org/jira/browse/REQ-83
    Admin Tool "lite" for a college division admins

    Some admin tasks that we currently handle university-wide could be offered/delegated to the college or school affiliates.
    Give these users "soft" versions of the Sites and Realms tools but limit access to sites over which they have dominion

  • http://bugs.sakaiproject.org/jira/browse/REQ-74
    Ad-Hoc Group Management

    Instructors need to be able to create ad-hoc groups and group spaces (group collaboration areas), and they need to be able to manage these within their course sites.

    Use Cases:

    • An instructor or TA creates an ad-hoc group of a subset of site users. Following creation group membership can be adjusted.
    • Each group has their own collaboration space which includes the usual collaboration tools.
    • Since students may typically spend more time in a group space than a course space, the group site should not require navigation through the course site.
    • An instructor has an option to import groups from another site (i.e. groups may span multiple sites)
    • An instructor or TA wants to send emails/messages/announcements to specific groups, and not have to remember an email address for each group.
    • Assignments and the gradebook should be "group-aware" to the extent that group projects may be submitted for grading, and feedback may be received on either an individual or group basis.

    I would like to add to this the ability to create groups automatically in more flexible ways: for example by randomly assigning students to groups.

  • http://bugs.sakaiproject.org/jira/browse/REQ-71
    prevent users from login

    for several reasons it can be usefull to prevent users from login, without having to delete them or to keep black lists outside Sakai. It can be though of as a soft delete, as it happens with resources.

  • http://bugs.sakaiproject.org/jira/browse/REQ-52
    Merge Course/Site Tool

    An admin and instructor tool that will merge courses or sites into a target course, however, this tool is for instructors not admins. It would allow instructors to merge one course into another to allow teaching of several sections of courses within one sakai course.

    The merge tool should do the following:

    • identify the course/site to be the target or repository of the course sections
    • identify or select the courses to be merged into the target course
    • merge the enrollments into the target course for all roles (stdts, instructors, GTAs, etc) and data updates will automatically take effect within the target course
    • this action (the merge) can be undone
    • still identify students which were enrolled in the pre-merge sites

    Use case:
    Instructor A is teaching 2 courses that meet on different days. He would like to post all course materials, tests, etc... on one worksite. He would like to also be able to send announcements to all students, or just students in the class that meets on the first day. At the end of the semester, he will split the site back into the 2 original sites and post final exam information. When the classes are split, the course materials and data should be duplicated in both classes.

  • http://bugs.sakaiproject.org/jira/browse/REQ-50
    Manage Users and Courses Tool

    A refinement of current admin tools, both UI and functionality. An admin tool that will list users and display courses or list courses and display users associated with course.

    a. ability to link user to all courses or link course to all users
    b. paging for all list views (currently a very long roster will break the html at Realms)
    c. showing X-of-Y for list pages (currently, when we do get paging we only get Previous and Next. No clue how many pages we're leafing through.
    d. a way to export any list in admin as .txt
    e. the tool list at Sites > Pages > Tools > New Tool as a dropdown menu.

  • http://bugs.sakaiproject.org/jira/browse/REQ-30
    Join Site by Requesting Membership

    Add the additional option for sites to be joinable only by request. In otherwords, a user could browse the list of joinable sites, but instead of being able to join immediately, they would click on a link that would provide them with a little form to fill out. That form would then generate an email to the site owner(s), who could click on a link in the email to accept or deny the join request, which in turn would generate an appropriate email back to the requestor.

  • http://bugs.sakaiproject.org/jira/browse/REQ-29
    Site Title Uniqueness

    There has always been a lot of support on both sides of the site name uniqueness issue, whether more than one site can have the same title. Currently sites are not forced to have a unique Title, and a user cannot tell which tab is which when sites have the same name.

    Most commonly course sites with the same name are an Instructor-related problem. It is easy to avoid such conflicts if your Sakai is using autogenerated site names, which include a date reference, such as GS 440 001 W05. If an Instructor is using a title without a temporarl reference, however, and they decide to duplicate a previous semester's site to use with a new crop of students, then they will see two tabs with the same name, even if their students don't because they are only given access to the one associated with the roster they are on.

    It can still occur with project sites too, where a temporarl naming convention is not generally enforced. For instance, you might have muptile lab groups that name their site "Lab Group" ; this becomes a problem when a user starts participating in more than one Lab Group site and they cannot tell which is which from the tab.

    How about offering this as a system-wide configuration option, since opinion is fairly strong both ways?

  • http://bugs.sakaiproject.org/jira/browse/REQ-15
    Comprehensive 'remove user' functionality

    When a user is deleted through the GUI (Users tool, 'Remove user'), not all artefacts and associations of the user are removed. For example, the user's my workspace site remains, as does realm membership or any sites of which the user was a member.

    In some cases, this behaviour is desirable (for example where a user was created internally but also exists through a provider), whereas in other cases it is undesirable, leaves behind orphaned data in the db and/or may have security implications (OOTB configurations and configurations where userids of internal users may not be unique across the lifespan of the application, e.g. guest accounts where the email address is the userid).
    A more comprehensive 'remove user' capability is required (whether invoked via the GUI, web services or API), which is flexible or configurable enough to cope with various deployment scenarios, i.e. ways in which the Sakai internal user db and external providers interact.

  • http://bugs.sakaiproject.org/jira/browse/REQ-14
    Sakai services should minimize dependencies and references to other services

    Sakai services should strive to model data management for a set of objects and minimize the use of other Sakai services in both the API and implementations. By clearly separating concerns, this will lead to Sakai services being more modular and easier to adapt services for enterprise integration. Since Sakai services are layered, no sakai service should ever reference a higher level service. Even references at the same level should be avoided unless absolutely necessary.

  • http://bugs.sakaiproject.org/jira/browse/REQ-8
    Need the ability to deny permissions

    A deny permission is needed in order to be able to control read/write access to subfolders. Without it, read access to a subfolder can't be prevented since you can't take away a permission granted at the parent folder, and in order to get to the subfolder, you need readd access at the parent. A deny capability would also be useful in conjunction with the !site.helper realm, to deny certain permissions to a role in all sites. See SAK-1609 for further details.