Implementation of Issues with multiple parents.

[jmatsushita]

cc @quentinberder

It seems that the implementation of Issues categorised in multiple Sectors is not implemented properly. In the D6 version Issues with multiple parents were handled via "Related Terms" as for this Communicable Diseases issue : http://infoasaid.org/admin/content/taxonomy/edit/term/1403?destination=admin%2Fcontent%2Ftaxonomy%2F12

However in D7 now Messages need to have 2 taxonomy terms : Issues and Sector which aims at reproducing the behavior, however this is not logically correct as it's not messages that should be tagged this way with 2 parent sectors but Issues themselves.

An example to illustrate. If Communicable Diseases is moved to be only part of Health (instead of Health and WASH) then all Threats/Messages tagged with the Communicable Diseases Issue should be displayed with only Health. This should take one change in the Issue entity, rather than going through all Threats and removing the WASH taxonomy term (as you'd have to do now by editing Threats like here http://hri.infoasaid.org/threat/cholera/edit)

It seems we could use the fact that Taxonomies terms can have multiple parents (as I did here as an example http://hri.infoasaid.org/issues/communicable-diseases/edit) and reproduce the same behavior this way. This would mean adapting the Attachment display of the Threat View (which should not be that difficult), as well as doing something smart with the import (which I is much harder and I guess is the reason why this is implemented this way).

Can you work it out so that we keep the data structure the way it was in D6?

[sn00011]

I'll take a little time to understand this and see what i can do.

[sn00011]

I've never recognized that the sector terms are used to categorize the Issues terms. The nested issues terms are very painful in many places, for example, when doing the feeds importing we need to take much effort to maintain the parent-child relationship.

After taking a look at the sector and issues terms, i am wondering if we could we split the sector terms from the issues terms. After that the issues vocabulary could only hold issues terms, and sector terms will be moved to the sector vocabulary. And the issues terms won't be a nested tree anymore. The parent-child relationship can be maintained by a new term reference field like 'field_issues_sector'.

I don't know if this idea is good for you. Please tell me how you think.

[jmatsushita]

Hi Kurt, yes if this will allow to maintain the relationship then I agree that a new term reference field on the issue (which is a taxonomy term not a node) should work. However the difficulty I can foresee is how then this would work for the advanced search? Right now the "Issues" advanced search criteria is just the normal taxonomy 2 level tree, how would you handle this? Also remember there is a feature (when you click on "Sectors" just below the "Issues" title) to switch to a flat alphabetical view. How easy will it be not to break this functionality?

[meeles]

Hi kurt Can you answer Jun's question please?

[meeles]

Kurt, Any news from your side?

[meeles]

Hi Kurt, This is an urgent issue now. Please can you resolve this asap. Thanks

[jmatsushita]

Bump

[tseropian]

Implementing the views : https://github.com/humanitarianresponse/message_library/commit/c53d9b2f437f25ba9359ec207f668c946e4a7ab7 Need to finish importers

[sn00011]

Hi, @jmatsushita, i took the approach as described in my this comment, I've also solved the issues you predicted:

However the difficulty I can foresee is how then this would work for the advanced search? Right now the "Issues" advanced search criteria is just the normal taxonomy 2 level tree, how would you handle this? Also remember there is a feature (when you click on "Sectors" just below the "Issues" title) to switch to a flat alphabetical view.

I'll explain this a little more later.