Edgewall Software

Changes between Initial Version and Version 1 of Ticket #10285, comment 13


Ignore:
Timestamp:
Sep 19, 2013, 12:14:01 AM (6 years ago)
Author:
Ryan J Ollos

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #10285, comment 13

    initial v1  
    11In #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.
    22
    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.
     3In 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.
    44
    55The 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: