Skip to end of metadata
Go to start of metadata

Especially with LDAP authentication, it is possible to accidentally revoke all iteraplan permissions from all users. This also means nobody has the permission to create and edit iteraplan roles anymore, which is the usual way of granting permissions to iteraplan users.

A short explanation how such a "lock out" can happen:

  1. iteraplan itself does not know which roles a user is assigned to. The assignment of roles or groups to users happens, for example, in a user directory iteraplan connects to via LDAP, or in iTURM.
  2. When logging in, iteraplan asks iTURM or LDAP for the user's roles/groups.
  3. iteraplan then matches its own roles to the result of that query, using the names of the roles. For example: User Alice has the groups "Admin" and "Employee" assigned in the company's user directory. In iteraplan there exist the iteraplan roles of "Admin" and "Architect". When Alice logs into iteraplan, the group "Admin" gets matched to the iteraplan role "Admin" because they have the same name. The group "Employee" as well as the iteraplan role "Architect" are ignored since there is no match for them. Alice thus gets the permissions of iteraplan role "Admin" assigned.
  4. If somehow the iteraplan role "Admin" was deleted or the LDAP group "Admin" was renamed, for example, iteraplan can't find a match for Alice. Alice is able to log into iteraplan, but has no permissions to do anything.

A possible fix is to (possibly temporarily) create a new iteraplan role that grants a user supervisor permissions in iteraplan. This can be done by someone with access to iteraplan's database. The user can then fix the remaining roles and permissions using the iteraplan UI.

Step-by-step guide

To grant supervisor permissions to Alice

  1. Choose one LDAP group (or iTURM role, whichever is applicable) that Alice is member of. In this example the group is called Generic_Admin. In the following SQL statements, please replace each occurrence of "Generic_Admin" with the name of the actual group in your case.
  2. Check whether there exists an according role in iteraplan by executing the following SQL statement in iteraplan's database:

    select * from ROLE where NAME like 'Generic_Admin';

  3. If the statement returns a result:

    1. Check whether the name in the result set is written exactly as the LDAP group, including upper/lower case. If not, fix this and re-log into iteraplan to check whether this was the issue.

    2. If a) doesn't apply or didn't fix the issue, run the following SQL statement in iteraplan's database to make the role Generic_Admin into a supervisor role:

      insert into ROLE_ROLE (ID_SUPER, ID_SUB) values (
          (select ID from ROLE where NAME like 'Generic_Admin'),
          (select ID from ROLE where NAME like 'iteraplan_Supervisor'));

  4. If the statement does not return a result:
    1. Create the role Generic_Admin by executing the following SQL statements in iteraplan's database:

      insert into ROLE (ID, VERSION, NAME, LAST_MOD_USER, LAST_MOD_TIME) values (
          (select next_val from hibernate_sequences where sequence_name like 'role'),
          1,
          'Generic_Admin',
          'SQL',
          CURRENT_TIMESTAMP);
      update hibernate_sequences set next_val=next_val+1 where sequence_name like 'role';

    2. Make the new role into a supervisor role by executing the following statement as in 3.b:

      insert into ROLE_ROLE (ID_SUPER, ID_SUB) values (
          (select ID from ROLE where NAME like 'Generic_Admin'),
          (select ID from ROLE where NAME like 'iteraplan_Supervisor'));

  5. Alice should now be able to log into iteraplan (log out before if necessary) and have supervisor permissions.