MoodleDocs - User contributions [en]

Portfolio API

2008-07-22T20:06:08Z

Shinoda: /* Duplication of Cata */

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

==Overview==

The Portfolio API is a core set of interfaces that all Moodle code will/should use so that we can easily publish files to all kinds of external document repository systems.

It's important to remember that portfolios are generally treated as WRITE-ONLY. All we are doing in Moodle is grabbing stuff and pushing it out to somewhere. Management of the files and further combining/reflecting is done through the native interface provided by the portfolio system. Reading of files from a repository is handled by the [[Repository API|Repository API]].

A typical user story:

# When portfolios are enabled, every page or major piece of content in Moodle has a little "Save" button beside it.
# User clicks one of these buttons
# User is able to choose from a list of configured portfolios (this step will be skipped if there's only one).
# User may be asked to define the format of the captured content (eg pdf, IMS LD, HTML, XML ...)
# User may be asked to define some metadata to go with the captured content (some will be generated automatically).
# The content and metadata is COPIED to the external portfolio system
# User has an option to "Return to the page you left" or "Visit their portfolio".

Note this will be just as useful for teachers as for students.

The formatting possibilities will vary depending on the context of the button and the type of external portfolios. So for example, the "Save" button on the course page would allow the user to capture the whole course in IMS LD or Moodle backup format, which you would not have on a forum page.

==Architecture==

Here is how it will work:

===Plugins and libraries===

There will be two separate types of plugins

# Portfolio (eg Mahara/Elgg/OSP/Facebook/Download) - this will be portfolio/type/xxx
# Transport (eg mnet/http/scp/cp/dav etc) - these will be reused across different portfolio plugins

Then there will be different formats that plugins will support (and the part of moodle exporting content must support as well), eg IMS, moodle native, mahara native, pdf, enrypted pdf. These will have good libraries supporting them.

The reason for this is that I can see for abstracting the transport layer to its own plugin type is that it's pretty likely that the same external system might talk both portfolio and repository.

===Admin===

It is important to be allowed to have multiple instances of (some) plugins. The workflow for adding a new one is:

*Admin navigates to portfolio config
*Selects from the list of available portfolio plugins, and clicks 'add a new external portfolio' (some may be disabled if there is an instance already and the plugin doesn't support multiple instances)
*Configure the plugin - select which transport and content types to use if there are multiple supported and installed, urls, authentication keys, etc.
*Set permissions (maybe) - handled by roles.

This is not necessary for every type of portfolio, because many will just require the user to authenticate directly and if we do ever want to retain settings for each user we just use user preferences.

===Exporting===

*User is viewing a page that calls portfolio_add_button(). This checks to see if there are any configured portfolio plugin instances, and also (maybe) any permissions related to portfolios, and what the user's portfolio settings are, and then displays either a single 'add to portfolio' button, or a drop down menu of the available systems with the add button.
*When this button is pressed, the user is redirected to portfolio/add.php, with some post data containing the responsible area (activity module or something like course or blog) callback file and function.
*On this page, the user is presented with a form to enter metadata about the item, and configure any options. At this point if there are multiple formats available for export (based on the intersection of what the plugin and module support), the user can select which format they want. The plugin and module can both export mform elements for this page. The user can at this point also select to send the data and wait (with a warning it might take awhile), or queue it for processing if it's larger.
*When the user has submitted the form, they are displayed a summary of what they're about to export, with 'confirm' and 'edit' buttons. Edit just relaunches the form, and confirm goes to the next step.
*At this point, the portfolio plugin (or transport plugin) might need to take control for a step. For example, facebook or flickr might require the user to log in for the first time and confirm moodle is allowed to access their API
*When the user has confirmed their summary, a 'portfolio_send' event will be triggered. At this point, one of two things happen.
# If the user has elected to wait, the 'instant' event is fired, and when the caller gets control again, it displays the status to the user.
# If the user has elected to queue, the delayed event is fired and the user is notified.
*The user is given the option to continue to their portfolio, or return to where they were
*
*When the event is handled (either through the cron or instant event), the following happens:
*The event handler is invoked. This is almost certainly going to be a function in lib/portfoliolib.php rather than any handler in the portfolio plugins. The event handler in turn calls the original callback that was passed to portfolio/add.php (module//lib.php or course/lib.php or something), which prepares the data in the format the user selected and returns control to the event handler.
*At this point we have all the metadata we need, and we have the content to send, so it's time to start transport negotiation, which happens in stages. Note that some plugins might not implement all stages, and 3 and 4 might be interchangeable in order, depending on the external system.
#request
#authentication
#content
#metadata (some control is passed to the portfolio plugin for packaging - either to just write out an xml file and zip up the whole package, or send a series of requests)
#completion
*When this is complete, we return control to the event handler (which, if it's an 'instant' one, will return true to the caller, which will be the ajax request)

===Storage===

Obviously during this process, state is going to be lost between webserver requests and also between user input and event handling. Some data will be stored in the user's session (the result of the metadata form, for example) and some in temporary files on the file system. These will be stored in dataroot/temp/portfolio/$userid-$timestamp/

===Access/Permissions===
* Portfolio plugin must be allocatable per context (site/course/group etc)
* How can we assume all users will have an account on the remote system? We could try and silently authenticate them (or at least see if it's possible to) in the background at the first call to portfolio_add_button (and then cache the result in the session)
* Check MNet policy - it assumes everyone with the role can have an account (assuming they_sso_in or whatever it's called is on) - this doesn't scale though, other transport mechanisms and or plugin types might not follow this assumption. I think this really must be defined by the portfolio plugin only, not the transport plugin.

===Event API===

It is probably worth using the event api to handle the sending of data, mostly just because it provides a handy way of detached processing. However, any portfolio_send event will be 'owned' by particular "instances" of plugins - and each plugin that subscribes to portfolio_send event (all of them by definition) will have to check if the event data belongs to any of their instances, which is potentially quite messy.

==Technical==

===Abstract Portfolio Baseclass: portfolio_plugin_base===

Mixes providing some basic functionality by means of its own functions, with a number of abstract functions plugins must implement, and with some functions that plugins can also optionally override.

See also: [[Writing_a_Portfolio_Plugin]] for a full list of all methods you must/can/shouldn't override, as well as associated instructions for what else you need to do to create a new portfolio plugin

===Abstract Caller Baseclass : portfolio_caller_base===

Whenever somewhere in Moodle wants an 'add to portfolio' button, they must subclass this.

See also: [[Adding_a_Portfolio_Button_to_a_page]] for a full list of all methods you must/can/shouldn't override as well as the associated instructions for how to call portfolio_add_button.

===Database Tables===

The actual information about plugins that are installed is just stored in mdl_config.

Additionally, as we're configuring instances of plugins, rather than just one config set per plugin, we're not using mdl_config_plugin, but instead our own set of tables:

'''portfolio_instance:'''

{| border="1" cellpadding="2" cellspacing="0"
|-
|'''Field'''
|'''Datatype'''
|'''Comment'''
|-
|id
|integer
|sequence
|-
|plugin
|varchar(50)
|name of plugin (should match directory in portfolio/type)
|-
|name
|varchar(255)
|name of this plugin instance
|-
|visible
|smallint
|0 or 1
|}

'''portfolio_instance_config:'''

{| border="1" cellpadding="2" cellspacing="0"
|-
|'''Field'''
|'''Datatype'''
|'''Comment'''
|-
|id
|integer
|sequence
|-
|instance
|integer
|(pseudo)fk to portfolio_instance
|-
|name
|varchar(255)
|config name
|-
|value
|text
|config value
|}

'''portfolio_instance_user:'''

{| border="1" cellpadding="2" cellspacing="0"
|-
|'''Field'''
|'''Datatype'''
|'''Comment'''
|-
|id
|integer
|sequence
|-
|instance
|integer
|(pseudo)fk to portfolio_instance
|-
|userid
|integer
|(pseudo)fk to mdl_user
|-
|name
|varchar(255)
|config name
|-
|value
|text
|config value
|}

All plugins can also implement their own database tables as needed, by creating a db/install.xml and db/upgrade.php inside portfolio/type/xxx/ (See [[Writing_a_Portfolio_Plugin]]) for more information.

===Portfolio Plugins===

#[[Mahara_Portfolio_Plugin|mahara]] (will be done for the initial implementation)
#download (should be done for the initial implementation)

transport types and formats should be able to be found in a shared location for multiple plugins of both portfolio and repository type to use, but also might be specific to one type of plugin which means that moodle should support looking in multiple locations for these plugins. (eg mahara native format will be in the mahara portfolio plugin, but pdf format will be in a shared library)

===Possible Transport Types===

# mnet (will be done for the initial implementation as part of the Mahara Portfolio Plugin)
# download (will be done for the initial implementation as part of the Download Portfolio Plugin)
# http
# filesystem (could be local/nfs/samba whatever) (cp)
# ssh based (eg scp - should find and re-use the elgg block code as it deals with using ssh keys nicely)
# webdav
# open social? (http://code.google.com/apis/opensocial/)

===Possible Export Formats===

(Note that we don't necessarily want more than one of these for the initial implementation)

# html
# pdf
# encrypted pdf
# ims?
# leap/piop? (http://wiki.cetis.ac.uk/LEAP_2.0) -- looking increasingly possible Mahara will speak this, so hopefully for the intial implementation
# moodle native?
# mahara native?
# Dublin Core (Enovation implemented this)

===Testing===

Nico to help (see Development Approach for TDD-related approach)

==MNET==

This section has moved to [[MNET_Roadmap]]

==Duplication of Data==

Moodle will keep track of what content it transfers and when. It'll remember the url of the original export location (alphabetisising the url parameters and removing the sessionkey) and a sha1 hash of the data, so that if the user tries to export the same content, Moodle can warn the user (along with a notification of whether it has changed or not).

At this point we can build support into the API for plugins to offer to differentiate between 'replace' and 'add', but won't implement it for any we write for the initial implementation.

==Assumptions==

* Using Moodle's built in Event API

==Outstanding questions==

*which parts of Moodle will have this button to start with (in order of necessity)
*Dependance of transport plugins - eg filesystem might depend on http for sending request/finished pings

==Development Approach==
* create two base classes
* create mahara portfolio plugin, relying on mnet
* create portfolio/add.php and portfolio/lib.php
* start adding calls to the portfolio_add_button function to various places in moodle, with their callbacks.
* create a dummy listener in mahara until the mahara side is specified

After a conversation with Nico about testing, we decided the most sensible ordering to start with would be:

# Write portfolio/add.php
# Write *skeleton functions* to support it in portfolio/lib.php and the class structure
# Write tests for those methods that are necessary
# Implement the functions to make the tests pass
# Keep adding module implementations

==See also==
* [[Repository API]]
* [[File API]]

Talk:Mahara Portfolio Plugin

2008-07-22T11:41:53Z

Shinoda:

=== Question 1 ===

It occurs to me that maybe Mahara could send back information about where files could be put/blogposts could be stored etc, as part of the reply to the "intent to send" request? In the "happy path", we wouldn't expect this information to change, so maybe it's safe to send back something then? [[User:Nigel McNie|Nigel McNie]] 07:40, 20 July 2008 (CDT)

We'd have to send back information about where to put any possible content though, because at the intent to send stage, we don't know what format it is (eg, it might just be a file but could be a LEAP/PIOP component, which would go into a whole another artefact plugin). we'd essentially have to send back the entire artefact tree. and then even if we did that, at that point Moodle still doesn't know what format the user wants, so we'd still have to add another step._
[[User:Penny_Leach|Penny Leach]]

=== Proposed MNET Changes ===

I think the application2service table is a good idea (no more Mahara "course enrolments"!). But I don't like the idea that the URL field is in this table. Even though it varies by application, it doesn't apply to _every_ service, and therefore is redundant much of the time. Furthermore, if more services are added that need their own custom per-application fields, all of a sudden this table is getting very big with a lot of poorly related fields.

A different model that doesn't suffer the problem is this:

==== application2service ====

{| border="1" cellpadding="2" cellspacing="0"
|-
|'''Field'''
|'''Datatype'''
|'''Comment'''
|-
|id
|integer
|sequence
|-
|applicationid
|integer
|fk to mnet_application
|-
|serviceid
|integer
|fk to mnet_service
|}

==== application2service_sso ====
{| border="1" cellpadding="2" cellspacing="0"
|-
|'''Field'''
|'''Datatype'''
|'''Comment'''
|-
|id
|integer
|sequence
|-
|a2sid
|integer
|fk to application2service(id)
|-
|url
|char(255)
|
|}

[[User:Nigel McNie|Nigel McNie]] 06:41, 22 July 2008 (CDT)

Talk:Mahara Portfolio Plugin

2008-07-22T11:39:16Z

Shinoda: Note about application2service table

Talk:Mahara Portfolio Plugin

2008-07-20T12:40:20Z

Shinoda: /* Question 1 */

Talk:Mahara Portfolio Plugin

2008-07-20T12:40:00Z

Shinoda: New page: === Question 1 === It occurs to me that maybe Mahara could send back information about where files could be put/blogposts could be stored etc, as part of the reply to the "intent to send"...

Talk:Repository API

2008-06-17T12:08:00Z

Shinoda:

(Ideas will be deleted from the comments section as they are resolved or merged into the main spec)

===Missing concept of trusted files===
Files are not created equal, some of them are to be trusted, some can not be trusted at all. Web browsers trust everything received from the server, files from server may access cookie information and thus scripting technologies may allow them to do anything user can do. We do have to trust our teachers because they are supposed to create the learning content, but we definitely can not trust all students.

Imagine if students were allowed to upload arbitrary files to server, like html file loaded with javascript and the server would happily serve them to all Moodle users. Our solution is to use html cleaning filters for submitted texts and force downloads of student uploaded files. To do this we must know if we trust the files or not. Unfortunately the forced downloads of student uploaded files and cleaning of html texts does not solve all problems, because bugs in browsers and especially browser plug-ins may sometimes be used to work around our protections.

The best solution would be to use separate web addresses for trusted and not trusted files (two wwwroots in config.php), not all sites may afford two different addresses but we should be imo prepared for this. [[User:Skodak|Skodak]] 16:42, 28 February 2008 (CST)

Great idea, yes. In fact couldn't all the files be served via $CFG->fileroot all the time?
[[User:Martin Dougiamas|Martin Dougiamas]] 07:08, 29 February 2008 (CST)

userid field could be used for this, but separate flag might be better in order to allow teachers to upload untrusted files (teacher uploads assignment submission for the student).

===Relative file links===
Flash, Java and SCORM require relative links and directory hierarchy in general - we must support it. Some SCORM packages load hundreds of files per page which means the file serving must be very fast with minimum of db access.

Reading the proposal above it seems the API is about serving of isolated files referenced by repository ids. HTML requires to use relative or absolute locators with file names, we can not use repository ids directly in relative links. In case of scorm we have absolute path to base of SCORM package of given activity and SCORM files use relative links inside the package.
Solution could be to store relative paths directly in filename field ex:directory1/directory2/filename.ext.

Yes I agree, we definitely need to support (virtual) directories and slasharguments.
We could just match the file argument to a path in the db. Perhaps add the fileid
to the argument path as a primary key: fileid/directory1/directory2/filename.ext
[[User:Martin Dougiamas|Martin Dougiamas]] 07:08, 29 February 2008 (CST)

===Virtual directories and files===
Sometimes the content of files is generated on the fly (csv exports, etc.), there are many special files spread through codebase doing nearly the same, it should be imho possible to use the same file API for these.

Another virtual example is assignment submissions and webdav. I would like to see an option to browse the assignment submissions as directory structure, the top directory would be a list of names of users, inside html files with online assignment and uploaded files. This would allow us to implement simple zip&go or webdav based offline grading solutions. The problem here is that the content of this virtual submissions directly needs to be created on the fly based on user references, the proposed repository structure can not be used for this.

Very interesting idea! [[User:Martin Dougiamas|Martin Dougiamas]] 07:08, 29 February 2008 (CST)

===Backup/restore relinking===
We are supporting relinking inside courses only. Till now it was easy to guess if absolute link will work after restore on another server.
There are several types of files:
*course files - relinked during restore, works on any server if from the same course
*module files - not relinked, urls are not permanent, link can not be copypasted (assignments, forum attachments, rss files, etc.)
*user files - not relinked, links work only on original server (blog attachments, personal files, etc.)

I think all this will be simplified in the proposed system because everything is
represented using the same system: a file with an ACL (backup can quickly
determine all the files in one course, probably using one SQL query).
[[User:Martin Dougiamas|Martin Dougiamas]] 07:08, 29 February 2008 (CST)

If we are backing up/restoring on the same server, will copies of a course restore without file duplication? I use this a lot so that I can archive one year's course whilst modifying it for next year. [[User:Matt Gibson|Matt Gibson]] 03:12, 29 April 2008 (CDT)

===Access needed for both file and its instances===
We need two types of access control - first who can create instances (link files), second who can access the instance (download the file).

For the first don't we already have those capabilities? (like mod/forum:createattachment,
moodle/course:managefiles) but they probably could use rationalising. We'll need new
ones per repository, too, of course.
[[User:Martin Dougiamas|Martin Dougiamas]] 07:08, 29 February 2008 (CST)

===Cache lifetime===
There should be a way to specify cache filetime for each instance of file. For example 0 for uploaded assignments, 1 day for resource file. It might be better to allow modules to decide about this, at present it is hardcoded in file.php.

Great idea. [[User:Martin Dougiamas|Martin Dougiamas]] 07:08, 29 February 2008 (CST)

== Hierarchy in tables ? ==

It's possible that I don't undertand a key piece of the concept, but I wonder why there is no reference to any "parent id" in the file or file_instance table ?
In other words, how the hierarchical structure is supposed to be "imported" from repository to Moodle ?
If the hierarchy is reserved to the course context, and not to the repository context, it seems difficult to allow students to access
to a complete directory, for example.

On the other hand, maybe it's only a question for the "local" repository type, and not to the "generic" repository API ?
[[User:Allegre Guillaume|Allegre Guillaume]] 16:43, 5 March 2008 (CST)

[[User:Martin Dougiamas|Martin Dougiamas]] 12:58, 15 March 2008 (CDT): basically I was thinking we just store a full local path for each file instead of hierarchies. It wasn't in the db schema though: I've just added it. Thanks!

As for allowing access to a whole directory, that's something I've not thought about - thanks! I agree we need to support something like that in the interface. Hmm ..

== Editing Repository Files / Version Control ? ==

How do you imagine to handle the "editing file" problem ?
I can see several solutions :
# the simplest way : write access to a file really allows to edit (re-upload) the file, each instance being modified
# the "cheap copy" way : optionally, the modification is applied only to new file_instances (or those for which the teacher forces to). Here you have to handle two (then maybe more) revisions of this file.
This triggers the file revisions (or version control) question.

A related question is about versionned files :
should it depend only upon the repository layer (for example, a plugin could implement a SVN "repository") ?
Or should Moodle be aware of the file "revision number" ?
[[User:Allegre Guillaume|Allegre Guillaume]] 17:00, 5 March 2008 (CST)

[[User:Martin Dougiamas|Martin Dougiamas]] 13:08, 15 March 2008 (CDT): I don't think we should start getting into such things, version and editing is the job of the dedicated external repository system and people should use that interface.

What we do have in Moodle is the file->updates field. This specifies when to get a fresh copy. It would be set when the user has specified they want Moodle to use the "latest version" of the file. And if the user specified a particular version in the repository interface then that is what gets copied (once) and the file->updates field is left as zero.

One scenario would be if someone wants to use version 1 in one course and version 2 in another, but since the version is in the URL to the original file (and thus a different remote path) they would be treated as two separate files in Moodle anyway.

Might be a small problem if they said "latest version, no update" in course 1 and then later on said "latest version, no update" in a second course. I guess that would re-download the latest version (which might have changed) and thus course 1 would have an unexpected update. We could solve this by alerting the user and giving them a choice, I suppose.

== Replacing Moodle's File System ==

The API as specified still uses the standard Moodle file system, which has its limitations while providing a simple file access method. But, shouldn't we also be considering completely (or partially) replacing the Moodle file system with the repository system? To that end, the file interface would be the same to users, but where the files are and how they are accessed would be up to which repository was being used. In this system, the standard Moodle file system would just be one of the available repositories. Then the API could support more robust access controls if available, or very few (as Moodle does now). This could allow for per-directory / per-file privilege granting, common file areas so that courses could access the same copy of a file (rather than copying it into the Moodle file area), etc.

The API could also support multiple repositories and allow choosing a file as a link rather than copying it.

Of course, this would also mean allowing write access to the repository area from Moodle, rather than leaving it as read-only. I know the plan was to do this through the [[Portfolio API]], but that really is limited to a user storage function and not a file management function. I think having an API defined to allow for full file management would be a better solution - even if not supported by all repositories.
[[User:Mike Churchward|Mike Churchward]] 12:54, 6 March 2008 (CST)

[[User:Martin Dougiamas|Martin Dougiamas]] 12:54, 15 March 2008 (CDT) :
Actually, Mike, the standard file system is NOT being retained at all. I've clarified this slightly in the docs. The course-centered structure for files is gone. All files ARE stored on disk but most of the info regarding their location and access is all governed by a table in the database (so the files could just as easily be in a remote database if you wished). Files used in multiple areas within Moodle will never be stored more than once in Moodle.

The idea of a read/write interface was how we started, but it's insanely complex once you try to handle backups (ie how do you make a complete backup suitable for giving to someone else?) and access control (how do you decide access depending on Moodle contexts), and we'll never do it as well as the original repository does it. Why should we duplicate the Hive interface (to use an example) in Moodle when Hive has a perfectly good one already, one that handles all the extra stuff like Copyright controls, workflow and so on?

That said, the current Repository plugin idea is very simple, so that if anyone really wanted to embed management into the "file picker" interface they totally could do it in the plugin.
---

==Windows network drives==
I've added this to the end of the list of repository types to be supported because its possibly the most useful one I can think of. Our school wants to make the transition to moodle, but getting the files on there is the biggest barrier and there is a lot of stuff sitting on our shared and personal folders which is time consuming to transfer. Integration is a big thing that management want to see, particularly the ability to bulk upload files. This may not be a repository as such because it may be that the best way is to copy the file from the shared folder into the repository rather than where it is so it can be moved/deleted accidentally, but easy access is vital in making the process of uploading a file possible. It would also make Moodle a killer app in that it could make our network drives available from home through a secure web interface.

I've linked to Guy Thomas' [http://moodle.org/mod/data/view.php?d=13&rid=991 Windows Share Web Client block] as it is a good start, but sadly only works on Linux. [[User:Matt Gibson|Matt Gibson]] 03:43, 29 April 2008 (CDT)

Fantastic idea, let's call it the SMB plugin - [[User:Martin Dougiamas|Martin Dougiamas]] 21:25, 8 June 2008 (CDT)

==Bulk operations==
On a similar note, Don Hinkelman's new course format provides a great bulk-upload feature whereby a whole folder can be uploaded and added to the course as resources with the names of the files as titles, with just a couple of clicks. I know this is extending the repository idea a little, but to be honest, I think that one of the biggest weaknesses of Moodle's file handling right now is not being able to add an entire folder of files without manually going through each one and laboriously specifying location and title. To make any repository useful, I think three operations should be possible with one or two clicks:
* Add a whole folder/group of files to the repository at once
* The above operation, but additionally, have all of the folder/group added to a course and named automatically, all in one go.
* Find a group of files which are already in the repository and add them to a course all at once, with automatic naming as above.
Not sure if this is best put here or in the Developemt: File_API bit, but here seemed slightly better. [[User:Matt Gibson|Matt Gibson]] 03:43, 29 April 2008 (CDT)

This is probably not related to the file API at all. I'd see it as being a new item on the resource menu (Add multiple resources ...) with some sort of shift-click scenario. nice idea though. Can you file it as a tracker item? [[User:Martin Dougiamas|Martin Dougiamas]] 21:26, 8 June 2008 (CDT)

== Bulk and a new resource type from repository ==

Our school has several campuses and a distance learning unit with well organized and big course resource trees. The repository module could be enormously useful for us.

I have looked at Moodle's IMS repository a bit, and like the way it is possible to put multiple resources into one access point. If the new repository could have some of the same possibilities, it would be marvellous. The drawback with the IMS is that it opens a new window with all the multiple resources. Instead, it would be OK to be able to share a whole lot of resources, or a whole "resource tree".

I also like the bulk function, to be able to parse a folder of say, html-files, and add it to the resource tree.

==Further notes==

* WebDAV --[[User:Helen Foster|Helen Foster]] 17:20, 9 June 2008 (CDT)

== "local repository name" ==

I think users will find the word local to be confusing. For the developer or administrator, local seems to refer to the Moodle server. But for the teacher or student, they will think that local refers to their own local files system. I would suggest just using the domain name for that server (like myMoodleSite.org) and list it as the first entry to avoid this confusion. [[User:Gary Anderson|Gary Anderson]] 02:40, 10 June 2008 (CDT)

== Credentials to third party systems ==

You might want to consider something like oauth - http://oauth.net - to manage credentials of third party sites, rather than asking the user for them. I know I sure wouldn't want to input my credentials for one system into another! [[User:Nigel McNie|Nigel McNie]] 07:08, 17 June 2008 (CDT)