Restricting access to Communites, Collection or Items directly is certainly not what DSpace was designed to do.
This is really one of the real "pain points" of DSpace IMO. There are just so many places where the assumption that a container (Community/ Collection/Item) will be unrestricted. To correctly fix the issue requires access control to be taken into consideration "in" the DSpace Model in methods such as DSpaceObecjt.findAll and that services that need to access those methods (JSPUI/OAI/XMLUI/CLI) such that they only return the children that the context is authorized to see, this means that every child needs to be evaluated before being returned in the List, Array or Iterator that comes back from these methods. The Harvest class (I.E. OAI Harvest) would need to have its own logic cleaned up (because if I remember correctly) it directly queries the database and uses its own instantiation to return objects. Conversely, as Andrea states, Search and Browse would need to be extended to support indexing Access control details and to manage limiting search across those spaces. I thought about this a bit and considered exploring such work, we just keep stepping back and asking "why are we attempting to restrict access to a Community/Collection/Item?" and redoing our requirements to eliminate the need. For instance: 1.) Don't use "Communities/Collections" to Identify only the items you want to expose of OAI harvesting, maybe instead use an external OAI Server and only add the items you want to that Gateway and not use the internal dspace-oai implementation. 2.) Use another installation of DSpace restricted exclusively to that user group for those wishing to have controlled access to Communities/ Collections/Items. My warning is that you've really reached a "boundary" in the capability/design of DSpace and rather falling off into a bottomless pit of customizations that you have maintain, instead reuse instances of dspace and OAI services with a little configuration/automation between them to achieve the same goal. I think its clear that with such an architectural issues being exposed as limitations, we should certainly consider putting it into the design requirements for DSpace 2.0 Cheers, Mark On Sep 1, 2007, at 9:38 AM, Andrea Bollini wrote: > mmm... I'm really wrong > I'm sorry but I should read more closely your wiki page ;-) > You have modified some part of retrieval API so your patch is not only > for JSPUI, as you have noted it doesn't works on oai-pmh because there > are others methods (as findAll() used by oai-pmh) for retrieval > collection & communities. > Note that if you hide some collections in findAll() you can have > problem > in oai-pmh response because your record could have a reference to a > set > (=collection) not displayed in ListSets (it use findAll). > If you hide collection in Item.getCollection() this will result in > strange behavior when you display item mapped from an hidden > collection > to a not hidden collection... (so the problem has not a really simple > solution "community wide"). > > Finally, you have missed another end-user point where he can see your > hidden collection&communities: advanced-search, try a first search > with > no result or wrong input and in the dropdown menu its appears > best, > Andrea > > Andrea Bollini ha scritto: >> Hi Lucas, >> thanks for you clear wiki page, it should be useful for someone >> others. >> Please note that your "patch" is *only* on user interface (JSPUI) >> so the >> communities and the collections that you hide are visible on oai-phm >> response (if you think you can add this info in "Things to do"). >> A more complete solution needs to alter the retrieval API >> (getCollections(), getItems(), getCommunities and so...) I'm >> currently >> exploring this scenario. >> Best, >> Andrea >> >> Schaik, L.B. van ha scritto: >> >>> Hi, >>> >>> At Leiden University, The Netherlands, we wanted to hide some >>> collections and communities from the Communities and Collections >>> page. >>> This is because we have a special community for all our harvest >>> collections (that include a subset of items from our normal >>> collections), but we did not want to show them to the "normal" user. >>> Also, we have a community for a special group within our >>> University, and >>> we wanted to be able to show this community only to people >>> working at >>> this special group. >>> >>> Well, we modified Dspace in such a way that we leverage to power of >>> resource policies to determine if a community/collection needs to >>> display on the Communities and Collections page. >>> >>> How we did that and how you can implement this too, is explained >>> on the >>> following wiki page: >>> http://wiki.dspace.org/index.php/ >>> Hide_Community_or_Collection_from_list >>> >>> >>> Hope this is useful to someone. If you have questions, please let me >>> know. >>> >>> regards, >>> >>> Lucas van Schaik >>> Developer >>> >>> Leiden University Library >>> Witte Singel 27, Postbus 9501, 2300 RA Leiden >>> Tel. +31 71 - 527 28 87 >>> E-mail: [EMAIL PROTECTED] >>> >>> >>> >>> -------------------------------------------------------------------- >>> ---- >>> >>> -------------------------------------------------------------------- >>> ----- >>> This SF.net email is sponsored by: Splunk Inc. >>> Still grepping through log files to find problems? Stop. >>> Now Search log events and configuration files using AJAX and a >>> browser. >>> Download your FREE copy of Splunk now >> http://get.splunk.com/ >>> -------------------------------------------------------------------- >>> ---- >>> >>> _______________________________________________ >>> Dspace-devel mailing list >>> [EMAIL PROTECTED] >>> https://lists.sourceforge.net/lists/listinfo/dspace-devel >>> >>> >> >> >> > > > -- > Dott. Andrea Bollini > Responsabile tecnico sviluppo e formazione applicativi JAVA > Sezione Servizi per le Biblioteche e l'Editoria Elettronica > CILEA, http://www.cilea.it > tel. +39 06-59292831 cel. +39 348-8277525 > > > ---------------------------------------------------------------------- > --- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a > browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > DSpace-tech mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/dspace-tech ~~~~~~~~~~~~~ Mark R. Diggory - DSpace Systems Manager MIT Libraries, Systems and Technology Services Massachusetts Institute of Technology ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ DSpace-tech mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/dspace-tech
