project: Moodle
summary: Global Search 2
description: Global Search is currently removed from Moodle 2.2. As part of GSoC 13 project, Ive re-written Tomasz Murass Global Search implementation for the current 2.6 (dev) master branch. You may view the demo and play with it here: ( Username:search_admin Password: Search_admin1 ) The docs are here:

1.summary: Fix global search unit tests
description: Unit test shouldnt affect the production solr instance.
2.summary: Move from modules support to subsystems and all plugin types support
description: Not only modules are interested in indexing their contents in a search engine, we should allow all moodle components (subsystems and all plugin types) to define what contents they want to index. It is very important to document how components can add support for global search as each component will be interested in indexing different kind of components. module and module link fields in search/solr/solr_conf/N.x/schema.xml can be changed for component and componentlink in this issue search_get_iterators() and all functions gathering the current mod/PLUGIN/lib.php functions ( should be changed to read, for example, a mod/PLUGIN/db/search.php file It is out of the scope of this issue to add global search support to other components than modules and course, we will have time for this later, but it is important to define a format that can be used accross components.
3.summary: Define common search APIs
description: A generic search engine class should contain a set of methods to get the moodle components implementing global search, index documents in the search engine (current behaviour of search_get_iterators() for example)... A class to act as a "document" representation would also be needed as currently there are hardcoded references to solr in modules implementing support for global search. Even though these 2 classes should be abstract, not all their methods need to be abstract, I mean that for example there will be process that are common in all search engines (like gathering all iterators) but most of the processes should be defined by the specific search engine implementations; an example, the document class can define a abstract function __construct(); but the solr extension will be the responsible of extending it with a function __construct() $this->solrdocument = new SolrInputDocument(); same with search engine methods.
4.summary: Create a renderer for global search
description: All UI should be delegated to a renderer
5.summary: Improve global search performance
description: Indexing contents is an expensive task and even dangerous in big moodle sites, we should refine the performance as much as we can. This can be considered a blocker. Possible actions: Tune permission checkings Use get_fast_modinfo() Indexing database fields Specific configuration to run search/cron.php ( to avoid blocking other cron tasks. MUC
6.summary: Database activity does not store the last time activity instances were modified
description: It is strange because add_instance and update_instance set timemodified, but there is no timemodified field in the database. Probably copy & paste issue. We need mod_data db table to contain a timemodified for search.
7.summary: course filtering in global search
description: An important missing feature in global search is course filtering. All indexed documents have a courseid field, the field can be used to set the filter sent to the search engine. For what Ive heard autocomplete form field, is a drop down if there are less than X courses, otherwise you have to start typing, but this courses filter seems a good candidate to use it.
8.summary: Provide a way to retrieve all courses a user can potentially access.
description: We have enrol_get_my_courses to list the courses where I am enrolled but I couldnt find a straight forward way to get a list of courses that I can access, which would include my courses, courses with open guest access and courses with self enrol with no restrictions (or with satisfied restrictions) and other stuff I may miss. We can not base this is capability checks because until you are enrolled you can not have the capabilities the role assignment gives you so it would require us to deal with enrolment methods. This would be nice for global search as we are currently only allowing users to get indexed documents from courses where they are enrolled and the frontpage. If I get into a moodle site open to guests and I want to learn about bash Id like to search for bash and get all courses that I might be interested on. Tags may be a component that will also be benefited, marina would be used to retrieve course tag instances from all courses where a user can have access?
9.summary: Add "my courses" to global search
description: Users should be able to search their own courses by its name or description. Description edited according to the final solution, only my courses, a new issue will be created for all course related stuff to work on it as part of the GSOC project
10.summary: Revise admin settings/report for global search for improved usability
description: Currently each enabled search area is a an admin setting checkbox. This does not fit well with other big list of plugin/areas weve got in admin settings. In addition the report_search seems to be mostly about administration - and its a bit hidden and separate from the other search settings. Here is a mockup suggesting one idea: !dan-admin-tool.png!

Below is an instruction that describes a task, paired with an input that provides an epic with this format: 
"project": "Name of the project" 
"summary": "Summary of the epic user story" 
"description": "Description of the epic user story". Write a response that appropriately completes the request.### Instruction:
Break this epic user story into smaller tasks to help the developers understand the epic better, you can divide this epic into as much as you want depending on the complexity of the epic.
### Input:
project: Moodle
summary: Global Search 2
description: Global Search is currently removed from Moodle 2.2. As part of GSoC 13 project, Ive re-written Tomasz Murass Global Search implementation for the current 2.6 (dev) master branch. You may view the demo and play with it here: ( Username:search_admin Password: Search_admin1 ) The docs are here:

### Response:
1.summary: Fix global search unit tests
description: Unit test shouldnt affect the production solr instance.
2.summary: Move from modules support to subsystems and all plugin types support
description: Not only modules are interested in indexing their contents in a search engine, we should allow all moodle components (subsystems and all plugin types) to define what contents they want to index. It is very important to document how components can add support for global search as each component will be interested in indexing different kind of components. module and module link fields in search/solr/solr_conf/N.x/schema.xml can be changed for component and componentlink in this issue search_get_iterators() and all functions gathering the current mod/PLUGIN/lib.php functions ( should be changed to read, for example, a mod/PLUGIN/db/search.php file It is out of the scope of this issue to add global search support to other components than modules and course, we will have time for this later, but it is important to define a format that can be used accross components.
3.summary: Define common search APIs
description: A generic search engine class should contain a set of methods to get the moodle components implementing global search, index documents in the search engine (current behaviour of search_get_iterators() for example)... A class to act as a "document" representation would also be needed as currently there are hardcoded references to solr in modules implementing support for global search. Even though these 2 classes should be abstract, not all their methods need to be abstract, I mean that for example there will be process that are common in all search engines (like gathering all iterators) but most of the processes should be defined by the specific search engine implementations; an example, the document class can define a abstract function __construct(); but the solr extension will be the responsible of extending it with a function __construct() $this->solrdocument = new SolrInputDocument(); same with search engine methods.
4.summary: Create a renderer for global search
description: All UI should be delegated to a renderer
5.summary: Improve global search performance
description: Indexing contents is an expensive task and even dangerous in big moodle sites, we should refine the performance as much as we can. This can be considered a blocker. Possible actions: Tune permission checkings Use get_fast_modinfo() Indexing database fields Specific configuration to run search/cron.php ( to avoid blocking other cron tasks. MUC
6.summary: Database activity does not store the last time activity instances were modified
description: It is strange because add_instance and update_instance set timemodified, but there is no timemodified field in the database. Probably copy & paste issue. We need mod_data db table to contain a timemodified for search.
7.summary: course filtering in global search
description: An important missing feature in global search is course filtering. All indexed documents have a courseid field, the field can be used to set the filter sent to the search engine. For what Ive heard autocomplete form field, is a drop down if there are less than X courses, otherwise you have to start typing, but this courses filter seems a good candidate to use it.
8.summary: Provide a way to retrieve all courses a user can potentially access.
description: We have enrol_get_my_courses to list the courses where I am enrolled but I couldnt find a straight forward way to get a list of courses that I can access, which would include my courses, courses with open guest access and courses with self enrol with no restrictions (or with satisfied restrictions) and other stuff I may miss. We can not base this is capability checks because until you are enrolled you can not have the capabilities the role assignment gives you so it would require us to deal with enrolment methods. This would be nice for global search as we are currently only allowing users to get indexed documents from courses where they are enrolled and the frontpage. If I get into a moodle site open to guests and I want to learn about bash Id like to search for bash and get all courses that I might be interested on. Tags may be a component that will also be benefited, marina would be used to retrieve course tag instances from all courses where a user can have access?
9.summary: Add "my courses" to global search
description: Users should be able to search their own courses by its name or description. Description edited according to the final solution, only my courses, a new issue will be created for all course related stuff to work on it as part of the GSOC project
10.summary: Revise admin settings/report for global search for improved usability
description: Currently each enabled search area is a an admin setting checkbox. This does not fit well with other big list of plugin/areas weve got in admin settings. In addition the report_search seems to be mostly about administration - and its a bit hidden and separate from the other search settings. Here is a mockup suggesting one idea: !dan-admin-tool.png!
