Proposals/Outcomes portfolio

Outcomes portfolio setting and database tables

High level overview

• Create the 'Outcomes portfolio' option as institution setting so that it can be available for groups created in that institution
• Create database tables for outcome types and subjects to record necessary details such as short names and colour code classes where appropriate.

The colours are defined via classes in the stylesheet in the code, not on the interface.

Details

1. Create the 'Outcomes portfolio' option in the institution settings with rules as for portfolio completion and SmartEvidence, i.e. if somebody is in multiple institutions, they see it if at least one of their institutions has it turned on.
   • It can be used in conjunction with portfolio completion and SmartEvidence.
   • It has characteristics of the portfolio completion page (rather than SmartEvidence), i.e. it should be possible in the future to add further blocks to that special first page.
   • It will be the very first page if portfolio completion and / or SmartEvidence are selected as well.
   • Initially, it is only available on the group level (group owned collections), but be open to future plans to have it available on personal, institution, and site level as well
   • Add a new field 'outcomes' into the collection table
2. New database tables for 'Outcome category' (lang string 'Outcome category') and 'Outcome subject' (lang string 'Subject'). These are hard-coded / inserted into the DB for each institution. It is not possible (at this stage) to add or change them via the admin interface. The key value should be a number. The category is created to future proof the functionality for when different outcome portfolios are created that require different outcome types either within one institution or across different institutions.
   • 1 table for outcome categories (outcome_category): ID, outcome category title [up to 100 characters], institution ID; e.g. here the category would be 'Foundation' (in the future, this could be displayed in the admin interface, but currently is out of scope)
   • 1 table for outcome types (outcome_type): ID, outcome category ID as foreign key, title of the outcome type [up to 100 characters], abbreviation of the outcome type [up to 10 characters], outcome type background colour which refers to a class that is saved in here and defined in SCSS as a colour (background and border) in theme/raw/sass/components/_outcomes.scss where we will keep all the outcomes classes.
   • 1 table for subject categories: ID, subject category name [up to 100 characters], institution ID, e.g. here the category would be 'Subject' (in the future, this could be displayed in the admin interface, but currently is out of scope)
   • 1 table for subjects: ID, subject category ID as foreign key, title of the subject [up to 100 characters], abbreviation of the subject [up to 10 characters]

Group changes

High level overview

A new group type is created that defines the editing permissions on a portfolio and access to certain other pages within a portfolio.

Details

These are the changes in groups that can't be done via configuration.

Create the group type 'Outcomes' that becomes available when an institution uses 'Outcomes portfolio'. The following rules apply when that group type is selected:

• Based on the 'Controlled' group type, i.e. members can be added and aren't allowed to leave
• Only group admin can see the 'Add' button on the 'Portfolios' overview page. However, everybody will be able to edit regular portfolio pages.
• Nobody sees the 'Copy' button on the 'Portfolios' overview page.
• Nobody can use the 'Copy' button in the 'More options' menu to make a copy of the portfolio in their personal account at this stage because that functionality is out of scope.
• Only group admins can access the collection's 'Edit' and 'Manage outcomes' screens, but everybody can edit regular portfolio pages.
• Only group admins and group tutors can change the sharing permissions for a portfolio either directly on a page or via the 'Portfolios' overview page.
• Only allow group admins and group tutors to edit the group homepage.
• Per default, all collections created in a group with the type 'Outcomes' have 'Outcome portfolio' selected automatically in the collection settings.
• Group admins and group tutors can delete an entire portfolio or individual pages within it, but regular group members can't.
• Group members cannot change the activity information or remove the associated block from the page.
• Group tutors and admins can change the activity information but cannot remove the block itself from the page as it is placed there automatically.
• Group members cannot remove a checkpoint block from their page once it has been placed there, but they can remove evidence from the checkpoint. Group tutors and admins can remove checkpoints.
• 'Prevent removing of blocks' is automatically turned on to prevent group members from accidentally removing content blocks from the page. This setting can be changed though by anybody either temporarily or for longer. Out of scope: Tie the switch in with a particular set of roles that should be allowed to change the setting.
• The outcomes portfolio is not to be locked as it is more or less a rolling document. → Nothing to develop here as that is the default.
• Hide 'Group homepage' in the block 'Group portfolios'.
• Hide forums (via group_menu_items() function in interaction/forum/lib.php)
• Hide plans (via group_tabs() function in artefact/plans/lib.php)

Defaults for group settings on the group creation screen are defined in the Administration menu → Groups → Default group settings instead of hard-coding them so that the group type can be used more flexibly if needed. 'Hide' means that the functionality is also not available when you know the URL.

Why is a group used?

• Both learners and staff can edit portfolios collaboratively. Permissions don't need to be changed as they would if we were to create portfolios in the personal portfolio area.
• Site admin can create groups in bulk via CSV and add group members via CSV, including their roles in bulk, which makes the creation of the groups and updating the group membership efficient without needing to enter every single group.
• Groups can have three roles: member, tutor, and administrator, which we can use to allow certain functionalities for the three different groups of people that need access to an outcome portfolio.
• Basic group settings can be predefined and group homepage set up as a template.
• All outcome portfolios for a group member can be held in the same group to easily see what the group member had been working on before, i.e. there is one group per learner and their support staff.

What is displayed on the group homepage can be set in the template in the site administration.

Defaults for group settings on the group creation screen are defined in the Administration menu → Groups → Default group settings instead of hard-coding them so that the group type can be used more flexibly if needed.

'Outcomes' infrastructure in the group collection

High level overview

• Create the 'Manage outcomes' page infrastructure ('Manage outcomes – group admin only' mock-up)
• Create the outcomes overview page and infrastructure
• Allow for the direct editing of fields
• Allow for the clicking of icons to complete outcomes and activities
• Create new pages (activities) from this page and set them up
• Pull in activity information from the individual pages
• Respect permissions for the different types of group members and who can edit or only see what

Details

Mock-up reference: 'Set up the outcomes collection - group admin only'

Who? As a group admin...

What? I want to be able to set up an outcomes collection...

Why? So that group tutors or I can add activities and prepare everything for the group member to get started.

The collection is set up in a group for a particular group member by a group admin. The numbered list refers to the bullets in the mock-up 'Set up the outcomes collection - group admin only'.

1. [no change] Collection name: Title of the outcomes portfolio. You can choose that freely, but might want to establish a convention to differentiate between the different plans that a group member may have.
2. Per default, the option 'Outcomes portfolio' is set to 'Yes'. This is done automatically when the institution selected to work with outcomes portfolios (see section 'Outcomes portfolio setting and database tables').
3. Clicking the 'Continue' button takes you to a new page where you can manage the outcomes.

Additional changes (not pictured):

1. Option 'Manage outcomes' is accessible from the collection settings screen and also on the 'Portfolios' overview page when clicking the 'More options' icon on a collection for group admins only.
2. Option 'Manage pages' is not available from the collection settings screen or via the 'More options' icon on a collection on the 'Portfolios' overview page to avoid pages from being added to or removed from the collection outside of the outcomes framework. It can also not be reached by URL.

Out of scope: Be able to add regular portfolio pages to the collection and not only activity pages.

Mock-up reference: 'Manage outcomes - group admin only'

Who? As a group admin...

What? I want to enter the outcomes for a group member's outcomes portfolio...

Why? To prepare the collaboration space for group tutors and group members.

• The Mahara collection creation process will be used.
• Outcomes are set up and modified, but interactions primarily performed by group tutors are done in 'Display' mode.
• In phase 1, we don't anticipate being able to move outcomes around but would expect that they are set up in order.
• Outcomes can be deleted.

The numbered list refers to the bullets in the mock-up 'Manage outcomes - group admin only'. Group tutors and group members do not have access to this page.

Notes:

• One outcome field set is set up per default as that is the minimum that is required.
• collection_outcome table: ID, collection ID, short title, full title, outcome type ID, support (boolean), progress (text), completed (boolean), section that shows the ID from the 'collection_view' table of the 'section' there. This 'section' is needed in here in case we delete an outcome or in future want to re-order outcomes.
• Collection_view table: create new column 'section' that in this case states the outcome ID to which the page belongs (section ID is the ID of the ID from the collection_outcome table.
• Each outcome is its own Pieform and has its own 'Save' button that is not displayed though.

1. Outcomes are auto numbered to distinguish them. When an outcome is deleted, the number is automatically updated (on page load).
2. Short title: Short title for the outcome as that becomes the page title. Suggested: 70 character limit. This field is mandatory.
3. Full title: The full name of the outcome text. Suggested: 255 character limit.

4. Outcome type: Select list with the abbreviation of the outcome and the colour along with the full title of the type (see section 'Outcomes portfolio setting and database tables'). This can be done with a in the select option.

   If no outcome type is selected, don't display the field on the outcomes overview page.

5. Link to 'Add an outcome' (not a button).

6. Click the 'Delete' button to delete the outcome.

   • The 'Delete' button tooltip or aria text takes the short title of the outcome to know which outcome is to be deleted, e.g. Delete outcome 'Short title of the outcome'.
   • There is a confirmation modal as safeguard on deletion.
   • When an outcome has activities associatedd with it, the outcome can't be deleted because the target pages would need to be deleted first. This is stated in the modal that comes up when attempting to delete an outcome.
   • When an outcome is deleted, AJAX comes into play that updates the number for 'Outcome 1', 'Outcome 2' etc but that number is actually not saved to the database as it's not important.
   • We need to make sure that we can't delete the first outcome because there must be at least one outcome in the collection or it's not possible to add pages.

7. Click the 'Save' button to be taken to the display page of the outcomes overview page. clicking that button submits all Pieforms at once and takes you to the display page of the outcomes overview page. If you have unsaved changes, a modal comes up telling you that.

Mock-up reference: 'Outcomes overview page in progress – group tutors and group admin'

Who? As a group tutor or group admin...

What? I want to see all outcomes and activities in one place...

Why? So that I have a quick overview of all the outcomes and activities for this group member to quickly note at which outcome we left off and which activity is next up.

Note: It's a pseudo page like portfolio completion.

The numbered list refers to the bullets in the mock-up 'Outcomes overview page in progress – group tutors and group admin'.

1. [no change] Title of the outcomes portfolio that was added when the outcomes collection was created. It can be changed at any time.
2. Title of this page: Ideally, this is fixed for everybody like we do for SmartEvidence and portfolio completion. → Outcomes
3. 'Configure' button: Allows you to add and update outcomes on the collection settings screen for outcomes (see mock-up 'Manage outcomes - group admin only'). Only group admins see that. Group tutors and group members don't.
4. Overall completion of outcomes: Progress bar across all currently available outcomes (similar to the progress bar on the portfolio completion page, just not for individual pages but for the outcomes).
5. Each outcome is collapsed so that only the short title of the outcome is displayed that concisely states what it is about. Our normal collapsable panel rules apply in terms of styling.

6. Group admins and group tutors can click an icon to mark the outcome as completed. A tooltip states that it's been completed along with the short title of the outcome. This icon with its hover state is the same as for the 'Sign-off' block for consistency.

   There are only two states: Incomplete and completed. The icon is ticked manually as it is not guaranteed that all activities will already have been added. There is a confirmation modal to confirm the ticking. It can be set to 'Incomplete' again though by the group tutor or group admin if more activities need to be added. No need to display who set the outcome to completed, but log the who and when in the database.

   • Tooltip for incompleted: Click to mark outcome 'Short title of the outcome' as completed.
   • Tooltip for completed: Outcome 'Short title of the outcome' has been completed. Click to reset.
   • Confirmation modal to confirm the ticking. It can be set to 'Incomplete' again though if more targets need to be added, again with a confirmation modal.
   • No need to display who set the outcome to completed, but log the who and when in the database.
   • Add a span around the icon so that it can be targeted and doesn't uncollapse it. It needs an ID as well so that we can map it to the outcome.

7. Click the outcome to expand the panel and see the details for that outcome.

8. A circle icon displays that the outcome is not yet completed. That is the same as in the 'Sign-off' block. A tooltip will also state that and includes the short title of the outcome. To mark the outcome as completed, click the icon and a modal is displayed to confirm this. The tickbox icon can be clicked to reset the completion if anything needs to be added. Only the latest change to 'Yes' will be recorded in the database.

   A group member sees a bar icon because they are not able to perform an action. See mock-up 'Outcomes overview page in progress – group member'

9. The full outcome text from the 'Full title' of the outcome when it was set up.

10. The outcome type is displayed with its short code and the background colour that is defined in the stylesheet. A help icon states all available outcome types in their long form.

    If no outcome type was selected, don't display the field.

11. Activities: Table that shows all the activities, i.e. the separate pages. These are Mahara portfolio pages for which a new type is created (see section 'Activity page infrastructure').

    Activity titles are added automatically when a new activity is added to this outcome as page and the viewer returns to this overview page. If someone places an activity page before the last page of a different outcome, it doesn't result in it being associated with that outcome. It will still be linked to the outcome in which it was created.

12. The link to the activity takes you to the page of the activity for easy access (similar to portfolio completion page).

    • While the activity has not yet been completed, everyone goes into 'Edit' mode of the page. This is to ensure that group members, group tutors, and group admins don't have an extra click to update checkpoints.
    • Once the activity has been completed, everyone goes to the 'Display' mode of the page.

    Out of scope: If someone changes the order of the outcomes, it also changes the order in which they are displayed on this page.

13. 'Sign-off', i.e. status of the activity: That is pulled through from the activity page and can be updated directly here (like on 'Portfolio completion' for sign-off as it is the sign-off functionality). No additional info is provided here, i.e. who and when they signed off. That is accessible on the activity page. A tooltip mentions though the state of the activity.

14. 'Add activity':

    • Clicking the button sets up a new page in this collection where you can fill in all the activity information.
    • Need to ensure that the link can't be manipulated so that you can't create the page in somebody else's collection.
    • On returning to the outcomes overview page, you will see the new activity added.

15. Support taking place: This is a Yes/No switch whose status is saved immediately. No tracking of previous status changes would take place. Once the outcome is marked as 'Completed', the status can't be changed any more and only the word 'Yes' (or 'No') is displayed instead of the switch.

    No need to display who changed the status, but log the who and when in the database.

16. Progress:

    • It's a plain text field with 3 rows shown, but could be expanded.
    • Text is saved when the 'Save' button is pressed.
    • We'll need to ensure that they can't navigate away before the text has been saved, i.e. a browser modal is to be displayed when there are unsaved changes.
    • Once the outcome is marked as 'Completed', the text can't be changed any more. Display who made the last change and when once the outcome has been completed.

All pages are added in order in which they are set up via the outcomes overview page into the collection. Once the pages are in, there is no distinction or separation between them to which outcome they belong. The link is made through the text on the activity page itself. The main navigation to the pages is anticipated to be via the outcomes overview page.

The collection navigation at the top of the collection displays the pages in order as they appear on this overview page if all outcomes were uncollapsed, no matter their outcome. Out of scope: Adding the outcome as heading into the drop-down menu.

Mock-up reference: 'Outcomes overview page completed – group tutor and group admin'

Who? As group tutor and group admin...

What? I want to track outcomes and activitys on one page...

Why? So I can see a quick overview to know what to work on with the group member.

The numbered list refers to the bullets in the mock-up 'Outcomes overview page completed – group tutor and group admin'.

1. Only group admins see the 'Configure' button, but group tutors and group admins can mark outcomes as completed.
2. Support taking place: No switch as the info has been locked in once the outcome was set to 'Completed'.
3. Progress: No editable text as the info has been locked in once the outcome was set to 'Completed'.. The name and time of the person who last edited the field is displayed.

The button '+ Add activity' is not available any more.

If the outcome is reset to 'Not completed', then 'Support taking place' and 'Progress' are unlocked and additional activity pages can be added.

Mock-up reference: 'Outcomes overview page in progress – group member'

Who? As a group member...

What? I want to see the outcomes overview page...

Why? So I know what I will be working on.

The numbered list refers to the bullets in the mock-up 'Outcomes overview page in progress – group member'.

1. Group member cannot see the configuration button nor will they be able to give access to the collection.
2. Since they cannot mark an outcome (or activity) as completed, the line icon represents that there is generally something that could be done, but they are not allowed to. This is accompanied by a tooltip, similarly to the 'Sign-off' functionality.
3. Support taking place: Group member only see the information displayed, but doesn't have a switch available.
4. Progress: The text is displayed without the potential to edit it. The name of the group tutor or group admin who wrote the text is displayed along with the time when they edited it.

Mock-up reference: 'Outcomes overview page completed - group member'

Who? As a group member...

What? I want to see my progress across all outcomes...

Why? So that I can be proud of my work and having finished my outcome.

The text refers to 'Outcomes overview page completed – group member'.

The only big difference to what group tutors and group admins see is that the group member can't mark an outcome as completed.

Activity page infrastructure

High level overview

• Add activity information to the page settings → Create a new portfolio page type
• Pull in information from tables and people to auto-populate information
• Display activity information set up on the page settings page
• Update certain information directly while editing or viewing the activity page
• Dealing with 'signing off' / completing activities

Details

Mock-up reference: 'Set up activity page – group tutor and group admin'

Who? As group tutor or group admin...

What? I want to set up activites for the group member...

Why? So that all admin work is collected in one place and then available when I work with the group member on a particular activity.

The numbered list refers to the bullets in the mock-up 'Set up activity page – group tutors and group admin'. This page is only accessible to group tutors and group admins. Students cannot get to it.

1. [no change] Page title: It's a short title of the activity to avoid that the heading of a page is longer than one line and therefore fits better into a navigation menu. This title is pulled into the outcomes overview page automatically. Mandatory field.
2. Activity information panel: automatically uncollapsed as information needs to be entered.
3. Activity description: Long title of the activity. Mandatory field.
4. Subject: Select list with hard-coded items (phase 1).
5. Responsible staff: Select list comprised of all group tutors and group admins from this group. The person filling in the form is automatically displayed as default choice.
6. Start date: Date picker.
7. End date: Date picker. Check that the end date is greater or equal to the start date.

8. Levels of achievement: Three single-line text entry fields. The fourth level is predefined.

   • Icons are assigned automatically.
   • Level 1 is the highest achievement and level 4 the lowest.
   • Suggested icons: Font Awesome number corresponding to the level with a circle around it in primary theme link colour but with a new variable set up if a different colour should be used. This will need to be achieved with stacked icons, e.g. icon-1 and icon-circle.
   • New table 'view_activity_achievement_levels' with ID, view_activity_ID (i.e. the view ID), priority column (1-4), value and level 4 always being the same (via hidden value).

9. Clicking 'Save' takes you to the 'Edit' screen of the activity page.

Notes:

• The page buttons have changed slightly in Mahara 22.10 and thus will be used instead of the ones pictured on the mock-up.
• This settings page is only available to group tutors and group admins.
• The rest of the page settings stay as they are in the 'Advanced' panel.
• 'Prevent removing of blocks' in the 'Advanced' panel is automatically set to 'Yes' (see section 'Group changes') but can be changed to 'No'.

Mock-up reference: 'Edit activity page – group tutor and group admin'

Who? As group tutor or group admin...

What? I want to add content to the activity page...

Why? To assist the learner with their evidence collection and mark checkpoints as completed to illustrate progress.

The numbered list refers to the bullets in the mock-up 'Edit activity page – group tutor and group admin'. This page is accessible to group tutors, group admins, and learners.

1. 'Settings' button: Available to group tutor and group admins to change information about the activity. It's not accessible to regular group members.

2. Activity information:

   • is displayed at the top of the page and cannot be moved.
   • is displayed collapsed so that you only see the long-form activity, outcomes, outcome type, and whether the outcome has been achieved or not in the panel header.
   • is a full-page width block. → Change the default width of blocks in Mahara when they are put on a page into full-page width blocks

3. Activity description: Long 'title' of the activity.

4. Outcome: Short title of the outcome to which this activity belongs.
5. Outcome type: Pulled from the outcome, i.e. short name with the predefined background colour.

6. Achieved: Switch to decide whether an outcome has been achieved or not. This can always be changed. A modal is displayed to confirm the choice. Only the latest change to 'Yes' will be recorded in the database.

   • This uses the 'Sign-off' block functionality as basis and makes the following change:
   • Change the 'Sign-off' block to not be a block any more but make it a setting in the 'Advanced' panel on the page settings screen so that the info is always displayed at the top right. → Sign-off/Verify gets a new template so that we can move it elsewhere if needed and the activity template includes the sign-off template which then is included in a page.
   • If a page is of the 'Activity' type, automatically set 'Verified' to 'No' in the settings for the 'Sign-off'.

7. Responsible staff: Pulled from the activity setup.

8. Subject: Pulled from the activity setup.
9. Time frame: Start and end date from the activity setup combined.
10. Strategies and support: Editable field for group tutor and group admin. Similar to the 'Progress' field on 'Outcomes' (see section 'Outcomes overview page in progress – group tutors and group admin').
11. Resources: Editable field for group tutor and group admins. Similar to the 'Progress' field on 'Outcomes'.
12. Learner support: Editable field for group tutor and group admins. Similar to the 'Progress' field on 'Outcomes'.
13. [no change] Click the 'Add block' button at the top right to add a checkpoint block or any other block onto the page below the activity information.

Numbered items 14-20 are done as part of the 'Checkpoint block infrastructure' (see that section for details).

Mock-up reference: 'View activity page, not achieved – group tutor and group admin'

Who? As group tutor and group admin...

What? I want to view a page in 'Display' mode...

Why? So that I can see the information how it is presented without all editing controls.

The numbered list refers to the bullets in the mock-up 'View activity page not achieved – group tutor and group admin'.

1. Strategies and support, resources, and learner support can also be changed when viewing the page. Content is saved upon clicking the respective 'Save' button. Browser modal to appear if content hasn't been saved yet before navigating away from the page.
2. Switch can be flipped to indicate the achievement status. A confirmation modal comes up when status is changed. It can be changed back to 'No'. Record in the database only who changed the status when but don't display it on screen.
3. Set the achievement level with the drop-down menu. The help icon displays the long-form text for the levels. The menu itself only displays 'Level 1', 'Level 2', 'Level 3', and 'Level 4'.

Mock-up reference: 'View activity page, achieved – group tutor and group admin'

Who? As group tutor and group admin...

What? I want to be able to mark completed activities as achieved...

Why? So that I don't have to go into 'Edit' mode to do that.

The numbered list refers to the bullets in the mock-up 'View activity page achieved– group tutor and group admin'.

1. Strategies and support, resources, and learner support are locked in and can't be edited any more. The name of the person who edited the field last is displayed along with the date.
2. Switch can be flipped to indicate the achievement status. A confirmation modal comes up when status is changed. It can be changed back. Record in the database only who changed the status when.
3. Comments can still be added to checkpoints.

Mock-up reference: 'Edit activity page – group member'

Who? As a group member...

What? I want to see the requirements for a particular activity and add my learning evidence to the page...

Why? So that I can demonstrate that I've achieved a checkpoint and ultimately the activity.

The numbered list refers to the bullets in the mock-up 'Edit activity page – group member'. This page is accessible to group tutors, group admins, and group members.

1. Group members don't see all the buttons like group tutors and group admin do. They can't access the page settings nor can they give access to the portfolio.
2. Activity information is displayed at the top of the page below the page instructions and cannot be moved. It is displayed collapsed so that you only see the long-form activity, outcomes, outcome type, and whether the activity has been achieved or not.
3. Achieved: Group members can't flip the switch and thus only see the line icon.
4. [no change] Group members can add any number of blocks onto the page. They won't be able to delete them unless group tutors or group admins allow that on the page settings (that's the 'Prevent removing of blocks' functionality).

Done as part of the checkpoint block infrastructure:

1. Group members cannot delete any comments. They can still edit a comment for 10 minutes after they made it or until someone posts another comments, whichever occurs first.

Mock-up reference: 'View activity page not achieved – group member' and 'View activity page achieved – group member'

Who? As a group member...

What? I want to view a page in 'Display' mode...

Why? So that I can see the information how it is presented without all editing controls.

This page is very similar to 'View activity page, achieved – group tutor and group admin', with the difference that group members see a line instead of a drop-down menu when a checkpoint or an activity hasn't been achieved yet.

Comments on checkpoints:

• Can be made no matter whether the checkpoint has been achieved or not.
• Group members cannot delete any comments. They can still edit a comment for 10 minutes after they made it or until someone posts another comments, whichever occurs first.

Checkpoint block infrastructure

High level overview

• Create a new block type
• Pull information through from the activity page setup for levels of achievement
• Deal with achievements and rules of what shall happen once a checkpoint has been achieved

• Resembles the peer assessment block

  • No restriction though who can add comments
  • No draft option
  • No instructions

• Page comments are still kept separate and could still be used.

Details

Mock-up reference: 'Edit activity page – group tutor and group admin'

Who? As group tutor or group admin...

What? I want to add content to the activity page...

Why? To assist the learner with their evidence collection and mark checkpoints as completed to illustrate progress.

The numbered list refers to the bullets in the mock-up 'Edit activity page – group tutor and group admin'. This page is accessible to group tutors, group admins, and learners.

Items 1-13 are part of the 'Activity page infrastructure' (see section there for details). Here are only the items listed that pertain to the 'Checkpoint' block, which is a new block type.

1. Checkpoint block is added in full width. When a checkpoint block is deleted by a group tutor or group admin, there is logic that renames all subsequent blocks.
2. Click 'Add comment' to add a comment to the checkpoint. Comments are displayed in reverse chronological order.
3. When a comment was made, the profile picture, the name, the time the comment was made and the comment itself are displayed. Comments can be saved as draft and then published, similarly to the 'Peer assessment'. Comments can be added no matter whether a checkpoint has been achieved or not.
4. [no change] Additional blocks can be pulled onto the page.
5. Set the achievement level with the drop-down menu. The help icon displays the long-form text for the levels. The menu itself only displays 'Level 1', 'Level 2', 'Level 3', and 'Level 4'.
6. Once the level has been set, a number icon represents the achievement level and below it is a help icon that contains the name of the person who set the level and when they did it. It also contains the long description of the achieved level.
7. Group tutors and group admins can delete comments. Editing of comments is possible for 10 minutes after posting or until somebody adds a new comment, whichever comes first. Group members cannot delete comments.

Note: It is possible to add new comments no matter whether an achievement level has been set or not.

• New block type but block config is just the normal things that we record for blocks: block type, view, config data, dimensions
• new table: ID, blockID, achievement level ID, userID, ctime
• New table to record checkpoint results for future proofing in case things do need to be reported over it
• Fetches achievement levels from the view_activity_achievement_level table
• Levels: Lang string 'Level' added automatically to the priority number of the level
• Actual name of the levels is in the help icon
• New artefact table similar to peer assessment table