[Building Sakai] [Deploying Sakai] Issue in 2.7.x content branch from 18 May to 1 Aug

Fri Aug 5 08:39:36 PDT 2011

Stephen, thanks very much for the detailed instructions and scripts.

We'll report back on how we get on.

Best wishes,

Daniel

On 5 Aug 2011, at 16:22, Stephen Marquard wrote:

> 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
> system), e.g.
> 
> select DISTINCT REF from SAKAI_EVENT_2011
> WHERE EVENT_DATE > '2011-07-20' AND EVENT='content.revise' INTO OUTFILE
> 'content-fix-jul2011-refs.csv';  
> 
> 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
> http://source.cet.uct.ac.za/svn/sakai/src_mods/trunk/webservices/axis/src/webapp/WSContent.jws
> 
> 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:
> http://source.cet.uct.ac.za/svn/sakai/scripts/trunk/SAK-20280/fix_visibility.pl
> 
> Invoke with the output from the SQL query above, e.g. fix_visibility.pl
> content-fix-jul2011-refs.csv
> 
> 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.
> 
> Cheers
> Stephen
> 
> 
> -- 
> Stephen Marquard, Learning Technologies Co-ordinator
> Centre for Educational Technology, University of Cape Town
> http://www.cet.uct.ac.za
> 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 >>>
> 
> Hi Stephen,
> 
> 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.
> 
> Best wishes,
> 
> Daniel
> 
> On 5 Aug 2011, at 14:13, Anthony Whyte wrote:
> 
>> The ticket in question that tracks this issue is SAK-20280.
>> 
>> https://jira.sakaiproject.org/browse/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.
>> 
>> Cheers,
>> 
>> Anthony
>> 
>> 
>> 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
> May)
>>> and r95999 (Mon 1 Aug) which led to incorrect release and retract
> dates
>>> 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
> due
>>> course, many resources (and entire folder structures) became hidden
>>> unexpectedly.
>>> 
>>> 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
> written
>>> some cleanup scripts to fix the affected resources which we can
> share if
>>> anyone else runs into the same situation.
>>> 
>>> Regards
>>> Stephen
>>> 
>>> 
>>> Stephen Marquard, Learning Technologies Co-ordinator
>>> Centre for Educational Technology, University of Cape Town
>>> http://www.cet.uct.ac.za
>>> 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
> 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.
>>> 
>>> ###
>>> 
>>> _______________________________________________
>>> production mailing list
>>> production at collab.sakaiproject.org
>>> http://collab.sakaiproject.org/mailman/listinfo/production
>>> 
>>> TO UNSUBSCRIBE: send email to
> production-unsubscribe at collab.sakaiproject.org with a subject of
> "unsubscribe"
>>> 
>>> 
>> 
>> _______________________________________________
>> sakai-dev mailing list
>> sakai-dev at collab.sakaiproject.org
>> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>> 
>> TO UNSUBSCRIBE: send email to
> sakai-dev-unsubscribe at collab.sakaiproject.org with a subject of
> "unsubscribe"
> 
> 
> 
> 
> 
> 
> ###
> 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.
> 
> ###
> 