Hi Jesús I think this approach works for us because the majority of items are in the open access category, if you have a real mixed bag then perhaps its is not so easy to implement and not the answer for you.
The private items are only viewable by the collection-admin (the main one) and/or the dspace-admin account, we either restrict the whole record or the bitstreams. If you wanted to allow other users to view the item this would get very messy and be hard to administer. Essentially the permissions occur at the item level and bitstream. Hope this make its clear. 1. Item is input within the normal submmission environment 2. Collection admin approves for entry 3. Permissions are applied by editing the record using the authorisations view I have seen other examples of theses with various levels of authentication better dealt with using the Tapir addon Cheers Leonie Hayes Project Manager Institutional Repositories Aotearoa University of Auckland Library New Zealand www.ira.auckland.ac.nz -----Original Message----- From: Jesus Martin [mailto:[EMAIL PROTECTED] Sent: Monday, 28 May 2007 10:12 p.m. To: Leonie Hayes Cc: [email protected] Subject: Re: [Dspace-tech] Granularity of Authentication Hi Leonie, after I read your message about granularity of authentication I have few questions: - how do you give permissions to public or private items in the same collection? - Do you use the dspace-admin account or there is another method whithout the dspace-admin account and without changing the permissions of the collection every time that a new item is inserted? Thanks in advance Jesús Martín Leonie Hayes wrote: > > Hi Eric and others re Theses authentication > > We find DSpace really good for dealing with the minority of work that > needs more complex restrictions. > > 90% or more of our items belong in the first category and we try to > encourage this. There is always going to be other work that has > complex authentication/access issues so we have put some examples in > place see links below. > > The three levels of access to theses in ResearchSpace are: > > 1. No restriction. Thesis is freely available for download over the > Internet. An example is at http://hdl.handle.net/2292/375 > > 2. Medium restriction. Abstract and front matter (up to Chapter 1) is > freely available for download, but the rest of the thesis is > restricted to administrator-only access. An example is at > http://hdl.handle.net/2292/382 > > 3. High restriction. The full text of the thesis is locked down for > administrator-only access. The information available on ResearchSpace > is the same access as provided in Voyager, the University of > Auckland's online Library Catalogue. > An example is at http://hdl.handle.net/2292/403 > > Cheers > Leonie Hayes > Project Manager > Institutional Repositories Aotearoa > University of Auckland Library > New Zealand > www.ira.auckland.ac.nz > > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of > [EMAIL PROTECTED] > Sent: Saturday, 21 April 2007 7:10 a.m. > To: [email protected] > Subject: DSpace-tech Digest, Vol 12, Issue 45 > > Send DSpace-tech mailing list submissions to > [email protected] > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.sourceforge.net/lists/listinfo/dspace-tech > or, via email, send a message with subject or body 'help' to > [EMAIL PROTECTED] > > You can reach the person managing the list at > [EMAIL PROTECTED] > > When replying, please edit your Subject line so it is more specific > than > "Re: Contents of DSpace-tech digest..." > > > Today's Topics: > > 1. Re: DSpace a memory hog? (Brad Teale) > 2. Re: Config Submission notes (Tim Donohue) > 3. Re: browse index problem (Jeffrey Trimble) > 4. Re: granularity of authentication for undergrad theses (Adam Brin) > 5. recommendations for a high-performance installation > (Deborah Kaplan) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Fri, 20 Apr 2007 11:28:11 -0500 > From: Brad Teale <[EMAIL PROTECTED]> > Subject: Re: [Dspace-tech] DSpace a memory hog? > To: Cory Snavely <[EMAIL PROTECTED]> > Cc: [email protected] > Message-ID: <[EMAIL PROTECTED]> > Content-Type: text/plain; charset=ISO-8859-1 > > Cory, > > Comments below: > > On 04/18/2007 01:54 PM, Cory Snavely wrote: > >> Well, as I said at first, it all depends on your definition of what a >> memory hog is. Today's hog fits in tomorrow's pocket. We better all >> already be used to that. >> > > Thank you for proving my point on memory bloat pervasiveness in the IT > industry. This type of thinking allows vendors (whether open source > or > proprietary) to drive up the "base" systems requirements without > greatly improving functionality because it is predestined. > > >> Also, I don't think for a *minute* that the original developers of >> DSpace made a casual choice about their development environment--in >> fact, I think they made a responsible choice given the alternatives. >> Let's give our colleagues credit that's due. Their choice permits >> scaling and fits well for an open-source project. Putting the general >> problem of memory bloat in their laps seems pretty angsty to me. >> >> Lastly, dedicating a server to DSpace is a choice, not a necessity. >> We >> > > >> as implementors have complete freedom to separate out the database >> and >> > > >> storage tiers, and mechanisms exist for scaling Tomcat horizontally >> as >> > > >> well. In the other direction, I suspect people are running DSpace on >> VMware or xen virtual machines, too. >> > > I didn't say they made a casual choice about their development > environment. I said the functional requirements of the application > didn't justify the memory footprint required to run this application. > Whether or not they made a choice that "fits well for an open-source > project" depends on your definition of Open Source. However, I don't > think that debate is relevant to this discussion. > > As far as scaling requirements, it depends on where you want > scalability. As you pointed out, there is a natural ability with web > applications to scale them vertically through hardware or Tomcat's, > now native, horizontal approach. Since either approach needs > hardware, the memory footprint of an application needs to be taken > into account. The higher the "base" system requirements, the > likelihood of someone having a scalable system is lowered due to total cost > of ownership (TCO). > While virtual machine technology can help lower some TCO issues, it > brings in a whole new batch of problems which are out of scope for > this discussion. > > The general problem of memory bloat rests in all developers laps (mine > included). As an industry, we need to constantly weigh our use of > memory against the functionality we are providing. The functionality > provided by Dspace isn't rocket science, and shouldn't require memory > footprints greater than most of systems that get people into space. > > -- ...................................................................... __ / / Jesús Martín García C E / S / C A Tècnic en Sistemes /_/ Centre de Supercomputació de Catalunya Gran Capità 2-4 (Edifici Nexus) 08034 Barcelona T. 93 205 6464 F. 93 205 6979 [EMAIL PROTECTED] ...................................................................... ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ DSpace-tech mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/dspace-tech
