Uploaded image for project: 'Jira Data Center'
  1. Jira Data Center
  2. JRASERVER-16416

Lock project from administration changes (not use) - make it safer to do changes to various schemes

XMLWordPrintable

    • We collect Jira feedback from various sources, and we evaluate what we've collected when planning our product roadmap. To understand how this piece of feedback will be reviewed, see our Implementation of New Features Policy.

      While doing some changes to a Jira instance with several projects, I noticed the need for this. In short: A setting for the project, that would "lock" it - disallow any changes being made to the project's settings or any component it uses (schemes or components a scheme uses - such as screens and field configurations). This would ease my mind when doing changes & creating new projects and reusing components. I could "lock" all other projects than the one(s) I want to change - and receive a warning if I try to do a change that would affect a "locked" project. This way I can unlock the projects I want to change, if I know I want this change there or can create a new component and use it if I do not want the change in the locked project. (Component != Jira project component, I just could not come up with a better name for it.. "configurable element")

      I assume this is very troublesome to implement as it affects so much code. There are various ways for doing it, at least:

      1. Show all links as before but do checkings on what projects use it when updating/editing something. If the change would affect a locked project, the change would not be done but the user would be shown an error page with the listing of the locked projects (I'm thinking throwing Java error and being redirected to the edit view). This should be fairly easy to implement and also usable - checking would only require to check where the editable component is in use before proceeding, and then it could throw an error... It should not slow down the normal browsing of the admin ui, only the time when performing changes.

      2. Disable (gray out) links when projects are locked - or optionally (even better) collapse the components all together. Say the screen schemes that cannot be edited would be hidden and available for viewing using an expand-link. This, however, would probably be much harder to implement as it requires so many changes every here and there. It would also slow down the loading of all affected admin pages. This would also call for a new view for listing where a component is in use (say a screen - in what all projects is it in use?, including workflows), especially if links are only grayed out.

      3. (probably the easiest) Do not disallow editing, just warn. When editing a screen for example, it could (on top of the page) list all projects the change would affect. This, however, would be very ugly and possibly only make the UI harder to use.

      There are probably other ways to implement this also.

      At least this is where I know this is needed:

      • Issue Types Scheme (already has the warning, type 3)
      • Notification scheme editing
      • Permission scheme editing
      • Issue Security Scheme editing
      • Field Configuration Scheme editing
      • Field Configuration editing
      • Issue Type Screen Scheme editing
      • Screen scheme editing
      • Screen editing
      • Workflow scheme editing (already has the type 2 lock in older versions with the possibility to edit since 3.13, which is a feature I love btw!!)
      • Workflow editing (lock like above)
      • Group member editing (as used via permission schemes and workflow conditions at least)

      I know this is a fairly time consuming feature to implement, so I really do not expect it anytime soon. However, it would make Jira much more "safe" to use - as you could know that you do not change your active production projects.. So you could allow some superuser the right to turn on/of locks and then allow lower right admins to do changes relatively safely (that only affect their project). Heh.. the more I think about it the more features I come up with - "locks" could of course be opened per user also And.. the permission scheme could of course be the place whereto set this then..

              Unassigned Unassigned
              790cb4f9dbbe Ivar Ekman
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

                Created:
                Updated:
                Resolved: