Deleting of old terms, where changes had been proposed

Terms coming from an import always overwrite corresponding existing things inside translate5. The systems where the imported terms come from are considered as leading systems (this is status quo before TRANSLATE-1273).

With TRANSLATE-1273 and its subtasks for terms where changes to existing values are proposed a new term had been created and linked to the old one. So both coexist in the DB (see TRANSLATE-1275 and TRANSLATE-1365) .

Therefore on import time we need to make sure, that the old term or attribut gets deleted, as soon as the new one is imported with a status unequal "unprocessed".

Example:

• The term "Haus" had been in translate5
• Someone proposes to change it to "Hütte"
• Therefore in the translate5 DB a new term "Hütte" is created with the status unprocessed and linked ot the existing term "Haus" (and TRANSLATE-1365)
• Now a TBX is imported, that contains "Hütte" with a status unequal "unprocessed"
• This means, all attributes of "Hütte" in translate5 are overwritten by the import TBX and the status inside translate5 is now unequal "unprocessed".
• As a consequence "Hütte" is now no proposal anymore and "Haus" must automatically be deleted.

Attribute processStatus on tbx import

Make the default attribute processStatus configurable (zf_configuration) on tbx attribute import.

New import flag to delete proposals 

In addition a new import flag for the import config is created:

• Also delete term proposals
• This flag is disabled be default
• This flag can only be activated in the GUI and evaluated in the termimport config, if a date "delete terms older than" or the flag "delete terms older than current import" are set.
• If the flag is enabled, term proposals that fit for the deletion criteria are also deleted. If not, they are not deleted.

Merge proposals with termEntries of existing terms

In the first version of this issue we had the following definition:

Imagine the following case:

• A new termEntry had been created for a proposal in the TermPortal
• The responsible person (that works with the leading terminology system (not translate5) from which the import TBX comes) decides, the proposal is ok, but it belongs to another existing termEntry (where for example the language of the termEntry had not been present so far)

This means, if on import time a term PROPOSAL (not true for terms in other status) is found but it does not belong to the same termEntry as the one that is currently imported, than simply the termEntry of the proposal gets merged into the termEntry that comes from the import. The IDs of the import stay, independent if they preexisted in translate5.

After discussions during the implementation we decided, this makes things really complicated and we can not care for every situation, that may be produced by users. In normal imports "merging" of terms merges the imported termEntry into the existing one and keeps the termEntry-ID of the existing one. To do the contrary with term proposals simply makes things complicated and hard to understand for the user and hard to implement every case correctly.

Therefore if a term proposal from translate5 should be moved to another termEntry within the leading term-system (not translate5) and it should be ensured, that this term does not lead to the merging of termEntries on re-import, that do not belong to each other, the term proposal that gets moved to another termEntry must be deleted in translate5 before re-import.

So the definitions from the first version of this issue that are commented above are not implemented.