You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
ZIM names must be unique to a single recipe, no matter the warehouse path / offliner in use, to avoid conflicting / overriding recipes and hard to debug situations.
Even when ZIMs are published to distinct warehouse path, I don't think that have conflicting names can bring anything good.
We need to be able to detect that issue at recipe configuration time and prevent such configuration from being saved, based on currently configured recipes. I.e. fail with something like "you cannot use this ZIM name which is already used by this recipe".
The corollary is probably that we must change / remove the ZIM name at recipe clone time, because this is the typical situation where we create a conflict, and should the editor forget to modify this setting, then we have conflict / overriding recipes.
This will not save us from a recipe overriding a ZIM which has been manually uploaded or created by a deleted recipe, but this last case is probably very rare and very hard to diagnose by the machine (and we might want to do it intentionally).
The text was updated successfully, but these errors were encountered:
ZIM Name is the readable identifier of the ZIM (along with Publisher and Flavour). It is already agreed that those should be unique.
Indeed simply removing ZIM name when cloning will be a huge win for a minimal effort (exact field setting name must be identified for all offliners though) 👍
ZIM names must be unique to a single recipe, no matter the warehouse path / offliner in use, to avoid conflicting / overriding recipes and hard to debug situations.
Even when ZIMs are published to distinct warehouse path, I don't think that have conflicting names can bring anything good.
We need to be able to detect that issue at recipe configuration time and prevent such configuration from being saved, based on currently configured recipes. I.e. fail with something like "you cannot use this ZIM name which is already used by this recipe".
The corollary is probably that we must change / remove the ZIM name at recipe clone time, because this is the typical situation where we create a conflict, and should the editor forget to modify this setting, then we have conflict / overriding recipes.
This will not save us from a recipe overriding a ZIM which has been manually uploaded or created by a deleted recipe, but this last case is probably very rare and very hard to diagnose by the machine (and we might want to do it intentionally).
The text was updated successfully, but these errors were encountered: