EDIT

Subtree filter is now implemented for (rankSpecific)rootNotes and simple taxon search. API exists also for freetext search (but filter not yet implemented)

the query parameter should be the same in all webservice uris: subtree

Andreas Kohlbecker wrote:

the query parameter should be the same in all webservice uris: subtree

DONE: 905f70dc

Also the following webservices need to get a subtree filter:

• /portal/taxon/{uuid}
• /portal/taxon/{uuid}/taxonNodes
• /portal/classification/{uuid}/pathFrom/{uuid}/toRank/{uuid}
• /classification/{uuid}/childNodesOf/{uuid}

Andreas Kohlbecker wrote:

Open issues:

tested with subtree filter Plumbaginaceae Juss. [#t10#1986#28#] uuid=0ad45274-c5cf-4a95-aa1b-dc698e78f53a

1) http://api.cybertaxonomy.org/caryophyllales_spp/portal/classification/9edc58b5-de3b-43aa-9f31-1ede7c009c2b/childNodesAt/ac470211-1586-4b24-95ca-1038050b618d?subtree=0ad45274-c5cf-4a95-aa1b-dc698e78f53a

returns the taxon set as filter! I think this should be supressesd

Why should it be suppressed? Where does it lead to problems and where is it used. Isn't this the root node for the tree and therefore should appear?

Andreas Kohlbecker wrote:

Open issues:

2) http://api.cybertaxonomy.org/caryophyllales_spp/portal/taxon/7114a8f3-6610-411d-b559-c28e7821cf1c/synonymy?subtree=0ad45274-c5cf-4a95-aa1b-dc698e78f53a'

not yet with filter parameter

I do not understand why this is required. The webservice is not used as primary input for a taxon page or any other portal site. So we do not need to filter it.
However I implemented it (cdmlib|bc9db6bf23) as it was more or less copy and paste from taxon/uuid . Please do review. I did not test with live data

Andreas Kohlbecker wrote:

Open issues:

3) http://api.cybertaxonomy.org/caryophyllales_spp/portal/taxon/7114a8f3-6610-411d-b559-c28e7821cf1c/toNameRelationships?subtree=0ad45274-c5cf-4a95-aa1b-dc698e78f53a

not yet with filter parameter

Again I do not understand why this needs to be filtered. If necessary we can do it the same way as the synonymy (3 lines of code), but it is not necessary. We do not want to filter webservices but data portals. For this it is not needed. Otherwise please give a dataportal link which is not protected because of this service.

To the issues 1) - 3) reported in #7745#note-17:

1) You are right, this web service behaves ok.

2) I reported this because the webservice is being used during the composition of the taxon page. It is not really required to protect it at the moment, but it could become more relavant once the data portal taxon pages are more modularized and rendered anynchonously. Anyway, thanks for filtering this webservice also. Implementation looks ok

3) I agree, this is not really needed a the moment.

So can we close the ticket?

Andreas Müller wrote:

So can we close the ticket?

You were too fast ;-)

For the polytomous keys the following webservices need to be filtered by the subTree to avoid unpublished taxa showing up in the key:

• polytomousKey/{uuid}.json --> suppress the whole key if it a) targets any taxon which needs to be suppressed or b) the taxonomic scope includes taxa to be suppressed?
• polytomousKeyNode/{uuid}/taxon.json --> suppress target taxa per polytomousKeyNode

we need to decide if keys need to be suppressed completely or if only specific nodes are to be shown incompletely? I think the whole key needs to be hidden if it is not 100% included in the classification subtree.

I suggest to open a new ticket for the remaining issues

Andreas Kohlbecker wrote:

For the polytomous keys the following webservices need to be filtered by the subTree to avoid unpublished taxa showing up in the key:

• polytomousKey/{uuid}.json --> suppress the whole key if it a) targets any taxon which needs to be suppressed or b) the taxonomic scope includes taxa to be suppressed?
• polytomousKeyNode/{uuid}/taxon.json --> suppress target taxa per polytomousKeyNode

we need to decide if keys need to be suppressed completely or if only specific nodes are to be shown incompletely? I think the whole key needs to be hidden if it is not 100% included in the classification subtree.

I suggest to open a new ticket for the remaining issues

copied to new ticket: #9402