Typically when a misconfiguration is done, we end-up in a situation where we have two titles instead of one.
This is for instance currently the case for "radiozamaneh" titles:
https://cms.openzim.org/titles?name=radiozamaneh
We have two titles where in fact there is (should be) only one, it is just that ZIM name (or title) has been fixed from radiozamaneh-com_far_all to radiozamaneh-com_fas_all in Zimfarm. Here this duplicate has been badly created by the CMS population script we ran few weeks ago, because the ZIMs did existed on the file system (where they should not).
But anyway, we can end-up again in such a situation in the future, where a publisher create a new title by mistake when an existing title should have been renamed in fact.
The "natural" way to solve this is to move books from "bad" radiozamaneh-com_far_all title to "good" radiozamaneh-com_fas_all, delete the empty title and then let retention rules clean the oldest ones if needed.
Is this a new action or only a variation of title deletion expressed in #278
Typically when a misconfiguration is done, we end-up in a situation where we have two titles instead of one.
This is for instance currently the case for "radiozamaneh" titles:
https://cms.openzim.org/titles?name=radiozamaneh
We have two titles where in fact there is (should be) only one, it is just that ZIM name (or title) has been fixed from
radiozamaneh-com_far_alltoradiozamaneh-com_fas_allin Zimfarm. Here this duplicate has been badly created by the CMS population script we ran few weeks ago, because the ZIMs did existed on the file system (where they should not).But anyway, we can end-up again in such a situation in the future, where a publisher create a new title by mistake when an existing title should have been renamed in fact.
The "natural" way to solve this is to move books from "bad"
radiozamaneh-com_far_alltitle to "good"radiozamaneh-com_fas_all, delete the empty title and then let retention rules clean the oldest ones if needed.Is this a new action or only a variation of title deletion expressed in #278