CzechIdM - extras

CzechIdM - extras contains various features, which are not suited to be in any other module. List of the currently supported features is below.

Currently supported CzechIdM version : 10.4.9

https://github.com/bcvsolutions/czechidm-extras

How to develop a new feature in extras:

• Create a specification page in private section and consult it with module owner and other colleagues. Specification page should contain:
  • Usecases - why we or user need this feature, what problem does it solve?
  • Why is it in extras and not in core, or other module?
  • Functional specification - how should it work, edge cases
• Ask a module owner, if this feature can be a part of extras and in which version it will be published
• Create ticket in Redmine with final requirements and with correct target version
• Implement the feature in a separate GIT branch
• Create merge request to develop or LTS version
• Get someone from product team, or module owner to review your changes
• After successfull review, ask module owner to merge you code

Rules for code review:

• All new features have at least 80 percent test coverage
• All features are documented (tutorials are welcomed and may even be required if the feature is complicated)
• There are no sonar issues in commited code
• Changelog is updated
• Feature is by default turned off (can be enabled either by processor, or configuration property)

• When developing, use our standard gitflow:
  • Branch per feature. Branch naming as usual.
  • Develop on top of the develop.
  • Master branch contains tagged releases.
  • The only way for code to get into master is by pull request develop → master.
• Release process
  • After merging all features wanted for the release, one (selected) developer builds the develop. If it builds fine and tests are also OK, the developer edits module version in pom.xml and package.json files and sets it to X.Y.Z.
  • Developer creates pull request on GitHub to merge develop → master.
  • Repo admin (or any other authorized user) reviews the pull request, can request changes if necessary. Unresolved TODOs, missing comments, bad codestyle or documentation, suspected bugs, etc. - all those things can be grounds for change request.
  • If the pull request is OK, repo admin merges it.
  • Repo admin creates a new release in GitHub interface, version is set to X.Y.Z to correspond with version set in project sources.
  • Repo admin pushes release into BCV Nexus.
  • After release, repo admin makes changes on the develop branch: upps module version to X(+1).Y(+1).Z(+1)-SNAPSHOT in the pom.xml and package.json. What the next version of the module will be is up to discussion preceding the release.

Documentation is available here: Systems - Import of data from CSV

Documentation is available here: Automatic role definitions - Import of data from CSV

Since module version 1.9.0. Documentation is available here: Automatic role definitions - Import all rules

Documentation is available here: Assign roles to contract EAV - Import of data from CSV

Documentation is available here: Roles - Import of data from CSV

Documentation is available here: Automatic roles - adding role by node in structure

Documentation is available here: Status task - How to prepare the task Information about content is here: status_task_content

Documentation is available here: sso_authentificate

The tutorial is available here: Provisioning - how to force provisioning for roles

This feature enable that if you are guarantee at least for one role then you will see all users and you can assign/delete/edit roles for which you are guarantee. You can see all user's roles but you can't change the others for which you are not guarantee

For correct behavior you need to configure three new evaluators to userRole:

• IdentityAccessForRoleGuaranteeEvaluator
• IdentityRoleAccessForRoleGuaranteeEvaluator
• RoleRequestAccessForRoleGuaranteeEvaluator

Other thing you need to do is to enable service ExtrasIdmConceptRoleRequestService. This service is by default turned off in extras module. Go to your project modul and create new service which will inherit from ExtrasIdmConceptRoleRequestService and add annotation Primary and Service.

Update IdmConceptRoleRequestDto is allowed everybody that will change only audited fields or systemState field (this is for update state of whole request after retry mechanism or approving virtual request).

Report will compare value of attributes with connected system. Connected system does not need to be in read only. More information is available here: Report - Compare values in IdM to system

A notification about the end of identity's last contract will be sent to those who have a specified role assigned and optionally the manager of the user. A different notification can be sent before the contract ends and when it ends. More information is available here: Notification - the end of identity's last contract

Edit: full IdmIdentityDto was added for use in a template in 1.7.0

Edit: Support for technical identities added for use in version 1.9.0

Almost every project receive all titles in one string and IdM allow separates titles before and after. For this case was created in ExtrasUtils two methods getTitlesAfter and getTitlesBefore. And transformation scripts extrasGetTitlesBefore and extrasGetTitlesAfter, transformation scripts calls method from utils.

Dictionary with titles can be setup by configuration properties. Default values exists in BE

idm.sec.extras.configuration.titlesAfter=Ph.D.,Th.D.,CSc.,DrSc.,dr. h. c.,DiS.,MBA,LL.M.,FESC,MHA,FEBO,FESO,FEBU,FACC
idm.sec.extras.configuration.titlesBefore=Bc.,BcA.,Ing.,Ing. arch.,MUDr.,MVDr.,MgA.,Mgr.,JUDr.,PhDr.,RNDr.,PharmDr.,ThLic.,ThDr.,prof.,doc.,PaedDr.,Dr.,PhMr.,MDDr.

You can use this tool to create automatic roles which are assigned based on the position within the organization structure using a CSV file as a source. More information is available here: Automatic roles on tree nodes - import data from CSV

Since module version 1.4.0 was exists better workflow for groups synchronization than in core. This workflow has same features as product. In product will be available same feature as this workflow but with configuration from GUI.

Documentation for configuration is available Systems - Groups synchronization workflow.

Setting this workflow (extrasDisableMissingContract) as workflow for action in contract reconciliation will disable contract, when its being synchronized. It can be used for example, in situations when contracts are being deleted from source data after expiration and they keep being stuck in MISSING_ACCOUNT state.

Note: When using this workflow, please consider the possibility that the contracts may "reappear" in the source data. In such case, it would make sense to enable the contracts again, e.g. by mapping the attribute "state" and filling it by value null (= active contract).

Since module version 1.8.0

Documentation is available Systems - Manage groups membership in multi domain (cross domain) AD environment

Since module version 1.9.0. Available only on LTS version!

Documentation is available there

Since module version 1.9.0. Available only on LTS version!

Documentation is available there.

Since module version 1.9.0 and 2.4.0

Documentation is available there

Since module version 2.4.0.

Documentation is available there.

Since module version 2.3.0

Documentation is available there