View source for Proposals/Metadata for views and artefacts

This proposal will allow site administrators to allow users to add more metadata to their views and artefacts.

<div id="section_1">

===1- New metadata fields to be defined by site administrators===

In order to give users the ability to enter more metadata on their views and artefacts, there will be a way to define new fields at the site level.

For each new field, the following attributes can be set:

* full name
* unique short name (only lowercase letters from A to Z are allowed, not spaces or punctuation)
* field type (free text, single select, multi-select)
* list of allowed values (for the select box field types) separated by semi-colons
* default value
* xml tag name (when embedded into a [[Developer Area/Specifications in Development/Sitemaps and extra metadata|sitemap]]) to be prefixed by the <code>mahara</code> namespace
* optional contextual help (HTML format) to be displayed when users click the help icon
* optional parent field and value (see next section)

At the database level, these new metadata fields will be stored in a way similar to the [http://docs.moodle.org/en/User_profile_fields Moodle custom user profile fields].

By default there will not be any fields defined there.

When an admin deletes a field, all metadata associated with it will disappear permanently.

</div><div id="section_2">

===2- Dependent fields===

A field may be set to be dependent on a particular value of another field. For example, selecting "English" as a "Learning Area" might unlock the "English Learning Area Strand" which would consist of a drop down with these values: "Reading" and "Writing", whereas selecting "The Arts" would unlock a different sub-field.

In the example above, both Learning Area Strand fields would have the same full name "Learning Area Strand" but they would have different unique short names. They would be tied to the same parent field ("Leaning Area") but different values ("English" and "The Arts" respectively).

The admin will define these optional relationships between fields by selecting from a drop-down list the parent field (if any). Then a new drop-down will appear and it will contain all of the values of the selected parent field. While the "parent ID" attribute is optional, the "parent value" is mandatory when the parent ID is not NULL.

Parent fields are restricted to single-select fields whereas the deepest dependent field (i.e. the leaf node) may be a single-select or multi-select field.

When providing meta-data values for their views and artefacts, users will only see dependent drop-downs appear when the right value is selected in the parent field.

</div><div id="section_3">

===3- Bulk creation/update of metadata fields===

There will be a way to automatically import a list of metadata fields so that site admins do not have to manually enter them. This import is for the definition of the fields. There will not be any way to populate views and artefacts with metadata values automatically.

The format of that file has yet to be determined, but it will most likely be XML-based.

When importing new definition files:

* new fields will be added to Mahara
* fields removed from the XML definition will remain in Mahara (they need to be manually removed by the admin)

As for fields that have been updated (i.e. same shortname):

* new xml tag names will be updated in Mahara (i.e. the old xml tag name overwritten with the new one)
* full name and default values will be updated in a similar way
* field types will also be updated in Mahara but it will impact values set by users:
** from single select to multiple select: existing values remain the same
** from single select box to freetext: existing selected values will be copied as text values
** from multi-select to freetext or single-select: existing values will be deleted
** from freetext to multi-select or single-select: existing values will be deleted
* if new allowed values are added, then it's an easy update of the field with no impact on existing values
* when allowed values are removed, then these values are removed from the places that used them
** in the case of single-select the value then becomes empty
** in the case of multi-select then the view/artefact loses one of its selected values

</div><div id="section_4">

===4- New fields in the view editor===

The form under "View | Edit title &amp; description" will now display all of the extra metadata fields defined at the site level and allow users to enter values for all of them.

All of these new fields will be '''optional''' given that Mahara needs the ability to create views quickly and automatically.

No validation will be performed on these text fields.

</div><div id="section_5">

===5- New fields for files===

The same optional metadata fields describe in the previous section will be available in the "File | edit" form. This will allow users to attach metadata to images and videos.

</div><div id="section_6">

===6- Advanced "Shared Pages" search page===

This will search through views that have been shared with the user but will allow users to apply filters based on the metadata that's defined on the site.

For example, if a site defines a list of "year level" for their school, then students will be able to select one of these levels for their views and then teachers will be able to search for "year 4" views in that new search page.

</div><div id="section_7">

===7- Create a "Shared Content" search page (requires Solr search plugin)===

The first part of this will be to replicate the "Shared Pages" search functionality but for artefacts instead of views.

The results page will display a list of artefacts and will link to their respective artefact landing pages. On these landing pages (which already exist), we will add links to the views (that the user has access to) which feature that artefact. This will provide users with the necessary context.

The second part will be to create an advanced search page for artefacts as described in the previous section.

</div>