Wiki macros may be registered in two different sitautions:
- As a response to an DocumentCreated- or DocumentUpdatedEvent
- During servlet initialization.
A DocumentCreated- or DocumentUpdatedEvent is only raised after a document has been successfully saved, which indicates that the document author have edit rights.
Thus, explicitly validating edit rights when registering macros in the wiki macro manager only affects the case when the servlet is initialized. There are two possibilities that may change the outcome of the validation of edit right during servlet restart compared to when the macro was first registered:
- The server is started in read-only mode.
- Edit rights were granted when first saving the macro, but have been revoked (or the user have been deleted) when the server is restarted.
Removing the check in the wiki macro manager will thus fix this issue, but have the side effect that revoked edit rights will not retroactively remove wiki or user local macros during servlet restart.
If it is a desired feature that revoking a user's edit rights should deregister the user's wiki-macros, the deregistration should always be triggered when the users rights are updated. As it is now, the deregistration is not triggered until the servlet is restarted (unless the edit right is denied directly on the particular document that holds the macro definition).
Globally visible macros are unaffected by the "read-only" state of the wiki, since the visibility of these are controlled by the programming right, which is allowed even if the wiki is in "read-only" state.
I will for now assume that the retroactive deregistration during servlet restart is not an intentional feature and proceed with simply not checking for edit rights. If it is an intentional feature, it should be properly reimplemented.