On 22.08.2012 14:52, Samuele Kaplun wrote:
Hi!
[...]
to a role and specify this very string to get some access to
the full text in a way orthogonal to the collection
association. I'm not yet sure if this solves an issue for
our case but options are always interesting. ;)
Almost. viewrestrdoc is not orthogonal. If a record belong to a restricted
collection (via viewrestrcoll) and it has restricted document (via
viewrestrdoc), a user must be authorized *both* to the collection *and* to the
document: i.e. documents are implicitly restricted at least as the collection
the corresponding record belongs to. See also below.
Ah. Ok.
[...]
And I add viewrestrcol with parameter ZB-20090406, ie. the
colletctions internal name.
Wow, you use quite intricate names in your institution :-)
They need to be unique over time and interchangable between several
institutions. Basically, it's "I:" for Institute, "(DE-Juel1)" for
issuing institution (it's just the ISIL) and then a unique ID built from
shortcut of the institute and date issued (what can you expect from an
LDAP ;).
If I now attach a pdf to my record 123 this is, however, not
restricted till now.
Not correct. It restricted as the record, i.e. you still need to be authorized
to the "ZB-20090406" collection in order to download/see it.
Ok.
Only the record as such has a
restriction, but if someone would know the direct url to the
pdf no restriction would apply. (Is this right?)
Nope :-) We really enforce the restriction. Otherwise Google or a malicious
user could have happily accessed any restricted record by simply crawling
Invenio for all the existing recids.
This is to be avoided and we thought we need to do this by document
restrictions.
Now, you say I could set the status of this document to say
"I:(DE-Juel1)ZB-20090406" in some way I don't yet know, but
surely our websubmit guru (aka Tomek) knows and could pass
this string to the viewrestrdoc action. Add this action to
my above defined role could gives access to all users of my
group I-ZB-20090406 to the document.
Well, your collection are properly set and authorized as you mention above
then I think you have no further need to also restrict documents.
Ok. This point was not clear to me.
This is what we actually do. We set up a collection for each
institute (as outlined above) and add a role with actions
attached.
So if the collection "foo" should be authorized
to group X, Y, Z, you can simply authorize these group
(for which it exists each time a role) explicitly via
"viewrestrcoll" action.
Right. But then I do not yet have the full texts restricted
but only the bibliographic record.
No, no, also the fulltext :-)
Ok, I learned that viewrestrdoc is additive to any other restrictions
that apply.
This would suffice indeed if we didn't have an open
collection that our records belong to in many cases. You
might remember that you prepared a patch for us that allows
for "if any rule matches" in the firerules block.
Unfortunately :-)
?
But I in the CFG_WEBSEARCH_VIEWRESTRCOLL_POLICY feature we
implemented for you public collections were not considered. I.e. in the any-
version, if a record belongs to the restricted collection A, the restricted
collection B and the public collection C, then the user must at least be
authorized to access the either collection A or collection B (regardless of C
being public).
Oh. Hm.
So, if I understand it correctly, I would have to restrict C such that
"guest" have access (sort of a restriction but not hard to meet). Then
the bibliographic records are viewable by guests even though they are
furthermore part of A and B.
But(!) then I again need to restrict the docs as mentioned above to be
viewable for A and B only (e.g. if there is a legal restriction on them)
or otherwise they'd be open to world.
Done :) I think we have everything in place except the the
doc restrictions (which wouln't be necessary in the first
place if Science would really be free<scnr> ;)
Eheh, well still you can use Invenio to store more than scientific documents
:-)
Psssst! Not so loud. There are some minor areas of "life, universe and
everything" that are out of scope of our current project. Luckily ;)
This is a bit more involved here as we acutally need to
harvest the LDAP (or a similar) system and also need to
generate a bunch of "bibliographic" records thereof. You
probably remember our discussion @CERN about authority
control where we use authority records living in MARC
instead of knowledge bases. (I think we should definitely
take a cup of tea over these issues in the near future, ie.
as soon as our stuff went publicly online.)
Anyway, basically we need to set up those records in this
step as well. For those following this far and wondering
"why the h... does he use so complex naming schemes", this
is the very reason: mapping institute histories, hierarchies
and rights with a bunch of collections living in t=now and
not valid for t=tomorrow in a managable way.
:-) BTW does the BEFORE/AFTER syntax in FireRole help you in any way? (i.e.
you can have time-based authorizations too).
They will be very helpful for embargoed documents, indeed.
But this before/after stuff is not an issue of rights but of
institutional history and hierarchy. Something like:
Institute a is renamed to b. a is part of A and b is part of B.
Institute c, part of C is split to at some point in time in d (being
part of D) and e (being part of E) and later d and e is merged to f
still being part of E.
In short: Just think of the worst ticket you can imagine as a starting
point, stick a name on any leaf, branch and twig. Then let this grow
(yes, they can grow together and split apart again, over time branches
die and new siblings coming up...). Imagine several of those (on the
level of institutes, grants and programs) ie. a wood and then spice it
up with an ever changing group of carbon based life forms called
"people" who insist on silly entities called "real names", that change
for some reason even in various directions while they insist that they
are still the same.
Once done try to map that in Marc to answer stuff like "I just have a
very simple question. I only need to know: what did e publish on grant g
in time t [much larger than the life time of any name involved] without
f when X was leader of subdivision y. As this is so simple, you can
surely answer it right on the spot, I need it NOW."
Plus: in this clearly structured universe every entity like "f" wants to
have her unique, own, private collection with "their" records in it for
easy access. Some of them being public ("WE did this!") while other are
private ("<censored> X did this already we need to...")
And only then comes some lawyer and the restriction stuff.
I fear this is a bit over simplified, but actually what we try to do. ;)
--
Kind regards,
Alexander Wagner
Subject Specialist
Central Library
52425 Juelich
mail : [email protected]
phone: +49 2461 61-1586
Fax : +49 2461 61-6103
www.fz-juelich.de/zb/DE/zb-fi
------------------------------------------------------------------------------------------------
------------------------------------------------------------------------------------------------
Forschungszentrum Juelich GmbH
52425 Juelich
Sitz der Gesellschaft: Juelich
Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
Vorsitzender des Aufsichtsrats: MinDir Dr. Karl Eugen Huthmacher
Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender),
Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt,
Prof. Dr. Sebastian M. Schmidt
------------------------------------------------------------------------------------------------
------------------------------------------------------------------------------------------------
Kennen Sie schon unsere app? http://www.fz-juelich.de/app
