Note: You are currently viewing documentation for Moodle 1.9. Up-to-date documentation for the latest stable version is available here: Student projects/Admin page cleanup.

Student projects/Admin page cleanup: Difference between revisions

From MoodleDocs
mNo edit summary
 
(79 intermediate revisions by the same user not shown)
Line 1: Line 1:
Right now, I'm trying to work on a more "logical" reorganization of the settings accessible via the admin page. Slowly getting there... Please use the talk page to leave me any comments, I'll be checking it regularly.
{| style="color:black; border: 2px solid red; width: 100%; height: 20px;"
| <center>'''Source code now available on CVS (web access [http://moodle.cvs.sourceforge.net/moodle/moodle/ here])'''
Please note the statuses on this page are out of date. For the latest issues and bugs, check the [http://tracker.moodle.org/ Moodle bugtracker]</center>
|}


== Key Project Tasks/Deliverables ==


* Re-organize moodle admin settings
== Key Project Tasks ==
* Design XML DTD
* Port moodle admin settings to XML
* Code PHP script to output hierarchy
* Code PHP script to display a setting-group
* Code PHP script to write modifications to settings
* Build a bookmarking system (per-user) for admin settings
* Redo the user management interface
* Code the necessary PHP to highlight changed settings after an upgrade


== Current Admin Layout (from 1.5) ==
* <strike>'''(done)''' [[Student projects/Admin page cleanup/XML file format|Design XML DTD]]</strike> '''(done)''' [http://betaserv.vkm.ca:82/moodlemindmaps/moodle_admin_classes.png Design OO format for admin]
* '''(almost done -- 2 issues remaining)''' [[Student projects/Admin page cleanup/Admin block|Design new admin block]]
* '''(done)''' [[Student projects/Admin page cleanup/Reorg|Reorganize and port Moodle admin settings to OO structure]]
* '''(done, except for possible bugs)''' [[Student projects/Admin page cleanup/Admin subpages|Code script for displaying and accepting input from new admin interface]]
* '''(done)''' [[Student projects/Admin page cleanup/Bookmarks|Build a per-user bookmarking system for admin settings]]
* '''(done)''' [[Student projects/Admin page cleanup/Upgrade|Code the necessary PHP to highlight changed settings after an upgrade]] (see admin/upgradesettings.php)


Admin
== Remaining Issues ==
*Configuration
**Variables
***Interface
****lang (select)
****langmenu (select)
****langlist (text)
****langcache (select)
****locale (text)
****timezone (select)
****country (select)
****framename (text)
****themelist (text)
****allowuserthemes (select)
****allowcoursethemes (select)
****allowuserblockhiding (select)
****showblocksonmodpages (select)
****tabselectedtofront (select)
***Security
****displayloginfailures
****notifyloginfailures
****notifyloginthreshold
****secureforms
****loginhttps
****runclamonupload
****pathtoclam
****quarantinedir
****clamfailureonupload
***Operating System
****gdversion
****dbsessions
****sessiontimeout
****sessioncookie
****zip
****unzip
****pathtodu
****slasharguments
****proxyhost
****proxyport
***Maintenance
****longtimenosee
****deleteunconfirmed
****loglifetime
***Mail
****smtphosts
****smtpuser
****smtppass
****noreplyaddress
****digestmailtime
****allowemailaddresses
****denyemailaddresses
***User
****sitepolicy
****fullnamedisplay
****extendedusernamechars
****autologinguests
***Permissions
****teacherassignteachers
****allowunenroll
****allusersaresitestudents
****showsiteparticipantlist
****forcelogin
****forceloginforprofiles
****opentogoogle
****maxbytes
****messaging
****allowobjectembed
***Miscellaneous
****maxeditingtime
****debug
****perfdebug
****enablerssfeeds
**Site Settings
***Full site name
***Short name for site
***Front page description
***Front page format
***Include a topic section
***News items to show
***Your word for teacher
***Your word for teachers
***Your word for student
***Your word for students
**Themes
***Select a theme
**Language
***Update language pack from moodle.org
***Check for missing strings
***Edit strings (per file)
***Edit help documents
**Modules
***Hide/show (per module)
***Delete (per module)
***Specific settings (per module)
**Blocks
***Hide/show (per block)
***Multiple (per block)
***Delete (per block)
***Settings (per block)
**Filters
***Active/Inactive filters (and order)
***Text cache lifetime
***Filter uploaded files
***Filter all strings
**Backup
***Include modules
***Metacourse
***Users
***Logs
***User files
***Course files
***Messages
***Keep x files
***Schedule SMTWTFS
***Time to execute
***Save to
**Editor Settings
***htmleditor
***editorbackgroundcolor
***editorfontfamily
***editorfontsize
***editorkillword
***aspellpath
***editorspelling
***fonts in editor's dropdown menu
***editorhidebuttons (hidden buttons)
**Calendar
***adminsseeall
***startwday
***weekenddays
***upcoming_lookahead
***upcoming_maxevents
***timezones
***timezone update/import
**Maintenance Mode
***enable/disable
***message
*Users
**Authentication
***(still looking into the different authentication methods)
**Edit User Accounts
***browse/edit/delete/add/search/alphasort users
**Add a New User
***(links to 'edit profile' for a new user)
**Upload Users
***import file
**Enrolments
***(still looking into different methods of enrolment)
**Enrol Students
***links to different courses (chosen via plain list) in admin mode
**Assign Teachers
***links through course cateogries to choose a course
**Assign Creators
***list to select from existing users
**Assign Admins
***list to select from existing users
*Courses
**shows course categories
**add/view/move/rename/delete catgories
**add a new course
**delete a course/other tasks (double-check what exactly they are)
*Logs
**live logs
**filter by date/site/participant/activity
*Site Files
**upload a file
**rename/delete/move to folder/delete files
**make a folder
*Environment
**evaluates current server environment for future moodle versions


== Proposed Structure ==
* <strike>Find a good way to mark settings that are set on initial install</strike>
 
* <strike>Find a good way to display settings that are added (or set to default values) during an upgrade</strike>
Alrighty, here's the deal for how this is organized: I'm proposing a 2-or-3-level hierarchy for the reorganization. However, this list only contains what I'm calling "final" top-level categories. The stuff under the top-level categories isn't yet organized into second- and third-level categories; it's just a list of items from the "Current Structure" list.
* <strike>Figure out how user_is_editing() should work in admin/pagelib.php</strike>
 
* <strike>Specify the $paramtype for all admin_setting_configtext objects and children</strike>
* User Interface
* Specify the $role for all admin_externalpage and admin_settingpage objects
**variables\interface
* Specify explicit $precedence values for all admin_externalpage, admin_settingpage, and admin_category objects
**variables\user\sitepolicy
* Fix non-language-specific strings, and add required langfile strings
**variables\user\fullnamedisplay
* <strike>Work out a way to handle gd_version</strike>
**site settings
* Consider adding icons and/or custom names for admin bookmarks
**themes
* Fix icons in admin_2 block to be theme-dependent
**language
* Find out if admin_2 block can be set up as an HTML list (and still work with Javascript)
**editor settings
* Fix admin/pagelib.php to include admin_2 and admin_bookmarks as default blocks
**calendar (except calendar\adminsseeall)
* For the course management section, allow view-only-mode? (i.e. the mode in which you don't edit categories)
**site files
* Work out which files can be safely removed from the admin dir
* Server Interface (a.k.a. backend)
* See if we can eliminate the old admin block (bear in mind it's still used on course pages)
**variables\maintenance
**variables\operating system
**variables\mail
**variables\user\extendedusernamechars
**variables\user\autologinguests (this might be better placed in security/auth)
**variables\miscellaneous
**test for future versions
* Authentication & Security
**variables\security
**variables\permissions
**calendar\adminsseeall
**user management (to be completely redone)
* Maintenance & Auditing
**backups
**maintenance mode
**logs
* Course Management
**to be worked out
* Plug-in Management
**filters
**blocks
**modules
* Bookmarks (per admin user)
 
== XML File Format ==
 
Here's a sample of how the moodle admin configuration file will look
 
<moodleadmin>
  <category name="Some Language File Link">
    <settinggroup name="Something Else">
      <setting name="..." type="(text|select|htmledit)" selectoptions="option1,option2,option3"
        description="..." upgrade="(flagged|acknowledged|none)" setoninstall="(true|false)"
        writeproc="setconfig..." readproc="print..." />
    </settinggroup>
    <settingpage name="Whatever" internalname="string3" hardcoded="filename.php" />
  </category>
</moodleadmin>
 
The idea behind the XML format is to make it easy to add variables without having to modify raw PHP code. The "name", "selectoptions", "description", "writeproc", and "readproc" fields will be parsed as PHP, so we can easily define how we read or write the value of a variable in the XML file. (And, naturally, the "name" field has to be parsed since this is multi-lingual.)
 
The DTD (which I haven't yet verified) would look like
 
<!ELEMENT moodleadmin (category|settinggroup|settingpage)*>
<!ELEMENT category (category|settinggroup|settingpage)*>
  <!ATTLIST category name CDATA #REQUIRED>
<!ELEMENT settinggroup (setting*)>
  <!ATTLIST settinggroup name CDATA #REQUIRED>
  <!ELEMENT setting EMPTY>
    <!ATTLIST setting name CDATA #REQUIRED>
    <!ATTLIST setting type (text|select|htmledit) #REQUIRED>
    <!ATTLIST setting selectoptions CDATA #IMPLIED>
    <!ATTLIST setting description CDATA #REQUIRED>
    <!ATTLIST setting upgrade (flagged|acknowledged|none) "none">
    <!ATTLIST setting setoninstall (true|false) "false">
    <!ATTLIST setting readproc CDATA #REQUIRED>
    <!ATTLIST setting writeproc CDATA #REQUIRED>
<!ELEMENT settingpage EMPTY>
  <!ATTLIST settingpage name CDATA #REQUIRED>
  <!ATTLIST settingpage hardcoded CDATA #REQUIRED>
 
Regarding the ideas that Martin & I had thrown around about flagging settings added during an upgrade, I think we could very easily do this through a second XML file (following the same DTD format) called, say, "upgrade.xml". This file will be created/modified on upgrades and list only those variables that were added. Then, it's a simple matter of a PHP frontend to let the admin modify all the settings affected by the upgrade.
 
== Random Ideas ==
 
* I mentioned (in my proposal) using XML to store the hierarchy. I still think this is ideal (after all, XML seems to lend itself to hierarchical data), but I think there are a few ways to expand this. Notably, along with the settings, we can store
# whether a setting should appear on the initial (installation) config page (granted, this'll require a rewrite or modification of the initial config page)
# if a new setting has been set to the default because of an upgrade, then we can have a config page that appears when upgrading which shows only the flagged, new variables (i.e. those that were set to defaults)
* Site settings and editor settings could be grouped together (but I won't jumble up settings between the two of them; they'll just have the same parent in the hierarchy).
* Logs and Site Files sections look good as-is... probably won't make very many changes there
* Will try to improve on course administration interface (ideas to come soon)
* (Sort of) redo the user management interface so that we can get rid of the "Assign Teachers", "Assign Admins", etc. options on the main admin page (i.e. have a single link to a "User Management Interface" and do everything else from there.
* Group Modules, Filters, and Blocks (and other 16 types of plugins) under a top-level category called Plug-Ins (similar to the way it's done on [http://moodle.org/mod/data/view.php?id=6009 moodle.org])
* Will probably use the PHP SimpleXML extension for reading XML files; variable data will be stored in current locations, not in XML, thus no XML changes will be made by PHP
 
== Random Questions ==
 
* There are no settings for specific filters? They're only active or inactive? A: There can be, just none have any yet.
* When it comes to the hierarchical menu, I mentioned JavaScript-based... custom-written or is there already some sort of open source framework for collapsible JavaScript hierarchies? A: Settled -- I've already custom-written a JS hierarchy
* Anyone mind if I rewrite the user management pages? I'm thinking a single interface to do everything with regards to users. (details soon to be posted at [[Student projects/Admin page cleanup/User management interface]])
* XML Schema or DTD?
* Are there changes to the admin section between the MOODLE_15_STABLE and MOODLE_16 interface? Which should I be working with primarily? A: Yup, use MOODLE_16.


== Links ==
== Links ==
Line 288: Line 36:
* Get back to the [[Student_projects | Student Projects]] listing.
* Get back to the [[Student_projects | Student Projects]] listing.
* You can get my official SoC app [http://vkm.ca/?s=soc2006-moodle-app here].
* You can get my official SoC app [http://vkm.ca/?s=soc2006-moodle-app here].
* My sample moodle setup (for fooling around & such) is [http://demoserv.vkm.ca:822/moodle here].
* My sample moodle setups are <strike>[http://demoserv.vkm.ca:822/moodle here for 1.5]</strike>, <strike>[http://betaserv.vkm.ca:82/moodle here for 1.6]</strike> and [http://betaserv.vkm.ca:82/moodle17/moodle here for 1.7 beta].
* A beta hierarchy script (actually, a PHP hierarchy object) that I created for this is available [http://demoserv.vkm.ca:822/temp.php here].


[[Category:Developer]]
[[Category:Developer]]
[[Category:Project]]
[[Category:Project]]

Latest revision as of 04:39, 21 September 2006

Source code now available on CVS (web access here) Please note the statuses on this page are out of date. For the latest issues and bugs, check the Moodle bugtracker


Key Project Tasks

Remaining Issues

  • Find a good way to mark settings that are set on initial install
  • Find a good way to display settings that are added (or set to default values) during an upgrade
  • Figure out how user_is_editing() should work in admin/pagelib.php
  • Specify the $paramtype for all admin_setting_configtext objects and children
  • Specify the $role for all admin_externalpage and admin_settingpage objects
  • Specify explicit $precedence values for all admin_externalpage, admin_settingpage, and admin_category objects
  • Fix non-language-specific strings, and add required langfile strings
  • Work out a way to handle gd_version
  • Consider adding icons and/or custom names for admin bookmarks
  • Fix icons in admin_2 block to be theme-dependent
  • Find out if admin_2 block can be set up as an HTML list (and still work with Javascript)
  • Fix admin/pagelib.php to include admin_2 and admin_bookmarks as default blocks
  • For the course management section, allow view-only-mode? (i.e. the mode in which you don't edit categories)
  • Work out which files can be safely removed from the admin dir
  • See if we can eliminate the old admin block (bear in mind it's still used on course pages)

Links