N°7570 - feat(Typology): Add useful tabs to certain typology classes

[Hipska]

Base information

Question	Answer
Related to a SourceForge thead / Another PR / Combodo ticket?	N/A
Type of change?	Enhancement

Objective

When clicking on a Typology item from a linked object, it is sometimes handy to see which other objects are also linking to the same Typology object.

Proposed solution

Add tabs to the Typology objects to see which other objects are using this Typology.

Checklist before requesting a review

• I have performed a self-review of my code
• I have tested all changes I made on an iTop instance
• I have added a unit test, otherwise I have explained why I couldn't
• Is the PR clear and detailed enough so anyone can understand digging in the code?

Checklist of things to do before PR is ready to merge

• Add dictionary items when the additional fields are accepted

[jf-cbd]

Thank you for your PR, here are a few notices :)

[v-dumas]

Hello Hipska,
Have you tested the use case, of adding or removing ospatches (or any other sub-objects)?
Add means moving them from one OS version to another. When do you need to do this ? It is highly subject to errors. And if you really do, the bulk modify is much better to control your changes.
Remove means empty the osversion of an ospatch (or multiple), why would you do that? You should rather replace the osversion if it was wrong by the correct one using the bulk modify of ospatches.

As a conclusion, our policy for Typology is to propose "add_only", nothing else, which means allow sub-object creation.
For the "edit_when" option, the policy is more open, if there are no dependencies, it can be omitted, which means
you can create a sub-object in read or edition of the host.
(This "edit_mode" "add_only" should have been named "create_only")

In some case like "model" and "brand", because of dependencies and class restriction, even this "add_only" mode is nearly unusable. So me might prevent even the creation in the standard model.

Translation are missing.

[Hipska]

@jf-cbd @v-dumas You were right. It's indeed not possible to remove linked items using the add_remove mode. I was confused and actually meant to use the in_place mode.

I tried all new lists and was able to create and remove items this way:

• Brand
  • Model
  • IOSVersion
• OSVersion
  • OSPatch
• OSFamily
  • OSVersion

Translations are indeed missing. Are we sure these new lists would be accepted to be added in the datamodel? Then I will make the translations for them..

[jf-cbd]

@jf-cbd @v-dumas You were right. It's indeed not possible to remove linked items using the add_remove mode. I was confused and actually meant to use the in_place mode.

I tried all new lists and was able to create and remove items this way:

* Brand
  
  * Model
  * IOSVersion

* OSVersion
  
  * OSPatch

* OSFamily
  
  * OSVersion

Translations are indeed missing. Are we sure these new lists would be accepted to be added in the datamodel? Then I will make the translations for them..

Yes it has been functionally accepted so it will be integrated in iTop :)

[v-dumas]

@Hipska
When providing new dictionary entries, developer is expected to update the 17 translation files with the new entries untranslated but with 2 tildes ~~ at the end, so translators quickly identified untranslated entries.

[Hipska]

Hmm, in the past there was an automated tool from Combodo that did that. Why can't it be done for this here as well? It is the first time I see this to be required..

[v-dumas]

Ok, will do it ourself.

[jf-cbd]

Hey, AFAIK the other translations files are not needed, so I'll merge this PR.
Thanks @Hipska for your (Hacktoberfest) contribution !

[Hipska]

Done, no more conflicts..

[jf-cbd]

Perfect, thanks :)

[jf-cbd]

FI : The test testEveryEnglishEntryShouldHaveItsFrenchCounterpart failed, so it seems 2 languages are required, French and English.
I'll add it.