mahara-contributors team mailing list archive

[Robert Lyon <robertl@xxxxxxxxxxxxxxx>]

Ok, now I've figured out what is going on.

In v1.3 onwards there is a function called update_locked that correctly
locks the related artefacts for the submitted view, in fact it takes the
user id and makes sure all the things that need to be locked are and
anything that doesn't need to be locked is unlocked.

In v1.2 the form submit function in view/submit.php only updated the
view table and did not lock any artefacts at all.

So if a site has come from pre 1.3 and a user had submitted a view (or
views) then but had not submitted anything post upgrade to 1.3 (or
higher) then the submitted pages would not have the artefacts correctly
locked.

The db update will check for any users that fall into this category and
apply the locks for them (due to the probability they are old, not
currently used accounts).

-- 
You received this bug notification because you are a member of Mahara
Contributors, which is subscribed to Mahara.
Matching subscriptions: Subscription for all Mahara Contributors -- please ask on #mahara-dev or mahara.org forum before editing or unsubscribing it!
https://bugs.launchpad.net/bugs/1281787

Title:
  Artefacts not locked in in submitted view

Status in Mahara ePortfolio:
  In Progress

Bug description:
  This looks to be problem with data on older sites. I've marked as high
  as bad data should be sorted asap

  Looking in the database there are views submitted for review but
  artefacts used in the view are not locked.

  To find the rows:
  SELECT a.id     
  FROM view_artefact va 
  LEFT JOIN view v on v.id = va.view
  LEFT JOIN artefact a on a.id = va.artefact
  WHERE v.submittedgroup IS NOT NULL AND a.locked = 0

  And to fix them:
  UPDATE artefact SET locked = 1
  FROM (SELECT a.id     
  FROM view_artefact va 
  LEFT JOIN view v on v.id = va.view
  LEFT JOIN artefact a on a.id = va.artefact
  WHERE v.submittedgroup IS NOT NULL AND a.locked = 0) AS subquery
  WHERE artefact.id = subquery.id;

  More investigation into how the databases ended up with bad data is
  needed and then a db upgrade change will need to be added to
  /lib/db/upgrade.php if needed.

To manage notifications about this bug go to:
https://bugs.launchpad.net/mahara/+bug/1281787/+subscriptions