6 Jun
2009
6 Jun
'09
10:38 a.m.
Hi everyone,
Current situation
=============
Right now we have 2 mechanisms in place:
- hidden docs. These is done deep at the storage level and hidden docs
don't appear in any HQL queries. This is
- $blacklistedSpaces in xwikivars.vm which is used (or not!, that's
the problem) in some wiki pages (AllDocs, Search, Dashboard, etc)
Need
====
We have a need for blacklisted/hidden docs and spaces. This is
different than rights. This is just for presentation purpose.
The need I see is:
- guest and simple users should not see blacklisted/hidden docs and
spaces
- advanced users and admin should see them
(Note: I'm not sure we have a need to blacklist docs/spaces for
everyone including admins as it's currently done for hidden docs)
Issues
=====
1) In lots of spaces we don't exclude blacklisted spaces since at
every location you have to add specific code to do the exclude.
2) Hidden docs are a problem since there are cases we want to see
them all (like when creating a new wiki and you need to copy a
template wiki containing hidden docs)
Proposal
=======
* I believe we need to remove the filtering at the storage level. That
level should return all docs matching the queries
* We modify the default XWiki.searchDocument APIs so that they filter
on hidden docs and blacklisted spaces (using the velocity
$blacklistedSpaces variable). This would be changed later on when we
implement the new model and introduce the notion of space. When this
happen we'll be able to have hidden metadata to the Space object.
* We add a new XWiki.searchDocument API that doesn't do any filtering
WDYT?
Thanks
-Vincent
6 Jun
6 Jun
1:36 p.m.
Hi Vincent,
On 06/06/2009 11:38 AM, Vincent Massol wrote:
Hi everyone,
Current situation
=============
Right now we have 2 mechanisms in place:
- hidden docs. These is done deep at the storage level and hidden docs
don't appear in any HQL queries. This is
- $blacklistedSpaces in xwikivars.vm which is used (or not!, that's
the problem) in some wiki pages (AllDocs, Search, Dashboard, etc)
Need
====
We have a need for blacklisted/hidden docs and spaces. This is
different than rights. This is just for presentation purpose.
The need I see is:
- guest and simple users should not see blacklisted/hidden docs and
spaces
- advanced users and admin should see them
(Note: I'm not sure we have a need to blacklist docs/spaces for
everyone including admins as it's currently done for hidden docs)
No, we shouldn't. Advanced users / admins are writing applications in the wiki,
with code in all sorts of places. They (most of the times) know what they're
doing and we should give them the chance to be in full control. I can only
describe as frustrating using WebSearch to find some velocity code I wrote but
don't remember where and not getting it as a result search because it's in a
blacklisted space or hidden doc.
Let's put it like this: there are people that program in the wiki and people
that don't. The people that program in the wiki are all equal, including the XE
/ platform devs, so there is no reason to add supplementary hiding of data.
A bad thing which I see from this "hiding for everybody" is the fact that the
whole data in the wiki is no longer accessible, for _anyone_ (not even
programmers or admins), you'd need to _know_ some data is somewhere to be able
to retrieve it, which is bad. Programming rights should be enough to be able to
retrieve anything using fairly highlevel API (not doing queries to the db).
Issues
=====
1) In lots of spaces we don't exclude blacklisted spaces since at
every location you have to add specific code to do the exclude.
2) Hidden docs are a problem since there are cases we want to see
them all (like when creating a new wiki and you need to copy a
template wiki containing hidden docs)
Proposal
=======
* I believe we need to remove the filtering at the storage level. That
level should return all docs matching the queries
+1
Until the hidden value for docs, we had no restriction on the programming API
wrt to the search results. I don't see any reason why this notion has to be
implemented at that deep level, when the need is only presentational purposes.
* We modify the default XWiki.searchDocument APIs so
that they filter
on hidden docs and blacklisted spaces (using the velocity
$blacklistedSpaces variable). This would be changed later on when we
implement the new model and introduce the notion of space. When this
happen we'll be able to have hidden metadata to the Space object.
You mean the one in the com.xpn.xwiki.api.XWiki ?
if so, +1. I think the only need is for public API to filter out hidden docs and
blacklisted spaces by default. Priviledged API should be the responsibility of
the people that "know what they're doing" which I mentioned above.
I don't think a velocity variable can do it though, there are multiple APIs that
don't go through velocity and should exclude the blacklisted spaces too. Maybe a
config param? (xwiki.cfg or the newer .properties)
* We add a new XWiki.searchDocument API that
doesn't do any filtering
do we need it? in the light of those written above...
Thanks for reading this long email and coping with my inability to resume ideas,
Anca
WDYT?
Thanks
-Vincent
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
8 Jun
8 Jun
9:46 a.m.
On Jun 6, 2009, at 1:36 PM, Anca Paula Luca wrote:
Hi Vincent,
On 06/06/2009 11:38 AM, Vincent Massol wrote:
yes
Hi everyone,
Current situation
=============
Right now we have 2 mechanisms in place:
- hidden docs. These is done deep at the storage level and hidden
docs
don't appear in any HQL queries. This is
- $blacklistedSpaces in xwikivars.vm which is used (or not!, that's
the problem) in some wiki pages (AllDocs, Search, Dashboard, etc)
Need
====
We have a need for blacklisted/hidden docs and spaces. This is
different than rights. This is just for presentation purpose.
The need I see is:
- guest and simple users should not see blacklisted/hidden docs and
spaces
- advanced users and admin should see them
(Note: I'm not sure we have a need to blacklist docs/spaces for
everyone including admins as it's currently done for hidden docs)
No, we shouldn't. Advanced users / admins are writing applications
in the wiki,
with code in all sorts of places. They (most of the times) know what
they're
doing and we should give them the chance to be in full control. I
can only
describe as frustrating using WebSearch to find some velocity code I
wrote but
don't remember where and not getting it as a result search because
it's in a
blacklisted space or hidden doc.
Let's put it like this: there are people that program in the wiki
and people
that don't. The people that program in the wiki are all equal,
including the XE
/ platform devs, so there is no reason to add supplementary hiding
of data.
A bad thing which I see from this "hiding for everybody" is the fact
that the
whole data in the wiki is no longer accessible, for _anyone_ (not even
programmers or admins), you'd need to _know_ some data is somewhere
to be able
to retrieve it, which is bad. Programming rights should be enough to
be able to
retrieve anything using fairly highlevel API (not doing queries to
the db).
Issues
=====
1) In lots of spaces we don't exclude blacklisted spaces since at
every location you have to add specific code to do the exclude.
2) Hidden docs are a problem since there are cases we want to see
them all (like when creating a new wiki and you need to copy a
template wiki containing hidden docs)
Proposal
=======
* I believe we need to remove the filtering at the storage level.
That
level should return all docs matching the queries
+1
Until the hidden value for docs, we had no restriction on the
programming API
wrt to the search results. I don't see any reason why this notion
has to be
implemented at that deep level, when the need is only presentational
purposes.
* We modify the default XWiki.searchDocument APIs
so that they filter
on hidden docs and blacklisted spaces (using the velocity
$blacklistedSpaces variable). This would be changed later on when we
implement the new model and introduce the notion of space. When this
happen we'll be able to have hidden metadata to the Space object.
You mean the one in the com.xpn.xwiki.api.XWiki ? if so, +1. I think the only need is for public API to
filter out
hidden docs and
blacklisted spaces by default. Priviledged API should be the
responsibility of
the people that "know what they're doing" which I mentioned above.
I don't think a velocity variable can do it though, there are
multiple APIs that
don't go through velocity and should exclude the blacklisted spaces
too. Maybe a
config param? (xwiki.cfg or the newer .properties)
Yes, I guess a property is fine since it can be overriden in the wiki
(in XWikiPreferences). +1 to that.
Thanks
-Vincent
* We add a new
XWiki.searchDocument API that doesn't do any filtering
do we need it? in the light of those written above...
Thanks for reading this long email and coping with my inability to
resume ideas,
Anca
>
> WDYT?
>
> Thanks
> -Vincent 
6 Jun
6 Jun
2:24 p.m.
On Sat, Jun 6, 2009 at 10:38, Vincent Massol<vincent(a)massol.net> wrote:
Hi everyone,
Current situation
=============
Right now we have 2 mechanisms in place:
- hidden docs. These is done deep at the storage level and hidden docs
don't appear in any HQL queries. This is
- $blacklistedSpaces in xwikivars.vm which is used (or not!, that's
the problem) in some wiki pages (AllDocs, Search, Dashboard, etc)
Need
====
We have a need for blacklisted/hidden docs and spaces. This is
different than rights. This is just for presentation purpose.
The need I see is:
- guest and simple users should not see blacklisted/hidden docs and
spaces
- advanced users and admin should see them
(Note: I'm not sure we have a need to blacklist docs/spaces for
everyone including admins as it's currently done for hidden docs)
I think I would prefer each user to be able to indicate if he wants
filtering or not by default and it should be very easy to switch from
a mode to another, like when we search for something not having to go
to our user profile change some configuration and then return to
search to see hidden doc and them reset the hidden mode... For me this
has nothing to do with rights or types of users, this could be used to
find the DEFAULT value of the hidden mode but not THE value.
Issues
=====
1) In lots of spaces we don't exclude blacklisted spaces since at
every location you have to add specific code to do the exclude.
2) Hidden docs are a problem since there are cases we want to see
them all (like when creating a new wiki and you need to copy a
template wiki containing hidden docs)
Proposal
=======
* I believe we need to remove the filtering at the storage level. That
level should return all docs matching the queries
+1 this has nothing to do at this level
* We modify the default XWiki.searchDocument APIs so
that they filter
on hidden docs and blacklisted spaces (using the velocity
$blacklistedSpaces variable). This would be changed later on when we
implement the new model and introduce the notion of space. When this
happen we'll be able to have hidden metadata to the Space object.
Agree with Anca, +1 only if this filtering is in public apis.
* We add a new XWiki.searchDocument API that
doesn't do any filtering
WDYT?
Thanks
-Vincent
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Thomas Mortagne
8 Jun
8 Jun
9:44 a.m.
On Jun 6, 2009, at 2:24 PM, Thomas Mortagne wrote:
Yes the idea is to put it in the public API.
-Vincent
On Sat, Jun 6, 2009 at 10:38, Vincent
Massol<vincent(a)massol.net>
wrote:
I really don't want to add more complexity for users. We already have
the notion of simple/advanced users and this use case fits perfectly
with that notion. Simple users should never see hidden docs/spaces
since those are for developers.
Hi everyone,
Current situation
=============
Right now we have 2 mechanisms in place:
- hidden docs. These is done deep at the storage level and hidden
docs
don't appear in any HQL queries. This is
- $blacklistedSpaces in xwikivars.vm which is used (or not!, that's
the problem) in some wiki pages (AllDocs, Search, Dashboard, etc)
Need
====
We have a need for blacklisted/hidden docs and spaces. This is
different than rights. This is just for presentation purpose.
The need I see is:
- guest and simple users should not see blacklisted/hidden docs and
spaces
- advanced users and admin should see them
(Note: I'm not sure we have a need to blacklist docs/spaces for
everyone including admins as it's currently done for hidden docs)
I think I would prefer each user to be able to indicate if he wants
filtering or not by default and it should be very easy to switch from
a mode to another, like when we search for something not having to go
to our user profile change some configuration and then return to
search to see hidden doc and them reset the hidden mode... For me this
has nothing to do with rights or types of users, this could be used to
find the DEFAULT value of the hidden mode but not THE value. Issues
=====
1) In lots of spaces we don't exclude blacklisted spaces since at
every location you have to add specific code to do the exclude.
2) Hidden docs are a problem since there are cases we want to see
them all (like when creating a new wiki and you need to copy a
template wiki containing hidden docs)
Proposal
=======
* I believe we need to remove the filtering at the storage level.
That
level should return all docs matching the queries
+1 this has nothing to do at this level
* We modify the default XWiki.searchDocument APIs
so that they filter
on hidden docs and blacklisted spaces (using the velocity
$blacklistedSpaces variable). This would be changed later on when we
implement the new model and introduce the notion of space. When this
happen we'll be able to have hidden metadata to the Space object.
Agree with Anca, +1 only if this filtering is in public apis. > * We add a new XWiki.searchDocument API that
doesn't do any filtering
>
> WDYT?
>
> Thanks
> -Vincent
10:17 a.m.
Vincent Massol wrote:
Yes the idea is to put it in the public API.
-Vincent
>> * We add a new XWiki.searchDocument API that doesn't do any filtering
I did the initial filtering at the storage level since there are too
many search methods, and changing all of them was too much. In the
storage, there was only one place to change.
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
On Jun 6, 2009, at 2:24 PM, Thomas Mortagne wrote:
+1. Users shouldn't see hidden documents at all. Why would a simple user
be interested in the application's code? That's just for developers.
On Sat, Jun 6, 2009 at 10:38, Vincent
Massol<vincent(a)massol.net>
wrote:
I really don't want to add more complexity for users. We already have
the notion of simple/advanced users and this use case fits perfectly
with that notion. Simple users should never see hidden docs/spaces
since those are for developers. Hi everyone,
Current situation
=============
Right now we have 2 mechanisms in place:
- hidden docs. These is done deep at the storage level and hidden
docs
don't appear in any HQL queries. This is
- $blacklistedSpaces in xwikivars.vm which is used (or not!, that's
the problem) in some wiki pages (AllDocs, Search, Dashboard, etc)
Need
====
We have a need for blacklisted/hidden docs and spaces. This is
different than rights. This is just for presentation purpose.
The need I see is:
- guest and simple users should not see blacklisted/hidden docs and
spaces
- advanced users and admin should see them
(Note: I'm not sure we have a need to blacklist docs/spaces for
everyone including admins as it's currently done for hidden docs)
I think I
would prefer each user to be able to indicate if he wants
filtering or not by default and it should be very easy to switch from
a mode to another, like when we search for something not having to go
to our user profile change some configuration and then return to
search to see hidden doc and them reset the hidden mode... For me this
has nothing to do with rights or types of users, this could be used to
find the DEFAULT value of the hidden mode but not THE value. Issues
=====
1) In lots of spaces we don't exclude blacklisted spaces since at
every location you have to add specific code to do the exclude.
2) Hidden docs are a problem since there are cases we want to see
them all (like when creating a new wiki and you need to copy a
template wiki containing hidden docs)
Proposal
=======
* I believe we need to remove the filtering at the storage level.
That
level should return all docs matching the queries
+1 this has nothing to do at
this level
* We modify the default XWiki.searchDocument APIs
so that they filter
on hidden docs and blacklisted spaces (using the velocity
$blacklistedSpaces variable). This would be changed later on when we
implement the new model and introduce the notion of space. When this
happen we'll be able to have hidden metadata to the Space object.
Agree with
Anca, +1 only if this filtering is in public apis.
10:19 a.m.
On Jun 8, 2009, at 10:17 AM, Sergiu Dumitriu wrote:
Vincent Massol wrote:
Yes the idea is to put it in the public API.
-Vincent
>> * We add a new XWiki.searchDocument API that doesn't do any
>> filtering
I did the initial filtering at the storage level since there are too
many search methods, and changing all of them was too much. In the
storage, there was only one place to change.
I know Sergiu, that's why I'm proposing to keep the default
searchDocuments to do the filtering and to introduce new methods if
you want all docs.
Thanks
-Vincent
On Jun 6, 2009, at 2:24 PM, Thomas Mortagne
wrote:
+1. Users shouldn't see hidden documents at all. Why would a simple
user
be interested in the application's code? That's just for developers.
On Sat, Jun 6, 2009 at 10:38, Vincent
Massol<vincent(a)massol.net>
wrote:
I really don't want to add more complexity for users. We already have
the notion of simple/advanced users and this use case fits perfectly
with that notion. Simple users should never see hidden docs/spaces
since those are for developers. Hi everyone,
Current situation
=============
Right now we have 2 mechanisms in place:
- hidden docs. These is done deep at the storage level and hidden
docs
don't appear in any HQL queries. This is
- $blacklistedSpaces in xwikivars.vm which is used (or not!, that's
the problem) in some wiki pages (AllDocs, Search, Dashboard, etc)
Need
====
We have a need for blacklisted/hidden docs and spaces. This is
different than rights. This is just for presentation purpose.
The need I see is:
- guest and simple users should not see blacklisted/hidden docs and
spaces
- advanced users and admin should see them
(Note: I'm not sure we have a need to blacklist docs/spaces for
everyone including admins as it's currently done for hidden docs)
I think I
would prefer each user to be able to indicate if he wants
filtering or not by default and it should be very easy to switch
from
a mode to another, like when we search for something not having to
go
to our user profile change some configuration and then return to
search to see hidden doc and them reset the hidden mode... For me
this
has nothing to do with rights or types of users, this could be
used to
find the DEFAULT value of the hidden mode but not THE value. Issues
=====
1) In lots of spaces we don't exclude blacklisted spaces since at
every location you have to add specific code to do the exclude.
2) Hidden docs are a problem since there are cases we want to see
them all (like when creating a new wiki and you need to copy a
template wiki containing hidden docs)
Proposal
=======
* I believe we need to remove the filtering at the storage level.
That
level should return all docs matching the queries
+1 this has nothing to do at
this level
* We modify the default XWiki.searchDocument APIs
so that they
filter
on hidden docs and blacklisted spaces (using the velocity
$blacklistedSpaces variable). This would be changed later on when
we
implement the new model and introduce the notion of space. When
this
happen we'll be able to have hidden metadata to the Space object.
Agree with
Anca, +1 only if this filtering is in public apis.
5636
days inactive
5638
days old
6 comments
4 participants
participants (4)
-
Anca Paula Luca -
Sergiu Dumitriu -
Thomas Mortagne -
Vincent Massol