{"version":"2.1.271","anchor":"managedenterprise-plugin-bindings-can-now-override-the-plug","canonical_anchor":"managedenterprise-plugin-bindings-can-now-override-the-plug","heading":"Managed\/enterprise plugin bindings can now override the plugin order and enabled set","tier":"internal","area":"Plugins","scope":null,"heads_up":null,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.271\/e\/managedenterprise-plugin-bindings-can-now-override-the-plug","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.271","markdown":"### Managed\/enterprise plugin bindings can now override the plugin order and enabled set\n\nManaged enterprise settings can now directly override which plugins are enabled and their load order\n\n**Unclear.** What `uft()` is or how it gets configured (e.g. managed\/enterprise policy) isn't stated in the evidence.\n\n**What**\n\nThe functions that determine which plugins are force-enabled and in what order plugins load (prepend\/append order) now first check a new source, `uft()`. If it returns a value, its managed plugin ids and order are used directly, instead of the previous behavior of reading from policy settings or user settings.\n\n**Why**\n\nThis gives whatever configures `uft()` \u2014 likely a managed or enterprise deployment mechanism \u2014 direct control over plugin enablement and ordering, overriding what would otherwise come from policy or user settings.\n\n- Area: Plugins\n- Tier: Under the hood\n- Useful: 2\/5\n- Signal: 2\/5"}