pvillard31 commented on PR #10275: URL: https://github.com/apache/nifi/pull/10275#issuecomment-3257464432
Thanks for the review @exceptionfactory. My use case is the following: I have version X that comes with NiFi OOTB, then I add a version Y of that NAR using the nar-manager API., In my flow, I have an instance of the processor version Y. If I force delete the NAR (version Y) using the nar-manager API, then the component becomes ghosted and I have no option to switch it back to version X. This change is letting the UI know that it should show the change version option and let me switch back to version X. This boolean `multipleVersionsAvailable` is only used by the UI as a hint to determine whether or not "Change Version" should be shown in the contextual menu of the component. One could argue that if you have a ghost component version Y, and a bundle with the same coordinates except for a version X, you do have multiple versions in NiFi at this point in time. With this change, on the ghosted component, I can right click and change version to X, and once done, if I right click on the component, I won't see Change Version anymore. I have not evaluated another approach but I guess we could imagine a completely new field that has a better meaning and make changes in the UI to use that new field but I really don't think it makes much sense as this current field would not be used anymore... So it would be kinda renaming with deprecation I guess... I have not looked into adding a system test for this scenario but I can definitely look into adding one if you think this is valuable. Let me know your thoughts. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
