[Deploying Sakai] [Building Sakai] Issue in 2.7.x content branch from 18 May to 1 Aug
stephen.marquard at uct.ac.za
Fri Aug 5 08:22:19 PDT 2011
Here's a brief description of what we did. You'll have to modify this
for your own situation. The process below is also not the most efficient
in execution time, but it was the fastest for us to put together
(because of reuse of existing code, etc.).
1. Query our event log archive database to find content.revise events
within a specific date range (in which we had the bug present on the
select DISTINCT REF from SAKAI_EVENT_2011
WHERE EVENT_DATE > '2011-07-20' AND EVENT='content.revise' INTO OUTFILE
2. Create a webservice to check and adjust if necessary the properties
for a given resource. Note you can deploy a .jws file into a running app
server without a restart. See fixResourceVisibility() in
The code removes show/hide dates for any resource where the show/hide
dates are exactly a week apart (the default settings introduced by the
bug). You could also put this code into a quartz job or something.
3. Create a perl script to invoke the method for each "suspect"
resource reference. Sample here:
Invoke with the output from the SQL query above, e.g. fix_visibility.pl
As a fourth step, we mailed users (again with a custom query and a perl
script) to advise them that we had reset the show/hide dates, and
listing the resources for each user for which we'd done that, to cover
any cases where users had intentionally set show/hide dates and we'd
then removed them.
Stephen Marquard, Learning Technologies Co-ordinator
Centre for Educational Technology, University of Cape Town
Email / IM (Jabber/XMPP): stephen.marquard at uct.ac.za
Phone: +27-21-650-5037 Cell: +27-83-500-5290
>>> Daniel Robinson <d.b.robinson at lancaster.ac.uk> 8/5/2011 4:02 PM >>>
We updated our production instance of 2.8.x late June and have some
worksites experiencing what seems to be the same problem.
We'd appreciate any help you can offer with the cleanup scripts.
On 5 Aug 2011, at 14:13, Anthony Whyte wrote:
> The ticket in question that tracks this issue is SAK-20280.
> It appears that 2.8.x was also affected by this bug between r92647
(Mon 5 May 2011) and r96021 (Mon 1 Aug 2011).
> Second, a cursory review of the commits associated with SAK-20280
suggests that the content.properties commit r92656 (Thur 5 May 2011) is
missing from 2.8.x but the properties file change was indeed merged
(r92657) though linked to SAK-20264.
> On Aug 5, 2011, at 3:47 AM, Stephen Marquard wrote:
>> Hi all,
>> There was a bug in the 2.7.x content branch between r93034 (Wed 18
>> and r95999 (Mon 1 Aug) which led to incorrect release and retract
>> being set on content folders or items whose properties were updated
>> (e.g. setting a quota on a site's resources folder, or updating a
>> description). This does not affect any 2.7 releases, only the
>> maintenance branch between 2.7.1 and 2.7.2 (still to be released).
>> The effect of the bug was to set a release date of the current date
>> (when it was revised) with a retract date 7 days later. Hence in
>> course, many resources (and entire folder structures) became hidden
>> If you had this code in production at any time, your users may have
>> been exposed to this issue (and may not realise it until some time
>> later). We unfortunately fell into this trap at UCT, and have
>> some cleanup scripts to fix the affected resources which we can
>> anyone else runs into the same situation.
>> Stephen Marquard, Learning Technologies Co-ordinator
>> Centre for Educational Technology, University of Cape Town
>> Email/IM/XMPP: stephen.marquard at uct.ac.za
>> Phone: +27-21-650-5037 Cell: +27-83-500-5290
>> UNIVERSITY OF CAPE TOWN
>> This e-mail is subject to the UCT ICT policies and e-mail
>> published on our website at
>> http://www.uct.ac.za/about/policies/emaildisclaimer/ or obtainable
>> +27 21 650 9111. This e-mail is intended only for the person(s) to
>> it is addressed. If the e-mail has reached you in error, please
>> the author. If you are not the intended recipient of the e-mail you
>> not use, disclose, copy, redirect or print the content. If this
>> is not related to the business of UCT it is sent by the sender in
>> sender's individual capacity.
>> production mailing list
>> production at collab.sakaiproject.org
>> TO UNSUBSCRIBE: send email to
production-unsubscribe at collab.sakaiproject.org with a subject of
> sakai-dev mailing list
> sakai-dev at collab.sakaiproject.org
> TO UNSUBSCRIBE: send email to
sakai-dev-unsubscribe at collab.sakaiproject.org with a subject of
UNIVERSITY OF CAPE TOWN
This e-mail is subject to the UCT ICT policies and e-mail disclaimer
published on our website at
http://www.uct.ac.za/about/policies/emaildisclaimer/ or obtainable from
+27 21 650 9111. This e-mail is intended only for the person(s) to whom
it is addressed. If the e-mail has reached you in error, please notify
the author. If you are not the intended recipient of the e-mail you may
not use, disclose, copy, redirect or print the content. If this e-mail
is not related to the business of UCT it is sent by the sender in the
sender's individual capacity.
More information about the production