XWiki Platform
  1. XWiki Platform
  2. XWIKI-7845

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-10120Don't try to log IRC messages when the wiki is in readonly mode
      XWIKI-7318Importing a XAR fails to register Macros in a cluster of wikis
      XWIKI-9552Don't try to log IRC messages when the wiki is in readonly mode
      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-10958Wiki macros initializer should register macros only for current wiki at init
      XWIKI-5668Wiki macros fail to register correctly on the first import of a .xar

      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

        Hide
        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
        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
        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
        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
        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
        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
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

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