Uploaded image for project: 'Product Roadmaps'
  1. Product Roadmaps
  2. MMF-339

Rewrite Settings WS and pages

    XMLWordPrintable

    Details

    • Type: MMF
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Labels:

      Description

      Context

      In SonarQube, settings can be specified at 3 different levels: Global / Project / Module.
      The settings are defined thanks to @Property annotations either in server or in plugins code.
      Most of the settings pages are generated directly from their definition and are based on RoR web-services.

      WS Requirements
      • RoR:
        Drop / replace RoR-based web-services (ref. to MMF-286)
      • Usability:
        WS must support properties with multiple parameters and multiple values but should abstract the key/param underlying mapping (key.id.param=value) in order to stay simple.
      • Scope:
        WS must validate the scope of the properties (Module/Project/Global/Unspecified) and, this way, restrict the domain for which a property can be set.
        Considering some specific usages of properties (e.g. for views), WS must also allow configuring a property which is not defined by an annotation.
      • Visibility:
        As the scope of a property should be used to specify its domain of application, a new "visibility" attribute has to be supported to decide whether the property should be displayed or not.
        By default,
        • if scope is Module/Project/Global, visibility should be considered as "True" (setting is displayed),
        • if property scope is not specified, visibility should be considered as "False" (setting is not displayed).
      • Inheritance:
        • WS must support getting the value of a property from different levels:
          1. from module level if specified,
          2. else, from project level if specified,
          3. else, from global level.
        • When specified, the value of a property doesn't extend but replaces any value(s) that can be specified at the upper level (even in the case of multi-valued properties).
      • Default value:
        WS must consider as default value:
        1. at module level: the value set at project level if any,
        2. at project level: the value set at global level if any,
        3. otherwise, and at global level: the default value set in the property definition if any.
      • Property relocation:
        WS should support relocating a property (change of key).
      • Authorization:
        WS should check user permissions at project and global levels:
        • to get, set, update or delete the value of a property at project level, user must have project administration or system administration right,
          Note: As a first step, project browse permission will not allow to read a property at project level. This could be handle in another MMF.
        • to get, set, update or delete the value of a property at global level, user must have system administration right.
      UI Requirements
      • Redesign "Settings" spaces, decreasing the number of levels in the UI in order to allow a quick and intuitive access to the different settings.
      • Possibly re-organize the settings, changing their scope,
        e.g. "Default user group" property can be hidden in "Configuration->General->Security" and used in "Security".

        Attachments

          Issue Links

            Activity

              People

              Assignee:
              christophe.levis Christophe Levis
              Reporter:
              fabrice.bellingard Fabrice Bellingard
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved: