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

Fri Aug 5 14:02:56 PDT 2011

Thank you for finding this.. We quickly patched it.. only about 120 
contents affected by this.. So we did it manually..

Also we filter out Dropbox, Melete, content in my Workspace etc. in 
initial query..

   and a.ref not like '%meleteDocs%'
   and a.ref not like '%/content/group-user/%'
   and a.ref not like '%/content/user/%'

Omer

On 8/5/2011 10:39 AM, Daniel Robinson wrote:
> 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.
>>
>> ###
>>
>
> _______________________________________________
> 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"
>
> !DSPAM:2294,4e3c0eb6194435666620612!
>
>