> I'm not sure that splitting the current READ permission in a more > granular way could be the rigth solution... > Could we have an EXISTENCE permission on an object without READ > permission? Could we have a READ permission on an object without EXISTENCE?
The same could be said for WRITE but no READ, or being able to READ a bitstream but not its parent item. I doubt we could build an ACL that can never have an inconsistent state. We should build tools and UIs that maintain consistency, but the tools in DSpace right now are sorely lacking. > There is only one > problem about bitstreams READ definition. In fact, while for > communities, collections, item and bundle READ means the possibility of > metadata access (therefore knowing about the object existence), the READ > permission for bitstream allows both medatata (name, size, format, etc.) > and content access (InputStream). Fair point -- right now it's not possible (I think) to 'hide' a bitstream in an item. In practical terms, I think it's READ permission on the item that determines whether you can see the bitstream's metadata. Tying down the exact semantics of such a limited set of permissions for very different objects is tricky. > Therefore I think that it would be good to make this behaviour uniform > also hooking-up the READ permission to the InputStream, and this would > also make sense for WRITE permission. The revised data model may make this much easier. (http://wiki.dspace.org/index.php/ArchReviewReport page 7). Metadata is a separate, identified object which can have separate permissions. > > It makes sense to me to have queries evaluated using a particular > > Context > could we use different indexes? Every EPerson could have a set of lucene > indexes, which would contain only the objects that he can see... > In this scenario we need to keep 1 index for any group or eperson that > have READ policies It may be possible to index all of the ACL info in Lucene but this wouldn't help e.g. the browse or OAI harvest systems at this point. Rob ------------------------------------------------------------------------- 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
