Changes between Initial Version and Version 1 of Ticket #10285, comment 13
- Timestamp:
- Sep 19, 2013, 12:14:01 AM (11 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Ticket #10285, comment 13
initial v1 1 1 In #11272, I've stumbled into an implementation of what Rémy suggested in comment:2, modifying `OrderedExtensionsOption` to raise a `ConfigurationError` if it can't find the named implementation of the interface. Since [browser:/tags/trac-1.0.1/trac/config.py@:693-697#L679 ExtensionOption raises an AttributeError] when the specified implementation of the interface can't be found, I couldn't see a reason that `OrderedExtensionOption` should behave differently. However, if we want to preserve the existing behavior for the sake of maintaining consistent behavior of the API, then adding a `require` parameter seems like a good solution. 2 2 3 In Trac, `OrderedExtensionOption` is used for: [browser:/tags/trac-1.0.1/trac/ticket/api.py@:170#L160 "[ticket ] workflow"], [browser:/tags/trac-1.0.1/trac/perm.py@:317#L303 "[trac] permission_policies"] and [browser:/tags/trac-1.0.1/trac/web/main.py@:95#L83 "[trac] request_filters"]. My starting point for #11272 was trying to catch errors in the configuration in order to make it easier for users to work with !AuthzPermissionPolicy, and for the `workflow` and `request_filters` options as well I can't see a reason why Trac shouldn't raise an error if one of the extensions isn't found. Silently failing to apply the extension just seems likely to make typos in the option value more difficult to debug, and lead to situations like the one discussed in this ticket where Trac may not be applying the permission policy, request filter or workflow controller that the user is expecting.3 In Trac, `OrderedExtensionOption` is used for: [browser:/tags/trac-1.0.1/trac/ticket/api.py@:170#L160 "[ticket-workflow] action_controllers"], [browser:/tags/trac-1.0.1/trac/perm.py@:317#L303 "[trac] permission_policies"] and [browser:/tags/trac-1.0.1/trac/web/main.py@:95#L83 "[trac] request_filters"]. My starting point for #11272 was trying to catch errors in the configuration in order to make it easier for users to work with !AuthzPermissionPolicy, and for the `workflow` and `request_filters` options as well I can't see a reason why Trac shouldn't raise an error if one of the extensions isn't found. Silently failing to apply the extension just seems likely to make typos in the option value more difficult to debug, and lead to situations like the one discussed in this ticket where Trac may not be applying the permission policy, request filter or workflow controller that the user is expecting. 4 4 5 5 The result per all of the testing I've done done is that if the component providing named implementation of the interface is not found, everyone is effectively locked out of Trac through the Web interface:
