Bibliography module

2010-10-25T17:16:47Z

Sleitao: /* User Manual */

Bibliography module

2010-10-25T17:11:45Z

Sleitao: /* User Manual */

Bibliography module

2010-10-25T17:01:30Z

Sleitao:

2010-09-02T14:22:10Z

Sleitao: /* Installation */

Bibliography module

2010-03-17T17:38:42Z

Sleitao: New page: (Available soon... March2010) The Bibliography module makes it easy to show and use bibliographic references in your Moodle course. It is contributed by [http://www.up.pt Universidade do ...

(Available soon... March2010)

The Bibliography module makes it easy to show and use bibliographic references in your Moodle course. It is contributed by [http://www.up.pt Universidade do Porto], Nuno Barbosa and [http://moodle.org/user/view.php?id=141886&course=1 Susana Leitão]. It was built based on the glossary module, using same code design and interface patterns.

It allows you to:
* Create different bibliography activities in a course
* Create instances in each bibliography
* Manually insert new entries in a bibliography activity
* View bibliographic references by citekey, date, author, instance
* Comment bibliography entries
* Let students insert their own bibliography entries
* Import and export references in bibtex format

You can also install the bibliography filter and the html editor bibliography icon, which will let you reference to bibliography entries present in your course and automatically add them as a footnote reference list.

error/moodle/auth ssosigarra error user

2009-02-10T17:37:46Z

Sleitao: New page: The error will show you when you try to access moodle@UP platform but your username is not in moodle@UP database system. Maybe you misspelled your username or you are not enrolled in any m...

The error will show you when you try to access moodle@UP platform but your username is not in moodle@UP database system. Maybe you misspelled your username or you are not enrolled in any moodle@UP course.

Please try to login again or contact your local technical support office for more information about your enrollment in moodle@UP courses.

(moodle@UP has custom SSO authentication module SSO(SiGARRA) enabled)

Development:Repository API

2008-03-25T18:38:31Z

Sleitao: changed js170 to jsr170

This page describes the specification for a future feature, currently being worked on for Moodle 2.0. This spec is STILL UNDER CONSTRUCTION.

See MDL-13766 to track the status of the implementation.

The page is open for everyone so everyone can help correct mistakes and help evolution of this document. However, if you have questions, problems or major changes to suggest please add them to the [[Development_talk:Repository_API|page comments]], or start a discussion in the [http://moodle.org/mod/forum/view.php?id=1807 Repositories forum]. We'll endeavour to merge all such suggestions into the main spec before we start development.

==Objectives==

# Allow files to be added directly into Moodle (as we do now)
# Allow all Moodle users to easily bring content into Moodle from external repositories
# Allow content to be used in multiple Moodle contexts securely and simply via capabilities
# Consistency and simplicity for ALL file handling

==Overview==

The Repository API is a core set of interfaces that all Moodle code will use to:
# copy files from external servers
# store files within Moodle
# display files to Moodle users

It's important to remember that a repository will generally be treated as READ-ONLY. Management of the files will normally be done through the native interface provided by the repository. Publishing of Moodle content TO a repository is handled by the [[Development:Portfolio API|Portfolio API]].

==Use cases==

===Teacher adding an external file as a new resource===

# Teacher wants to add a new resource to a course
# Teacher clicks the "Choose a resource" button
# Teacher is able to choose from a list of configured repositories (this step will be skipped if there's only one).
# Teacher is presented with a simple file picker to choose a file
# Teacher chooses a file
# File is COPIED into Moodle and included in the course.
# File is marked as owned by that user
# Access controls are automatically added for that file so that only those with privileges to see that course can see that file (the owner can change those permissions anytime)

===Student submitting an assignment===
# Student needs to submit an assignment and presses the "Choose files" button
# Student sees a "file picker" where they can see files listed on any of several configured repositories
# Student chooses MySpace from the list
# Student is prompted to enter MySpace username/password (a checkbox could be there to "remember this for next time" but for security perhaps not)
# Student sees their files in MySpace and chooses one or more
# Files are copied from MySpace to Moodle
# Assignment module gives the files permissions so that only the Student and assignment graders can see the file (other students would not have permission).

===Student attaching an image to a forum===
# Student needs to attach an image and presses the "Choose files" button in the posting screen
# Student sees a "file picker" where they can see files listed on any of several configured repositories
# Student chooses Mahara from the list
# Student is prompted to enter MySpace username/password (a checkbox could be there to "remember this for next time" but for security perhaps not)
# Student sees their files in Mahara and chooses one image
# Image is copied to Moodle
# Image file is attached to forum post by Forum module (by reference)
# Forum module gives permissions so that anyone who can read that forum can see that file

===Student attaching the same image in another forum===

# Student needs to submit an assignment and presses the "Choose files" button
# Student sees a "file picker" where they can see files listed on any of several configured repositories
# Student chooses Mahara from the list
# Student is prompted to enter MySpace username/password (a checkbox could be there to "remember this for next time" but for security perhaps not)
# Student sees their files in Mahara and chooses one image
# Moodle detects that the image already exists in Moodle so it it not copied again (or it's just updated)
# Image file is attached to forum post by Forum module (by reference)
# Forum module adds some permissions so that anyone who can read the current forum can also see that file

===User managing their files===
# User goes to the "Files" area (similar to current Moodle, but for all users)
# User sees two tabs
# First tab shows listing of current files belonging to self, with buttons to manage them, including buttons to modify the permissions (eg "Allow all people in Course X to see this"). You can also see what repository it came from, including the foreign path, and choose to "update from repository" and get a new copy of the file.
# Second tab shows listing of files belonging to others that you are able to see.

Please add more use cases in this same format

==General Architecture==

All file-handling areas in Moodle (eg adding a new resource, adding attachments to a forum post, uploading assignments) will be rewritten to talk to the standard API class methods in a standard way.

Each repository plugin (a standard Moodle plugin stored under /repository/xxx) will subclass the standard API and override methods specific to that repository.

As is usual in Moodle, there will be admin settings to disable/enable certain repository plugins as standard, as well as user settings so that users can add their own personal repositories to the standard list (eg [http://briefcase.yahoo.com Yahoo Briefcase] or [http://docs.google.com Google Docs]) and to select their default repository.

Once a repository has been used the file will usually be copied into Moodle there and then. However there will also be options to:
* only return the URL to the file if it's desired to keep it external (but this does present security and integrity risks), or
* refresh the local file copy regularly and automatically

All files in Moodle will be listed in a table (see below) allowing us to store various metadata about each file. The file contents will not be the database (though we could easily offer that option if we want to), they will be on disk with a name related to the id rather than the "human" name (this avoids a lot of OS Unicode problems).

The current "course file manager" will be replaced by a personal file manager, which basically is a user's view of the internal Moodle repository, showing the files that are available to you in that context (which may include files from other people, repositories etc) and a nice browse/search interface.

Finally, normal Moodle modules will have easy functions it can use to add/remove permissions to particular files, according to module rules. For example, the assignment plugin may, after allowing a student to select a file to be submitted, add permissions so that people who have grade permissions in that assignment can read it.

All files will be served via a single control script in Moodle, located at $CFG->fileroot. This could be the same as $CFG->wwwroot by default, but will be recommended (for security and avoiding XSS) that Moodle admins set up a second DNS name pointing to this script eg the main site could be at http://moodle.domain.edu but files would be served via http://moodlefiles.domain.edu/file.php. (We'll have to set session cookies on both domains and keep them in sync somehow).

The file.php will serve files using slasharguments almost as now. We just need to replace the courseid with a fileid: file.php/fileid/dir/dir/file.jpg (where dir/dir/file.jpg is the virtual path in Moodle).

==Repository requirements==

From the Moodle point of view, each repository is just a hierarchy of nodes.

The repository MUST provide:
# A URL to download each node (eg file).
# A list of the nodes (eg files and directories) under a given node (eg directory). This allows Moodle to construct a standard browse interface (much like a standard OS file picker). However some repository plugins may choose to completely override the repository_browse() method and implement their own interface, that's OK, as long as they end up with a URL for the file.

The repository can OPTIONALLY:
# Require some authentication credentials
# Provide more metadata about each node (mime type, size, dates, related files, dublin core stuff, etc)
# Describe a search facility (so that Moodle can construct a search form)
# Provide copyright and usage rules (or just information about the rules)

==Repository plugins==

Some plugins I'd like to see developed for the first version are:
* local - very similar to the current course-based file manager, except user-based
* moodle - an interface to another Moodle site, accessed over a secure mnet connection
* jsr170 - an interface that can talk to anything that supports jsr170 (eg [http://www.alfresco.com/ Alfresco])
* oki - an OKI emulator allowing us to access things with OKI interfaces,like [http://www.fedora.info/ Fedora]
* briefcase - an interface to [http://briefcase.yahoo.com/ Yahoo Briefcase]
* myspace - an interface to MySpace files (perhaps via [http://www.programmableweb.com/api/myspace this MySpace API])
* googledocs - an interface to [http://dpcs.google.com Google Docs]
* skydrive - an interface to Microsoft's [http://skydrive.live.com/ SkyDrive] files
* facebook - an interface to Facebook files
* merlot - an interface to the learning materials in [http://www.merlot.org/merlot/materials.htm Merlot.org]
* flickr - an interface to [http://flickr.com flickr]
* youtube - an interface to [http://youtube.com YouTube]
* mahara - an interface to a Mahara installation

==Local Files==

In general, all external files will be copied locally and stored in Moodle. This section describes the storage of the files and how we define ACLs (access control lists) for them. All existing files in the Moodle dataroot course areas will be moved into this new system during the upgrade.

The files will not be stored as they have been in the past. The new file system is "flat" with each file stored as an id. The name and path are stored in tables. To avoid running out of nodes we'll use a hash-like structure like the users directory does, ie:

dataroot
/files
/0
/10000
/20000
/30000
/3076.jpg

==Tables==

=== repository ===

This table contains one entry for every configured external repository instance.

{| border="1" cellpadding="2" cellspacing="0"
|'''Field'''
|'''Type'''
|'''Default'''
|'''Info'''

|-
|'''id'''
|int(10)
|
|autoincrementing

|-
|repositoryname
|varchar
|
|A custom name for this reopsitory (non-unique)

|-
|'''repositorytype'''
|varchar
|
|The name of the plugin being used

|-
|'''userid'''
|int(10)
|
|The person who created this repository instance

|-
|'''contextid'''
|int(10)
|
|The context that this repository is available to ( = system context for site-wide ones)

|-
|username
|varchar
|
|username to log in with, if required

|-
|password
|varchar
|
|password to log in with, if required

|-
|option1
|varchar
|
|Other information useful to the plugin

|-
|option2
|varchar
|
|Other information useful to the plugin

|-
|option3
|varchar
|
|Other information useful to the plugin

|-
|option4
|varchar
|
|Other information useful to the plugin

|-
|option5
|varchar
|
|Other information useful to the plugin

|-
|timecreated
|int(10)
|
|The time this repository was created

|-
|timemodified
|int(10)
|
|The last time the repository was modified
|}

=== file ===

This table contains one entry for every file. Enough information is kept here so that the file can be fully identified and retrieved again if necessary.

{| border="1" cellpadding="2" cellspacing="0"
|'''Field'''
|'''Type'''
|'''Default'''
|'''Info'''

|-
|'''id'''
|int(10)
|
|autoincrementing

|-
|'''userid'''
|int(10)
|
|The owner of the file (person who created this entry)

|-
|filename
|varchar
|
|The full Unicode name of this file

|-
|'''repositoryid'''
|int(10)
|
|The repository instance this is associated with

|-
|updates
|int(10)
|
|Specifies the update schedule (0 = none, 1 = on demand, other = some period in seconds)

|-
|cachetime
|int(10)
|
|Specifies how long this file can be cached by browsers

|-
|moodlepath
|text
|
|The virtual path to the file locally (so we can still have apparent subdirectories etc)

|-
|repositorypath
|text
|
|The full path to the original file on the repository

|-
|timeimportfirst
|int(10)
|
|The first time this file was imported into Moodle

|-
|timeimportlast
|int(10)
|
|The most recent time that this file was imported into Moodle

|-
|timecreated
|int(10)
|
|The time this file was created (if known), otherwise same as time imported

|-
|timemodified
|int(10)
|
|The last time the file was modified

|-
|timeaccessed
|int(10)
|
|The last time this file was accessed for any reason
|}

=== file_instances ===

This table contains one entry for every "place" a file is published to. For example, one file might appear in an assignment but also in a forum attachment, so there would be two entries here.

{| border="1" cellpadding="2" cellspacing="0"
|'''Field'''
|'''Type'''
|'''Default'''
|'''Info'''

|-
|'''id'''
|int(10)
|
|autoincrementing

|-
|'''fileid'''
|int(10)
|
|The file we are defining access for

|-
|instancetype
|varchar
|
|This defines the table in Moodle that this instance is associated with (eg 'forum_posts', 'assignment_submissions' etc

|-
|'''instanceid'''
|int(10)
|
|The id in the foreign table (of name instancetype) that this instance is associated with
|}

=== file_access ===

This table describes the ACL for each file, so that checks can easily be made on whether someone can see this file or not. Note there can be multiple entries per file. Users can ALWAYS see their own files, so there are no entries here for that.

{| border="1" cellpadding="2" cellspacing="0"
|'''Field'''
|'''Type'''
|'''Default'''
|'''Info'''

|-
|'''id'''
|int(10)
|
|autoincrementing

|-
|'''fileid'''
|int(10)
|
|The file we are defining access for

|-
|'''contextid'''
|int(10)
|
|The context where this file is being published

|-
|'''capability'''
|text
|
|The capability that is required to see this file
|}

==Class methods==

===Repository class===

This class implements the interface to a particular repository, for browsing, selecting and updating files.

====get_file($path)====

====get_listing($parent='/', $search='''''''')====

====cron()====

====etc====

===File class===

This class implements the display and management of files from local storage, with full access checking. Some of the functions are for single files, while some are optimised for bulk display and searching (eg in the personal files interface).

====display_file()====

sort of like file.php is now, except smarter

====set_access($fileid, $accessstuff)====

Grant some access to people to a file

====has_access($fileid, $userid=NULL)====

Returns true or false depending on access to a file

==Areas in Moodle that need re-writing==

Sandbox

2007-05-08T11:15:21Z

Sleitao: /* Aesthetic buggery to follow! */

abcdef deneme 1 2

Very nice :-) 
Moodle is Great! 

'''== אחת שתיים שלו ארבע
==== Headline text ==== Headline text =='''Bold text''''''

====aaaaaa====

==Aesthetic buggery to follow!==
<hr size=5>
<hr size=10>
<hr size=20>
... well, that's too bad: <tt> I was expecting to be able to make larger headers! [pout!]</tt>

:Interesting. Don't know much about HTML but
#remember this is a Mediawiki.
#When I want to try something off the beaten track in MoodleDocs, I [http://meta.wikimedia.org/wiki/Help:Editing#Templates start here with a search on editing tips].
#Since I am a clutz, I created a web page using a word processor. Then opened my browser and revealed the page code. Then placed it below. So you can make larger headers several ways. chris collman
::see examples below

==This is 26.opt test==

Notice it still is a header just not the default font

===This is a 3rd level - a little smaller===

====This is a 3rd level header - Probably no difference====

== Headline text ==

Martha is a radical

=Is a 1st level header - the larger header topic=

just to see what would happen

=This is a 400.opt font test

Hmm...

[[fr:Bac à sable]]

Just testing it out!

Seems OK!

Sandbox

2007-05-08T11:14:56Z

Sleitao: /* Aesthetic buggery to follow! */

abcdef deneme 1 2

Very nice :-) 
Moodle is Great! 

'''== אחת שתיים שלו ארבע
==== Headline text ==== Headline text =='''Bold text''''''

====aaaaaa====

==Aesthetic buggery to follow!==
<hr size=5>
<hr size=10>
<hr size=20>
... well, that's too bad: <tt> I was expecting to be able to make larger headers! [pout!]</tt>

:Interesting. Don't know much about HTML but
#remember this is a Mediawiki.
#When I want to try something off the beaten track in MoodleDocs, I [http://meta.wikimedia.org/wiki/Help:Editing#Templates start here with a search on editing tips].
#Since I am a clutz, I created a web page using a word processor. Then opened my browser and revealed the page code. Then placed it below. So you can make larger headers several ways. chris collman
::see examples below

[[link]]

==This is 26.opt test==

Notice it still is a header just not the default font

===This is a 3rd level - a little smaller===

====This is a 3rd level header - Probably no difference====

== Headline text ==

Martha is a radical

=Is a 1st level header - the larger header topic=

just to see what would happen

=This is a 400.opt font test

Hmm...

[[fr:Bac à sable]]

Just testing it out!

Seems OK!