|
Peter A. Knoop made changes - 04-Sep-2007 11:17
I couldn't reproduce this on qa1-za 2-5-0_QA_007. I tried:
- Creating a site with a bunch of the demo rosters (6) and Section Info tool (defaults to automatically manage) - Looking in SAKAI_REALM, there are 7 realms (site realm + 6 section realms) - In Site Info, added a new participant (student0300) and then also a new tool, both of which save the site - Still the same 7 realms in SAKAI_REALM What triggers this is switching from manually managed Sections in Section Info to automatically managed sections.
If the default is automatic and you leave it like that, then it's fine. If you switch from automatic to manual, then switch back again, you get left with a set of sections in SAKAI_REALM with no provider ids, and a new set of sections with provider ids. So this would appear to a Section Info bug rather than a site/realm bug. Updating component and assignment accordingly.
Stephen Marquard made changes - 12-Oct-2007 11:49
I believe the section info tool uses siteService.save to preform these actions,
as I have quartz code which uses the call above directly and creates orphaned realms as the siteInfo tool does.. these orphaned realms may well be referred to by resources, schedule and announcements XML bindings, if the users have set up access restrictions. but that's another jira. this code reproduces the effect (in 2.4)
and is a fragment from quartz. I'll wrap it up in a JWS and add it to this JIRA start ==== if (LOG.isDebugEnabled()) LOG.debug(logName + " saving sync-last, sync-state properties for site: "+ siteId); EventTrackingService.post(EventTrackingService.newEvent(SCP_INFO, "saving site: " + siteId , true)); e.addProperty("sections_externally_maintained", "false"); LOG.debug(logName + " SCP: **** Section Info Toggle Dance Step One ***** "); siteService.save(s); // site service eventually gets to SectionManager, which updates the reamls. or is supposed to. // trying a crazy idea; try to toggle like the SI UI does if (LOG.isDebugEnabled()) LOG.debug("saving second site save: "+ siteId); // e.removeProperty("sections_externally_maintained"); e.addProperty("sections_externally_maintained", "true"); LOG.debug(logName + " SCP: **** Section Info Toggle Dance Step Two ***** "); siteService.save(s); // site service eventually gets to SectionManager, which updates the reamls. or is supposed to. if (LOG.isDebugEnabled()) LOG.debug(logName + " re-saved properties for site: "+ siteId); EventTrackingService.post(EventTrackingService.newEvent(SCP_INFO, "saved Site: " + siteId , true)); cleanUpRealmOrphans(s); // siteService.save leaves orphan realm groups === this may all well end up back at the section service. more in a bit. It still looks like a section info issue to me, unless you can reproduce this in a site with only site groups (i.e. not sections), or manually maintained sections only.
The Section manager does stuff in the background to synchronize section membership when sections_externally_maintained=true. Section Management, which Section Info is a user, yeah probably.
So, the section manager needs to trigger the deletion of any existing realms/AuthZgroups that are defined as sections whenever manual is toggled to auto in Section Info -- does that sum it up?
Oliver,
I was going to try and make the section manager use any current realms it could to avoid the related SAK-11921. I am really hoping I can work on this issue next week, however our staff is hot for new features as opposed to bug fixing. I have Realm orphan cleaning code in my CM / Site update sync jobs as a workaround. The orphaned realms may be used by Section aware tools.
casey dunn made changes - 13-Oct-2007 12:16
upon review, Oliver, the answer is: NO.
sorry about not making that clear earlier today. just some notes for later:
SiteService.save(Site) -> BaseSiteService.doSave(Site, isNew) -> some funky stuff with site properties (why aren't the site properties methods exposed? hmm.) iterate across Site Advisors (around 829 of BaseSiteService): org.sakaiproject.component.section.sakai.SectionManagerImpl org.sakaiproject.tool.coursemanagement.hometool.impl.CmHomeServiceImpl the SectionManagerImpl does some heroic stuff. onward w/review. I am inclined to close this as a "Won't fix," chalking it up as one of the costs of Sakai's generic flexibility for institutions with archaic or byzantine SISs and complex CM demands (like UCB).
I gotcha. or at least your sentiment. not sure on how the costs of generic flexibility work in there - did you mean generic inflexibility? or that it is overly generic hence not useful?
anyhoo I am, in one of my 'get to return to this stuff once every few weeks" bursts of activity, looking at it still. I'm looking at a part where new groups for externally maintained sections are created, but the SMgr never checks to see if groups are already in existence with the about-to-be-created section's provider id. if a Jira is closed as "wont fix" does that mean that comments are no longer accepted? Without some major re-architecting, too generic to function as well as a home grown LMS might . Closed issues can still be commented on. They can also be re-opened if working on an unsolved problem becomes a priority for anyone. The other option is set a 2.6 target version, but I'd rather not have to defer the issue again in 09
close it won't fix!
I'll keep at it 4 the needs of Stanford. What I end up with may be too unwieldy for other deployments. The side-impact on the ACLs of group-aware tools is a major issue for Stanford - folks like section aware restrictions. FWIW I think it should be fixed rather than closed without fixing. Operations that you can do in the UI shouldn't leave behind orphaned data in the db.
Casey, All right if I assign this to you? We are happy to share commit rights and "ownership" with others for whom this app is important.
Casey, based on the comments above, I'm going to assign this issue to you for now with a tentative target version of 2.6. Thanks.
Peter A. Knoop made changes - 28-Dec-2007 12:16
Peter A. Knoop made changes - 06-Jan-2008 14:22
I'm back on this, start-of-term willing.
I'll be keeping notes here, so those of you watching the bug may want to not watch for a while. I clearly had the wrong term in mind.
review: So the trigger for 11320 can be: using Section Info options preform: Automatic Management -> Manual Management -> Automatic Management let me call those states: A1 -> M1 -> A2 where you get new realms as you enter A2. If during A1 or M1 the users set ACLs in Section-aware tools some of the tools will stuff the realm Id into XML (etc etc). Once we're in A2 state there are all new groups. These don't match the Ids stuffed away by the section aware tools. SAK-11921 it also leads to orphaned realms, as the M1->A2 transition leaves the now 'unused' realms lingering. if you have a lot of sections you get a lot of orphaned realms. We're testing a patch to SectionManagerImpl which takes advantage of the group's persisting properties to test for and restore the A1 state's provider id setting during M1 -> A2 change. These properties are part of the decoration done to the standard authz groups to bring in "section awareness." As the link to CM is via a providerId, and that is stashed away in the properties... off we go. If during M1 state sections are added the corresponding groups remain as orphans after a M1->A2 transition.
Filter Maintainer made changes - 10-Jun-2008 16:09
Filter Maintainer made changes - 11-Jun-2008 09:21
Filter Maintainer made changes - 18-Jul-2008 09:55
Filter Maintainer made changes - 01-Oct-2008 13:22
Filter Maintainer made changes - 23-Oct-2008 07:49
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Bug
Open
Major
Section Info leaves behind unused Realms
the Sections are created via the Section Info (SI) tool.
steps:
SI is added to the Site.
SI's Options link
SI "Automatically Manage Site Sections" is chosen, and confirmed
bang, at that point we get a new set of authz groups.
background:
updates to CM data are ignored by SI, so workaround
is to explicitly re-save the Site. This must call in the Section
site adviser as well, to resolve the provider Ids provided memberhsip
of the groups.
workaround to the side effect is to compare SAKAI_SITE_GROUP
(via site.getGroups()) with authzGroupService.getAuthzGroups(s,page)
and scrape out the orphans by authzID and Provider comparison. (provider
comparison bonus, authzId would be sufficient as long as the top realm is
automatically addressed)