Andrew Jaquith wrote:
1) while the usual search functionalities respect permissions (es.
Person X in group Y cannot even see a page restricted to group Z) this
is not respected
by the RecentChanges plugin (all pages can be seen - albeit when jumping
there you get the usual error message)
I understand your concern, but I do not believe this is a bug. I would
argue that is better for RecentChanges to show all recent changes,
even those that are for pages the user has no access to. The idea
behind ACLs (and security policies, for that matter) is to restrict
access, not make them invisible to less-privileged users.
Well, in some context just knowing something exists (not to say anything
you can grab even from just reading page name) may be something not wanted.
As for the point of ACLs to be used only to restict access and not to
make them invisible .... we could discuss about it in general, but it is
a matter of fact
that currently even just viewing is something that you can disable, and
this is also reflected in search results (so the behaviour of the
recentChanges plugin -
btw not checked the referring pages one - is anyway non coherent with
that of search)..
2) this can onlybe enforced by the author adding [{ALLOW edit mygroup}].
2) any other way? I was wondering whether thic can be enforced by a
filter ...
Not sure what you meant by "this" and "thic."
Sorry ... typo ('thic' for 'this') and too short ...
My point was about the possibility to exploit the filter mechanism to
automatically add a 'ALLOW edit my group' when saving - and also possibly
hiding it when editing. And the question about whether this approach
could be reasonable or there are other alternatives.
I suspect the discussion had in recent thread on page metadata in this
mailing list would also mostly apply here, but interested in having
a better understanding
L
Tx in advance
Luca