Search code examples
jasperserver

User / Rights / Resource management: usage of ROLE_ADMINISTRATOR, ROLE_SUPERUSER, jasperadmin and more?


(We experienced quite some problems after some rather unconceptional usage of our Jasper Server rights management and like to share some insights that are not mentioned in the docs.)

Why should one not rename the role ROLE_ADMINISTRATOR, ROLE_SUPERUSER or jasperadmin?

Which defaults should apply to them?

Which other unintuitive restrictions apply to the rights management (maybe in correlation with repo folder structure, user management, resource management)?


Solution

  • (to be continued - feel welcome to edit or move to SO documentation when possible in the future)

    admin-specific:

    • The jasperserver code relies on the existance of ROLE_ADMINISTRATOR, ROLE_SUPERUSER (not there in community edition, but can be created) and jasperadmin.
      Therefore they should not be renamed.
    • users with ROLE_SUPERUSER, once created, have the opportunity to Export whole repo-trees by right-clicking on the repo folder in the GUI
    • jasperadmin should be part of ROLE_ADMINISTRATOR
    • jasperadmin (not the ROLE_ADMINISTRATOR!) should have Administrator rights on the / root node
      • otherwise the ROLE_ADMINISTRATOR does not seem to work as intended and members of it do not have admin rights

    overall:

    • if one does not have ROLE_ADMINISTRATOR he cannot upload input controls, even if he has Administrator rights on the desired folder :-(
      • that's not so nice in a multi-dev environment where a lot of devs work in different areas and should potentially not be complete Jasper Server Admins
    • in order to download/view uploaded files, e.g. PDFs, XLSXs etc. one needs the read + write privilege, because for some reason read only or execute only are not sufficient (5.2.0)
      • so it seems reasonable to create some subfolder downloads in every possible upload location that should inherit this right to its contained resources
    • the length of the internal id path of a resource is restricted to 100 (or so) characters - if you want to edit some input control that is more deeply nested (you can use it still, but not edit it)
      • thus you should be careful since this could potentially be reached faster on more deeply nested structures
      • creating a folder /_dev and then renaming it to _report-developers could, e.g. be better since the id path will stay /_dev.

    best practices:

    • (currently we feel that it may be much better to not overuse the Jasper Server GUI and rather embed the reports in a better Document Management System (e.g. Alfresco, SharePoint, WebCenter) than up-/downloading non-report resources or managing users/rights in this quite specific environment)
    • it is always good to not have user-specific rights at all, but create and think in business roles that should be named as such
    • one should ideally not think resource-specific when designing roles
      • so -ROLE_FOLDER_SALES_2016-03- is not a good practice, rather create e.g. some roles ROLE_DEPARTM_SALES, ROLE_DEPARTM_PRODUCTION and apply the proper rights on e.g. some folders sales-2016-03, sales-2015-07, ...
    • short, meaningful repo id paths for some report developer section are much recommended since e.g. input controles and other things are shown in Report Units (which are executable within the server GUI) with their id path instead of there "name path"
    • meaningful naming of input controls or/and their parent folder (to be continued)
    • naming of roles (to be continued)
    • repo tree layout (to be continued)
    • root node renaming (to be continued)

    (everything so far is experienced on JasperServer 5.2.0)