Roadmap Dokeos 1.8/community 2.0

From Dokeos

(Redirected from Roadmap Dokeos 1.7/1.8)
Jump to: navigation, search

Contents

What is Dokeos community release 2.0?

The Dokeos community releases are not officially supported by the Dokeos company (though they do believe this release is a good idea). The Dokeos company involvement in community releases can be likened to the involvement of Red Hat in the Fedora project.

This community release and the next Dokeos company release share the same roadmap. Dokeos community release 2.0 is released first, and contains several but not all features of this roadmap (only those we think are stable enough to release). The next official release should contain all features of this roadmap, though of course the roadmap may change over time.

For more info on the how and why, please see these meeting minutes.

Note: Dokeos community release 2.0 was developed under another name: Dokeos 1.7. There may still be references to this older name.

Timing

Further planned releases

  • June-July 2006 - Dokeos community release 2.1
  • October 2006 - Dokeos company 1.8

Shared Roadmap

This is the roadmap for Dokeos community release 2.0 and the next official release. Several of these items will already be present in Dokeos community release 2.0. For a short overview, you can also see the Dokeos community 2.0 release notes.

Admin section

  • A graphical way to change the password of users (also the admin), taking the optional encryption into account.
  • The ability to specify the authentication source of new users (added individually or through csv or xml files).
  • confirmation message after subscribing a class to a course

developer(s): Bart

  • Dokeos Config Settings: easy adding of plugins
  • Dokoes Config Settings: easy adding of new course tools

developer(s): Pcool

Breadcrumbs

  • On the 'my courses' page the breadcrumb reads platform > my courses. Both links link to the same page. Inside the course the breadcrumb reads platform > current course. This is an inconsistency because the my courses link has disappeared. More on this: http://www.dokeos.com/forum/viewtopic.php?t=4516
This is now fixed in the CVS: http://www.dokeos.com/forum/viewtopic.php?t=5380 --turboke 14:14, 5 Dec 2005 (CET)
  • AWAC setting for the link to the course homepage in the breadcrumbs: 'this course', course code or course title (shortened to x characters.
can the last item (currently displayed page)in the breadcrumbs NOT be a clickable link?--Wolfgang 12:31, 1 Sep 2005 (CEST)
I'd prefer a clickable link, that does NOT repeat the last/current action. So a link without any ? parameters. Currentky the link always repeats the last action, which is annoying and quite dangerous. Roan
I'd suggest changing the term "current course" for the breadcrumb link to "course homepage" or something that would reflect to where the link is leading. The link is not leading to "current course" because in all tools we are already in the "current course".--Wolfgang 12:31, 1 Sep 2005 (CEST)
done.

Developer(s): Patrick will have a look at it

Status:

  • the "Current course" is changed to "Course Home" in the DLTT -- Roan 10:15, 29 Sep 2005 (CEST)

Campus homepage

The current index.php file does too much. We will create a separate page for showing the "open" courses, and when a user logs in, they should also get taken to another page. bEvaluate proposal to separate out the current functionality of the index.php Campus Homepage into two separate files:

  • The current homepage before login (as is) with possibilities to configure and edit homepage content to display general campus information, etc.
  • After user login, the "personal" page with similar functionality as is now (all the different "my ..." items (my courses, my agenda, my profile, etc).
Instead of this being handled by one and the same file (index.php in root folder), the after login functionality should be in a separate file.
the current initial development is now available in CVS --Wolfgang 06:15, 27 Oct 2005 (CEST)
  • If the campus has open courses in various categories, there should be a link on the current homepage to a separate file, like an "open courses overview", from where users can access these open courses
  • note on course homepage=language driven

developer(s): various working on it, e.g. turboke, wolfgang, note:Wolfgang could not be present but gave his ideas for this through mail, wiki, forum.

Course creation

  • complete refactoring of create_course/add_course.php because
    • make the 2 "create course" pages (1 for teachers via current right menu after login, the other via platform admin section) to be consistent => only difference really is that in one the teacher name is taken automatically from the login, in the other the teacher name is entered in a field--Wolfgang 09:16, 30 Aug 2005 (CEST)
    • it states that 'All fields required' but in fact none is really required (there is no check if the fields are really filled)
    • use AWACS to determine which fields are really required (see also the already existing AWAC: 'Display Course Code in Course Title') and indicate it using the red asterisk (as in user registration)
    • Coursecode when creating a course: when this is not entered the default CL code is used. Maybe it is better to change this to the x characters of the title (stripping out special characters and spaces). This can easily be accomplished by adding the following code on line 146 of create_course/add_course.php (after line 145 $wantedCode = trim(strip_tags($_POST['wantedCode']));) 
if (empty($wantedCode))
{	 
    // we use substr because the code field can only contain 20 characters (in the db 40 however)	 
    $wantedCode=substr(trim(strip_tags($_POST['title'])),0,20);	 
}
    • the algorithm to create a unique code is not so good. The input is a string(20) and in the database it is a string(40). If the code is already in the db it adds some extra characters. If however (using the situation above) we use the title to create a course and obtain a string (40) than this can no longer work and we would have to do it the other way around: take the last character of the code string(40) and shuffle this one untill we have one that is unique (proposal by tberton)
  • AWAC that switches on or off the default documents, default tests, ... This is a choice between a course that contains already some example material or a completely empty course.
  • AWACs to set the default course settings.

developer(s): Patrick will do some of these

Course settings

  • Showing/hiding of tools should be possible from here (see item on navigation menu).
This can be done through the roles-rights overview page for the course, but the easy eye-icon way of doing this is not in the course settings yet.

developer(s): Bart (first 2 items), Roan (setting course tool visibility)

Database abstraction layer and API

  • We will gradually move to use PEAR:DB.
  • Removing of all backticks in queries, since this is very MySQL-specific (they can't be simply searched & replaced because they can occur outside queries as well)
  • Currently there are hundreds of queries inside the code. Many of these are actually more or less the same queries with a few different parameters. We can refactor these hundreds to dozens of query functions with parameter options.
  • Some other interesting PEAR-packages:
    • DB_DataObject: An SQL Builder, Object Interface to Database Tables

developer(s): Yannick will start the development, others will help; turboke is taking care of the backticks

Documents

  • Display the folder structure in the dropdown-list to select a folder and not the whole path

developer(s): sorting: Bart, dropdownlist: Bart (done), no zipping for guest: Ghent univ. (perhaps with roles?), thumbnails: show comments in slideshow: Patrick, direct link: Patrick

Dropbox

  • user sortable table consistent with the other tools
  • folders

developer(s): René

See e.g. forum topics 5146 (prototype), 4668 and 2831 (supporting requests for improvement).

Requirements, Design ideas, ...

  • 'folder' could be an additional field in table dropbox_person; this table tells to which user(s) a dropbox item is (still) visible (many to many); then students and teachers can set up their own (private) set of folders (cfr. e-mail);
  • does this need to be a folder hierarchy or is one level enough? does anyone have a need for storing dropbox files in multiple folders simultaneously?

-> I would say one level is enough but there will certainly be users who will want this. Dropbox file in one folder only, not simultaneously in two (or more) folders (just like in the documents tool) Pcool

Exercises

developer(s): Dokeos company


File structure

  • main folder, which holds the main Dokeos code
  • plugin folder moved from inside main code folder to be in the top level, this will help separation between dokeos standard code and plugins - take care because HtmlArea is in the current plugins folder, so we will do this and the move to FckEditor at the same time.
  • documentation folder in top level, that holds installation guides, readmes,... in various languages
  • data folder in top level (same level as courses directory), this folder stores e.g. all the images the users upload as user pictures
  • Move the garbage folder to inside the new data folder because it does not belong in the code folders.

developer(s): Roan (folder structure), Bart or Olivier (move to FckEditor), ...

  • Status:
    • documentation folder is created, filled with translations of the installation guide, and an index.html that links to all of them. The documentation folder is also included in the stable 1.6.x branch. Currently, there are only English, French, and German translations. Roan
    • plugin folder is created (kses and fckeditor included), old plugin folder still exists (Bmollet 13:19, 7 Sep 2005 (CEST))
should the kses and fckeditor files be included in the plugin folder. I do not think so because the PEAR files then also should appear there. The plugin folder should only be used for the Dokeos Plugins (from the extensions page) = scripts that can be removed and are optional (Pcool 14:11, 8 Sep 2005 (CEST))
I see the problem with people thinking something is optional and removing it. Though perhaps that will not actually happen often. It is still a good idea to separate all external code (kses, fckeditor, pear:db...) from our own. Ideally of course, fckeditor is optional and can be replaced by other wysiwyg html editors. Roan

Forums

  • An hidden forum can be used by teachers / tutors for the course monitoring. So hidden really means hidden to students and guests. -> UGent has code for this: make forum or threads hidden.
  • make forums and forum categories sortable
  • use dokeos id in the forum and use this to retrieve the email (instead of first/last name combination-> there might be users with the same first/lastname combination as UGent and VUB experienced).
  • a third view, nested, which is a combination of flat and threaded
  • an option in the teacher or admin config settings to set the default view type, currently this is always flat.
  • management of fora and forum categories identical to the links tool.
  • remove the language files inside phpbb/languages and move the variables to the phpbb.inc.php file
  • make topic administration available (move - delete - merge)
  • link in the notification message to the correct thread.
  • allow forumusers to add attachments (note: already possible, I added to the resourcelinker section: allow adding of student publications).
  • optional: allow people to upload documents from their computers (add it through resource linker, so all tools get it)

developer(s): Patrick, perhaps others from Ghent University


Groups

  • A tool to create groups in your course matching the several classes subscribed to your course

developer(s): Bart

status: First implementation available in CVS. See forum

Help

  • The help should be improved and should be contextual. The help should be much more extensive than is the case now and should provide "good practices" and examples of use.
  • Discussion remains... Where do we best make translations for the help system? We will try to use the wiki for this. And perhaps afterwards either link from Dokeos to the wiki or generate html pages. For the moment we will keep the current system.
  • Each form could also have a small help icon that explains what is expected to go into the form. This could for instance explain if you can or cannot add HTML into the form. example. We should make this an API function.
  • tooltips for the action links (add document)

developer(s): tooltips: all; the rest: ???

Icons

  • delete more unused icons (some already deleted by Bart)
  • make all icons transparant
  • gif / png. IE has problems however with transparant png files, so for now we choose gif as standard, which is legally OK since the gif patent has expired.
  • api (Display lib) function for displaying the icons on the course homepage as this would allow matching the icons with the stylesheet. The different stylesheets are in a subfolder of the css folder (example: css/silverbullet). The api function for the icons would then check if there is a folder inside the img folder called silverbullet and then look for the requested icon. If it is not found (folder or file) then the normal icon is used. This would allow us to match the stylesheets and the iconpacks of the extensions section.

developer(s): Delete unused images: Dietrich Van Damme See forum, API function: Patrick

Installation and upgrade

  • Code improvements for easier maintainability/support
  • Ability to upgrade from 1.6.x to 1.7.0
  • Sql file for the main tables, used during install, also useful for a future manual install script
  • Ability to upgrade from 1.6 to 1.8, 1.7 to 1.8, 1.5 to 1.7/1.8...
  • Sql files for the other tables (scorm, statistics, user)
  • More error checking with messages to the user
  • Checking if the folders have the right permissions for reading / writing http://www.dokeos.com/forum/viewtopic.php?t=3758

Important remarks

  • Dokeos 1.6.1 introduces some database changes so we have to take into account people upgrading from both 1.6.0 and 1.6.1.
    • The esperanto language has been added
    • Fix for converting the old course homepage links to using the links tool
    • (works, can be improved) Fix for sorting the personal courses
  • Changes in Dokeos 1.7:
    • dokeos_main.sys_announcement : visibility fields changed from enum('true','false') to enum('0','1')
    • several new roles tables (basic_right, role, location, role_right_location, user_role)
    • default auth_source renamed from 'claroline' to 'platform'. Use the PLATFORM_AUTH_SOURCE constant defined in main_api.lib.php
    • new role-right course module: record mus be addd to the tool table of every course
    • new role-right course module: record must be added to dokeos_main.course_module

The install and upgrade code is being reworked (see forum topic) for several goals:

  • (busy) separation of code and data - most data should come from external data files
  • (busy) more robustness, less cause for errors
  • possibility of an upgrade script that can upgrade from multiple versions, e.g. people should be able to upgrade from 1.5.x to 1.7, and from 1.6.x to 1.7.
  • better installation for users who are only allowed one database that might also contain tables for other software that should not get deleted
  • the language used during installation can now be selected
  • installation of the main tables and data now happens with a .sql file, this one can also be used with a shell script to install (the shell script is not written yet). We experimented with filling data in tables using .csv fles and the MySQL LOAD DATA statement, but this proved not to be a good idea because of various permissions / safe mode issues.

Developer(s): Roan Embrechts, Bart Mollet

Status:

We have first complete versions of the install and upgrade. For the rest of 1.7 development it'll be mostly bugfixing.

Navigation menu

We've added a menu for navigating between course tools. There is be an on/off switch, and this feature is on by default. We will add on the course settings page the ability for course admins to show / hide icons. If someone develops it, we can also have a switch to choose the place of the navigation menu (left, rigth, top, bottom...).

  • code to display navigation menu, by default to the right side
  • navigation menu yes/no switch to admin config settings, activated by default
  • navigation menu show icons switch in admin config settings, not activated by default
  • code duplication: tool shortcuts == navigation menu at the top with icons, this means we can save code
  • optional button to reduce its size
  • perhaps: more config settings dealing with the position of the menu (left - right - top - bottom)
  • show text and icons, only icons, or only text (like browser buttons options) instead of just show icons yes/no


Developer(s): several developers (Bart, Patrick, Roan, Sandra, Wolfgang)

Status: basic implementation is in cvs, for further implementation see forum topics "Navigation menu" and Left menu.. the sequel.

Personal course management

  • we will remove all but two options from the list, the main view will by default show the courses + sort and unsubscribe features
  • replace the unsubscribe from courses link by an icon = consistency increase + less clicks required
  • make the sort my courses the default view (currently you only see an empty page with the 4 links)
... why make the one of 4 options a default view? why not one of the others?
I would suggest to consider a restructure of this page as part of the ideas of homepage/index.php redesign (see above). Also, why make one option into an icon and leave the others as text? this idea does not make sense to me --Wolfgang 07:43, 16 Aug 2005 (CEST)
Wolfgang, I believe all options are displayed as icons now. --turboke 18:40, 6 April 2006 (CEST)
  • In dokeos 1.6 it is already possible to do course sorting using user defined course categories. This needs some more options:
    • sorting of the categories: as it is now the user defined course categories cannot be sorted (moved up and down)(code ready UGent)
    • show the already existing course categories (in the create course category section)(code ready UGent)
    • AWACS: show all user created course categories on the my courses page (even those that are empty)
    • no two categories with the same name
    • delete a user defined course category (code ready UGent)
    • show the categories that do not contain any course also otherwise there is no easy method to remove them (code ready UGent)

Note: see http://www.dokeos.com/forum/viewtopic.php?t=4859 for the code

Developer(s): Patrick

Print option

developer(s): Jeroen Coupe

Profile

  • OK - language selection in the profile => language dropdown can disappear once the user is logged in
  • As an extension, not in standard Dokeos, we will provide a css style selector
  • Allow profile to be seen by others -> everything should also be visible through the 'User' tool (and also searchable)
  • Allow the student to select what can be viewed by others (simple checkbox in front of the label now, perhaps portfolio based on LCMS features later)
  • In the future, we will rename My profile to My portfolio, when there is enough in there to actually speak of one.

Refactoring and cleaning

  • All code should work without the fake register globals code. This process is almost complete, but there are still a few places where it isn't (some parts of the learning path for example).
  • rename claro_init_banner to banner.inc.php, claro_main_conf.inc.php to main_conf.inc.php...
  • change the code so in arrays representing a course, a user,... the same keys are used as the corresponding field names in the database. For example, now sometimes $course['path'], $course['directory'], $course['dir'] are used. It should always be $course['directory'].
  • replace occurrences of $_course['dbNameGlu']."table_name" with Database::get_course_table(TABLE_NAME_CONSTANT)
  • replace occurrences of $mainDbName."table_name" with Database::get_main_table(MAIN_TABLE_CONSTANT)
  • replace occurrences of $siteName with get_setting('siteName'). Same for $Institution, $InstitutionURL, $emailAdministrator, $administratorSurname, $administratorName
    • status: It looks like this is OK (Bmollet 15:13, 21 Nov 2005 (CET))
  • delete all occurrences of bgcolor="#XXXXXX" in the code (and replace them by a good css alternative)
  • replace include(....claro_init_header.inc.php) with Display::display_header($tool_name)
  • use $_clean array that contains the forms. This array would only contain 'cleaned' content (according to the cleaning rules of the form itself): kses cleaned, mysql_real_escape_string, ... This array would then be the only one that could be used in all sql statements. (see also Security)
  • become PHP5 compliant for 1.7 (low priority but still a good thing). UGent is already running http://zephyr.UGent.be on PHP5. Only minor problems so far.
  • change the field 'auth_source' of the main user table to contain 'platform' by default
  • clean the claro_main.conf.php file so that the settings that are stored in the db do no longer occur in the claro_main.conf.php file. This can cause unneeded confusion since editing the claro_main.conf.php will not have any effect (it is now done through the Dokeos config setting).
  • css cleanup
    • refactoring existing styles
    • only one css (=merging htmlarea.css and the various other styles inside the tools)
    • removing every hardcoded styling <font size=... color=... and alike
  • Uniform form handling: take the input of the forms, check if all required fields are filled, do the cleaning (XSS), return them in a $_clean array (see HTML_Quickform)
  • use of the api functions throughout Dokeos. Several tools have not the correct API calls yet (Thinking of is_allowed_to_edit(), get_lang(), ...)
  • use of the phpmailer class throughout Dokeos


developer(s): All developers should help with this.

Registration

  • Registration as course manager only after approval of platform admin. (can this be extended to have the option to have all registrations needing approval by the admin?)

developer(s): Patrick


Resource linker

  • major code rewrite ?
  • use tool constants
  • add student publications
  • allow uploading new documents => goes into the user space

developer(s): Patrick


SCORM

  • Import: (upload) multiple SCORM packages in one operation.
  • Export: also export the metadata of the learnpath items. It is just copy/paste of an already-XML-formatted string into the imsmanifest.xml (DONE in 1.6 for Documents).
  • modify an uploaded scorm package (forum)
  • test results as prerequisites (forum)
  • score weighing missing (forum)
  • Dokeos learnpath: Allow creating learning paths in directories (forum)

developer(s): Dokeos company


Search tool

There are currently no less than four search tools in development or ready as plugin for Dokeos, all by Dokeos core developers. We must coordinate our efforts to provide a good search tool.

  • necessary: search in all courses / documents that a person has access to, search metadata
  • optional (we integrate this if we have time) search in office documents, text of html documents...

developer(s): Hogeschool Gent, Dokeos company, Patrick, Ren�


Security

  • We will do more efforts for security. We'll start using HtmlQuickForms (a pear package) and KSES (als free software).
    • A notice if the form is required (like in the registration page). Currently this is pure html code but a simple api function would do the trick. Maybe this could also be used in the api functions that deal with the checking if the required fields are really not simple (thinking of an array that contains all the required fields, the api that displays the label for the fields also displays the asterisk when the label is for a required field)
    • no XSS
    • no SQL injections
    • validating user input: a library to validate user input (Is given value in correct range? Does the given date exist? ...)
    • no register globals
  • New API class to deal with forms and filtering
    • Currently the user input is not filtered. The bottomline is that the input from the student accounts gets filtered so that no javascripts can be used. We discussed already that we will allow javascript inside html documents in the document tool. Elsewhere it should be impossible to
    • If we take this to the extreme then we only allow flat text to be entered by the students. We can give more possibilities to the teachers though.

(todo: put Patrick's presentation online) developer(s): Bart and Patrick will create the initial design and a short how-to guide for the other developers, after that everyone wil contribute. status: QuickForm is available in CVS. Use Form Creation And Validation as a reference to change existing code.

Sortable Table

  • The current sortable table function (display_sortable_table, in inc/lib/display.lib.php) accepts an array of the items that have to be displayed and the sorting itself is done by sorting this array. This gives performance problems with large lists. It is better to let the mysql database do this sorting and pagination by using a limit and order by as part of the sql statement.
(René: Dropbox accesses the DB via PHP classes. With this philosophy, it can only pass an array. Fortunately Dropbox lists are seldom large. Proposal is for display_sortable_table to also keep the array-based functionality.)
  • The current default value shows 10 items in a sortable table. This is a bit too small. An AWACS would be nice.
  • there is a link 'show all'. Maybe it is a good idea to have a dropdown menu where one can choice how much items have to be shown on the page: 10, 25, 50(the 1.5 default), All
  • you cannot see how much items (users) there are in the complete list. Maybe it would be nice to display something like: showing x to y of z items

Developer(s): Bart

Status: finished. More info about how to use it.

Student Publications

  • Download all items in one zip file
  • The ability to create 'folders'

developer(s): Ghent university


User roles and rights

  • design based on this presentation (pdf), see also User roles and rights, User Permissions
  • clearly defined set of default local roles (used inside courses)
  • support for view, edit, add and delete rights in most course tools
  • basic locations support, using a localised / hierarchical system
  • mapping of old user interface options to new system
  • global roles
  • ability to define new roles and their rights
  • restrict course admin ability to grant rights to others, restrict it to only the rights they possess

Developer(s): Frederik, Evie

Note: The design+implemnation will be further written out and discussed, especially the user interface still needs a lot of care.

Status: A first basic implementation is available in Dokeos community 2.1 - see the forum [1], [2], [3]

Users

  • (for platform admins) ability to lock a user: http://www.dokeos.com/forum/viewtopic.php?p=16863#16863
  • (for platform admins) timewindow on a user: a start and end date in course_user. This is a sort of a view option with a time restriction. What should be decided is if these temporary user are visible in the users tool or not. The user table could also have such a start and end date (default enddate=startdate + 1 year)
  • Ability to search in the user tool.
  • alfabetic filtering in the users tool (dropdown list A->Z, dropdown list first name & last name)
  • registration to a course: access allowed after approval of course manager
  • vcard export
  • Make the user Image clickable so that a popup with the full sized image appears
  • (default off, as config setting) 'Subscribe users to this course' to allow what was possible in previous versions (add new accounts) http://www.dokeos.com/forum/viewtopic.php?p=19370#19370
  • The ability to search when subscribing a user to your course.

Developer(s): Ghent university: all items, except Roan: last item

Status: one item ready

===User info (detail page)===
User Detail
User Detail
  • bring the user statistics to the user detail page
  • add overview of all forum posts. Students are sometimes quoted on their forum posts also.
  • Teacher comment: allow the teacher to add personal comments on a student (only visible for the teacher, not for the student). At UGent this is used when more than one teacher have to give grades for the same course. They share comments on the student like this. (these teacher comments, do they overlap with the existing off-by-default facility to "define headings")?
  • The visible items of a user profile/portfolio should be displayed here

developer(s): Ghent University, others

What's new

  • On the course homepage an icon is displayed to inform the user that new items were added to the course. But inside those tool, this notification isn't available. Documents, links,... can be marked as new. A more advanced version would also allow users to mark items as new. (Cfr an email-reader where you can mark emails as 'not read')
  • An option on the homepage to mark all items read and remove the what's new icons (like the mark all topics read-link in a forum)

developer(s): Toon note: This proposal may be too heavy for the database. A possible intermediate solution is a forum-like system to mark all new items since your last visit (and use the session to store this information). Perhaps take a look at how phpbb2 does this.


Who is online

  • Current who's online shows total users of the platform. We extend this to also show persons online on course level.
Note: This needs a extra field 'course' (varchar (40) ) in track_e_online. The install script already has this field but the update script doesn't.

developer(s): Dokeos company, Patrick

Subscribe users to course

  • add search field to search for users, much easier than going through hundreds of users looking for the right one

Developer(s): Roan

Status: done implementing search feature, code of the subscribe_users.php script has been cleaned up as well.

Various

  • System announcements: use date selecter

Extensions

Some plugins or extensions may be developed specifically for working with Dokeos 1.7, need to be reworked for that version, or are simply some finished dream map items that we decided to have as plugins instead of included in the default 1.7 code.

Style Selector

Some discussion in the forum concerning this under http://www.dokeos.com/forum/viewtopic.php?t=4741 incorporation of a style switcher functionality to be able to incorporate specific style sheets for different user accessibility situations Developer(s): Patrick

RSS feeds

  • Provide an RSS-feed in which a user can see all new items on his Dokeos-campus (see forum).

Developers: Bmollet

Status: As "RSS-creator" now available from Dokeos Extensions page

Retrieved from "http://www.dokeos.com/wiki/index.php/Roadmap_Dokeos_1.8/community_2.0"
Personal tools