Forums | Mahara Community

Support /
Smart Evidence Framework - saving an annotation does not save as evidence


James Pearce's profile picture
Posts: 12

15 May 2026, 21:18

We have noticed that a small number of claims for a Smart Evidence Framework (SEF) evidence via adding an annotation has not created a record in the framework evidence table but does create a record in the block_instance table with a block type of annotation. The result is that a student has made a claim for a standard but the matrix page does not highlight that the page needs to be reviewed.

I can see multiple examples in the database for a SEF that is being assessed currently.

This is on our Live site which is currently running 25.04.

I can't replicate the issue, so it may be that the user has missed something in the annotation when saving. Are there any specific logs that are written that log the creation of the evidence? There appear to be some checks in the "instance_config_validate" function in artefact>annotation>blocktype>annotation?lib.php would these be the correct log messages to review?

Doris ⚡'s profile picture
Posts: 117

19 May 2026, 11:06

Hi James,

Unfortunately, instance_config_validate is not the right place to look. It has no log messages, and it does not run in the matrix save path at all.

Check Mahara's general error log around the time the affected blocks were created. Look for SQLException or ParamOutOfRangeException from save_evidence_in_block() or save_evidence(). If the log is clean at those timestamps, smartevidence was simply not present in the form submission when those students saved, which is the likely cause.

You could try and find them via these queries. If your site is not in English, you'll need to change the query to match what 'Annotation' is in your site's language.

-- Step 1: Find the orphaned blocks
-- existing_evidence_id populated = evidence record exists but points to wrong block, run Step 2
-- existing_evidence_id empty = no evidence record at all, run Step 3
-- same view+element twice = duplicate claim, resolve with learner
SELECT
block.id AS block_id,
block.title,
block.view,
col.framework,
element.id AS element_id,
evidence.id AS existing_evidence_id,
evidence.annotation AS existing_annotation
FROM block_instance block
JOIN collection_view cv ON cv.view = block.view
JOIN collection col ON col.id = cv.collection
JOIN framework_standard standard ON standard.framework = col.framework
JOIN framework_standard_element element ON element.standard = standard.id
LEFT JOIN framework_evidence evidence
ON evidence.framework = col.framework
AND evidence.element = element.id
AND evidence.view = block.view
WHERE block.blocktype = 'annotation'
AND col.framework IS NOT NULL
AND block.title = CONCAT('Annotation: ', element.shortname)
AND NOT EXISTS (
SELECT 1 FROM framework_evidence fe2
WHERE fe2.annotation = block.id
)
ORDER BY block.id;


-- Step 2: UPDATE evidence records pointing to the wrong block
-- The evidence row is there but the annotation reference is stale
UPDATE framework_evidence evidence
SET annotation = block.id,
mtime = block.mtime
FROM block_instance block
JOIN collection_view cv ON cv.view = block.view
JOIN collection col ON col.id = cv.collection
JOIN framework_standard standard ON standard.framework = col.framework
JOIN framework_standard_element element ON element.standard = standard.id
WHERE block.blocktype = 'annotation'
AND col.framework IS NOT NULL
AND block.title = CONCAT('Annotation: ', element.shortname)
AND evidence.framework = col.framework
AND evidence.element = element.id
AND evidence.view = block.view
AND evidence.annotation != block.id
AND NOT EXISTS (
SELECT 1 FROM framework_evidence fe2 WHERE fe2.annotation = block.id
);


-- Step 3: INSERT missing evidence records
-- No evidence record exists at all for these blocks.
-- Creates one row per accessrole - state 0 = begun.
INSERT INTO framework_evidence (annotation, framework, element, view, state, accessrole, ctime, mtime)
SELECT DISTINCT
block.id,
col.framework,
element.id,
block.view,
0,
statuses.accessrole,
block.ctime,
block.mtime
FROM block_instance block
JOIN collection_view cv ON cv.view = block.view
JOIN collection col ON col.id = cv.collection
JOIN framework_standard standard ON standard.framework = col.framework
JOIN framework_standard_element element ON element.standard = standard.id
JOIN framework_evidence_statuses statuses ON statuses.framework = col.framework
WHERE block.blocktype = 'annotation'
AND col.framework IS NOT NULL
AND block.title = CONCAT('Annotation: ', element.shortname)
AND NOT EXISTS (
SELECT 1 FROM framework_evidence evidence WHERE evidence.annotation = block.id
)
AND NOT EXISTS (
SELECT 1 FROM framework_evidence evidence
WHERE evidence.framework = col.framework
AND evidence.element = element.id
AND evidence.view = block.view
);

-- The first step after this point will show what's left over; most likely the double ups where now there
-- is a connected annotation, but the collection may still have an unconnected annotation but there's already
-- a matching annotation to the element

 

I realise this fix the root cause as that needs proper investigating but I hope it helps connect some annotations as evidence,

Doris

 

James Pearce's profile picture
Posts: 12

21 May 2026, 23:01

Hi Doris,

Thanks for the reply, that was very helpful. Working with the academics who raised the issue we think the issue may be due to students copying pages with annotations on. We are continuing to investigate.

Thanks

James

3 results