Search engine adapters - Revision history

Dmonllao at 08:26, 8 March 2016

2016-03-08T08:26:32Z

← Older revision		Revision as of 08:26, 8 March 2016
Line 1:		Line 1:
			{{obsolete}}

	''Update 2011.10.23: for Moodle 2.3 see [[Global Search]].''		''Update 2011.10.23: for Moodle 2.3 see [[Global Search]].''

Deraadt: Adding to a top level category

2011-11-04T08:40:39Z

Adding to a top level category

← Older revision		Revision as of 08:40, 4 November 2011
Line 267:		Line 267:

	== Physical Document Adapters ==		== Physical Document Adapters ==

			[[Category:Plugins]]

Tmuras at 13:07, 23 October 2011

2011-10-23T13:07:11Z

← Older revision		Revision as of 13:07, 23 October 2011
Line 1:		Line 1:
	Update 2011.10.23: for Moodle 2.3 see [[Global Search]].		''Update 2011.10.23: for Moodle 2.3 see [[Global Search]].''

	The Global Search Engine of Moodle, available as experimental feature till the Moodle 1.9 release, allows plugin new document types for being searched and indexed by the Lucene indexer.		The Global Search Engine of Moodle, available as experimental feature till the Moodle 1.9 release, allows plugin new document types for being searched and indexed by the Lucene indexer.

Tmuras at 13:06, 23 October 2011

2011-10-23T13:06:59Z

← Older revision		Revision as of 13:06, 23 October 2011
Line 1:		Line 1:
			Update 2011.10.23: for Moodle 2.3 see [[Global Search]].

	The Global Search Engine of Moodle, available as experimental feature till the Moodle 1.9 release, allows plugin new document types for being searched and indexed by the Lucene indexer.		The Global Search Engine of Moodle, available as experimental feature till the Moodle 1.9 release, allows plugin new document types for being searched and indexed by the Lucene indexer.

Vf at 22:48, 29 November 2007

2007-11-29T22:48:03Z

← Older revision		Revision as of 22:48, 29 November 2007
Line 1:		Line 1:
	The ~~global search engine~~ of Moodle, available as experimental feature till the Moodle 1.9 release, allows plugin new document types for being searched and indexed by the Lucene indexer.		The Global Search Engine of Moodle, available as experimental feature till the Moodle 1.9 release, allows plugin new document types for being searched and indexed by the Lucene indexer.

	Each module or block should have an adapter written to wrap the plugin's internal data model to a searchable document. The actual implementation allows a module to provide the search engine with a set of virtual documents. The search engine will index the text content of these documents, recording sufficiant data to access back the exact context in which it was appearing (i.e, access URL, course context, etc.).		Each module or block should have an adapter written to wrap the plugin's internal data model to a searchable document. The actual implementation allows a module to provide the search engine with a set of virtual documents. The search engine will index the text content of these documents, recording sufficiant data to access back the exact context in which it was appearing (i.e, access URL, course context, etc.).

Vf: /* Checking Access Back To The Content */

2007-11-18T14:46:43Z

Checking Access Back To The Content

← Older revision		Revision as of 14:46, 18 November 2007
Line 198:		Line 198:

	== Checking Access Back To The Content ==		== Checking Access Back To The Content ==

			When searching, the Zend Lucene engine dig into its own word index organization, and then retrieves a set of matching "Documents". You will want now to filter out those documents that the user who activated the search engine DO NOT have permission to see.

			The search results function calls back an access checker for each results, depending on the known document type. This is the :

			<pre>
			function <module>_check_text_access($path, $itemtype, $this_id, $user, $group_id, $context_id){ ... }
			</pre>

			function, that will have to implement the access policy, depending on the plugin's contextual logic. The function traps any access revocation condition (and than will return false). In cas no trap was triggered, it will return true. The admin role bypasses this check call and will access all documents.

			Here comes a standard synopsys for that implementation :

			<pre>
			function <module>_check_text_access($path, $itemtype, $this_id, $user, $group_id, $context_id){
			global $CFG, $USER;

			// may include some plugins libs
			include_once("{$CFG->dirroot}/{$path}/lib.php");

			... get the course module and content record ...

			// this part is very standard for modules, reconsider it for blocks
			// or other stuff
			$context = get_record('context', 'id', $context_id);
			$cm = get_record('course_modules', 'id', $context->instanceid);
			if (!$cm->visible and !has_capability('moodle/course:viewhiddenactivities', $context)){
			// nice for debugging undued visibility or non visibility
			if (!empty($CFG->search_access_debug))
			echo "search reject : <reject cause> ";
			return false;
			}

			// user check : entries should not be owner private or we are that user

			// group check : entries should be in accessible groups

			// date checks : we are in an open window

			return true;
			} //<module>_check_text_access
			</pre>

			'''Note : Debugging access policy'''

			Use the above construction for any ''false'' you will return :

			<pre>
			if (!empty($CFG->search_access_debug)){
			echo "search reject : <reject cause> ";
			return false;

			</pre>

			For debugging, add a simple key in {$CFG->prefix}_config table :

			<pre>
			INSERT INTO {$CFG->prefix}_config VALUES ('search_access_debug', 1);
			</pre>

			Delete it for normal operations :

			<pre>
			DELETE FROM {$CFG->prefix}_config WHERE name = 'search_access_debug';
			</pre>

	== Physical Document Adapters ==		== Physical Document Adapters ==

Vf: /* Updating The index Database */

2007-11-18T14:30:21Z

Updating The index Database

← Older revision		Revision as of 14:30, 18 November 2007
Line 171:		Line 171:

	$coursemodule = get_field('modules', 'id', 'name', '<module>');		$coursemodule = get_field('modules', 'id', 'name', '<module>');
	$cm = get_record('course_modules', 'course', $<module_obj>->course, 'module', $coursemodule, 'instance', $<module_obj>->id);		$cm = get_record('course_modules', 'course', $<module_obj>->course,
			'module', $coursemodule, 'instance', $<module_obj>->id);
	if ($cm){		if ($cm){
	$context = get_context_instance(CONTEXT_MODULE, $cm->id);		$context = get_context_instance(CONTEXT_MODULE, $cm->id);
	... preparing some data eventually ...		... preparing some data eventually ...
	return new <ModuleItem>SearchDocument(get_object_vars($<content_obj>), $<module_obj>->id, $<module_obj>->course, $itemtype, $context->id);		return new <ModuleItem>SearchDocument(get_object_vars($<content_obj>),
			$<module_obj>->id, $<module_obj>->course, $itemtype, $context->id);
	}		}
	return null;		return null;
Line 182:		Line 184:

	Note : we need use get_object_vars() as historical implementation uses a hash in constructors rather than an object.		Note : we need use get_object_vars() as historical implementation uses a hash in constructors rather than an object.

			For deletion, you will have to reproduce a callback which remains from an old unexplained implementation :

			<pre>
			function <module>_delete($info, $itemtype) {
			$object->id = $info;
			$object->itemtype = $itemtype;
			return $object;
			} // <module>_delete
			</pre>

			Just rewrite it AS IS, nothing to think about here.

	== Checking Access Back To The Content ==		== Checking Access Back To The Content ==

	== Physical Document Adapters ==		== Physical Document Adapters ==

Vf: /* Updating The index Database */

2007-11-18T14:27:14Z

Updating The index Database

← Older revision		Revision as of 14:27, 18 November 2007
Line 127:		Line 127:
	* drop indexes on deleted resources and contents		* drop indexes on deleted resources and contents

	An API ~~call back~~ tells each of these three actions where the items to consider are in the Moodle database. This callback SHOULD return an array of arrays of strings, each containing the following fieldset :		An API callback tells each of these three actions where the items to consider are in the Moodle database. This callback SHOULD return an array of arrays of strings, each containing the following fieldset :
	* primary id fieldname,		* primary id fieldname,
	* table name,		* table name,

Vf: /* Making The Backaccess Link */

2007-11-18T14:26:38Z

Making The Backaccess Link

@@ Line 117: / Line 117: @@
 Contextual params are usually ids of course module, or internal entities depending on the module construction, modal values...
 == Checking Access Back To The Content ==
 == Physical Document Adapters ==

Vf: /* Providing The indexer Documents From The Module */

2007-11-18T14:04:42Z

Providing The indexer Documents From The Module

@@ Line 103: / Line 103: @@
+}
 </pre>
 == Checking Access Back To The Content ==
 == Physical Document Adapters ==