XWiki Platform

When starting in readonly mode, none of the wiki macros are registered

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Fixed
  • Affects Version/s: 4.1-milestone-1
  • Fix Version/s: 4.2-milestone-1
  • Component/s: Old Core, Rendering
  • Labels:
    None
  • Difficulty:
    Unknown
  • Documentation:
    N/A
  • Documentation in Release Notes:
    N/A
  • Similar issues:
    XWIKI-7315Wiki macros are not registered in workspaces
    XWIKI-7318Importing a XAR fails to register Macros in a cluster of wikis
    XWIKI-4520Not possible to generate inline content from wiki macros when the macro body starts with another macro
    XWIKI-5439Log too verbose when attempting to register wiki macros with insufficient privileges (for example at wiki startup)
    XWIKI-6185In some conditions wiki macro with user visibility are not registered with the proper user
    XWIKI-4742Code Macro language option only works with the language set to "none"
    XWIKI-4633Add ability to register components only for a given user or for a given wiki
    XWIKI-5668Wiki macros fail to register correctly on the first import of a .xar
    XWIKI-8004Wiki macros with global visibility are not registered when installed as extensions
    XWIKI-7739"Current wiki" wiki macros not available in the macros list in wysiwyg in path based multiwiki

Description

To reproduce, edit xwiki.cfg and add xwiki.readonly=1, then restart the wiki. When opening the main dashboard, you'll see: Unknown macro: activity, and so on for the other macros on the homepage.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Thomas Mortagne added a comment -

I think that's because the way readonly is working as far as I remember is at rightservice level itself by returning false pretty much all the rights except view which mean that the wiki macro don't have enough right to be registered.

Show
Thomas Mortagne added a comment - I think that's because the way readonly is working as far as I remember is at rightservice level itself by returning false pretty much all the rights except view which mean that the wiki macro don't have enough right to be registered.
Hide
Permalink
Andreas Jonsson added a comment -

Wiki macros may be registered in two different sitautions:

  1. As a response to an DocumentCreated- or DocumentUpdatedEvent
  2. 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:

  1. The server is started in read-only mode.
  2. 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.

Show
Andreas Jonsson added a comment - 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.
Hide
Permalink
Thomas Mortagne added a comment -

If admin right is affected by read only state then this issue is not fixed. Don't mix global scope (which require programming right) and wiki scope (which require wiki admin right).

Show
Thomas Mortagne added a comment - If admin right is affected by read only state then this issue is not fixed. Don't mix global scope (which require programming right) and wiki scope (which require wiki admin right).
Hide
Permalink
Andreas Jonsson added a comment -

Admin rights are not affected by the read only state, but wiki scope does not require admin rights. Now when you mention it, it seems reasonable that it should, but both wiki and user scoped macros require only edit rights as far as I can see.

Show
Andreas Jonsson added a comment - Admin rights are not affected by the read only state, but wiki scope does not require admin rights. Now when you mention it, it seems reasonable that it should, but both wiki and user scoped macros require only edit rights as far as I can see.
Hide
Permalink
Thomas Mortagne added a comment -

Then it's a but since it always supposed to be admin right.

Show
Thomas Mortagne added a comment - Then it's a but since it always supposed to be admin right.
Hide
Permalink
Thomas Mortagne added a comment -

Just created XWIKI-7880.

Show
Thomas Mortagne added a comment - Just created XWIKI-7880 .

People

  • Assignee:
    Andreas Jonsson
    Reporter:
    Sergiu Dumitriu
Vote (0)
Watch (0)

Dates

  • Created:
    Updated:
    Resolved:
    Date of First Response: