Description Johan Van Noten 2015-02-06 05:31:32 EST

Example scenario:
* Create a profile with the intention of extending another profile.
  A common case is stereotype MyRequirement with a generalization link to SysML's Requirement stereotype.
* Create a model with a few elements with MyRequirement applied to them.
* Create a requirements table
--> The table ignores the MyRequirements elements since its tests exclusively for the Requirement StereotypeApplication. This is annoying, since all MyRequirements are also Requirements, so it would be usefull and possible to host them in the same table.
(Problem also mentioned in bug #435276.)

Suggested behaviour:
* The synchronized table collects all Requirements and all specialized stereotypes.
* This issue is not specific to Requirements but to any case where a element "filter" needs to be implemented for a specific synchronized table.

Potential code changes (not validated):
Today, the RequirementAxisManager accepts a "String elementId" as a parameter to canCreateAxisElement (and similar methods). That limits the implementation of those methods to an exact string comparison with the supplied element type.
It could be useful to change the type of this parameter (in org.eclipse.papyrus.infra.nattable.manager.table.INattableModelManager) to "IElementType".
* This way, the implementation could use ISpecializationType's isSpecializationOf (in case the supplied type is a ISpecializationType).
* Alternatively, without breaking the interface, one could go for getElementType(elementId) and check the same isSpecializationOf.