Feature Request
MidPoint development team regularly receives requests to enhance midPoint features or to create a completely new features. We are very grateful for such requests. But the capacity of the development team is naturally limited and as hard as we try we cannot satisfy all the requests immediately. However, the way how the request is formulated and requester’s participation can greatly influence the outcome of the request. Following types of requests will always take precedence:
-
Request from a partner that is covered by appropriate support agreement, from midPoint project subsciber or from a strategic partner (requester is supporting the request by money)
-
Request for which the requester is willing to help (requester is supporting the request by his own effort)
What I Can Do?
Obviously you can donate money to the team or support the feature development that you want to see implemented by activating Platform subscription. But that is not the only way. You can invest your own time and expertise instead.
This is what you can do to improve the chances that your feature gets implemented:
-
Write down a detailed use case
-
Communicate with the developers
-
Test the feature (in the development version)
-
Repeat steps 2 and 3
Write Down Detailed Use Case
Think about your use case in midPoint terms. Think what is already there in midPoint to implement your use case. Think about the things that are missing. Try to share your rough ideas on midPoint mailing lists. Try to figure out what exactly do you need. Once you have that then write it down. The best way how to write it down is by describing a scenario - a user story. It looks like this:
-
Ordinary user logs into midPoint web interface
-
The user goes to the "self service" part of the interface, he can see his existing accounts and roles
-
There is also "Request new" button. User clicks on that button.
-
MidPoint provides a list of requestable roles to the user. Use chooses one or more roles. And clicks "Request" button.
-
MidPoint will start processing any rules and policies.
-
If there are no approvals or other synchronous tasks the roles will be provisioned immediately while user waits (up to a couple of seconds).
-
If there are approvals (or similar reasons) the user will be informed that his request is being processed and that he will be informed about the outcome.
-
-
MidPoint provisions accounts/entitlements according to the role definition(s).
-
MidPoint send a mail to the user informing him about the outcome of every operation [sample of mail message attached].
Please make sure that you think about your use case. Try to go over the scenario several times in your head. Think about details, such as "can user choose more than one role?". Try to simplify the scenario as much as you can.
Providing rough user interface sketches, diagrams, samples or flowcharts also helps a lot. We do not require anything fancy. Simple photo of a sketch on paper or whiteboard is OK. Actually, that’s exactly the way how midPoint team often communicates internally. Therefore we are used to it.
Please, try to be exact and practical. Your scenario is an input to the designers and developers. But much more importantly: it is an input to create a test case. If you are vague in your description then midPoint developers can interpret the details differently and the new feature may not work for your exact situation. If you are exact then you save a lot of time during testing and deployment.
Communicate with MidPoint Team
Keep in touch with midPoint team. Watch appropriate isses in the issue tracking system to follow the progress. Look through git commit logs. Send mails to developers with additional ideas or feedback from your testing. If you request a feature we expect you to be active. We expect you to take part of the management task to get the feature done. Do not be afraid about asking too much or too often. Our development process is open, we have nothing to hide. And we like to communicate.
Test The Feature
Do not hesitate with testing. Start as soon as possible. Once the feature starts to take shape it is a good time to start testing. Ask the developer when it is the correct time. But be sure to start early. We love feedback early in the development. This is the time when it is easy to change things. The developer may also be slightly lost especially if the feature is quite new and unique. Your early feedback can help a lot. Therefore start testing as soon as possible. Use midPoint Development Snapshot for testing.
Make sure you test the feature reasonably well and do it quite ahead of planned midPoint release date. Things are easy to change before our feature freeze date which is usually 2-3 months before the planned release. No major functionality changes are allowed after this date. The effort between feature freeze and release is mostly dedicated to testing and bugfixing. Therefore make sure you test early. And make sure you communicate often and communicate well.
Other Assistance
If you are experienced in programming you are more than welcome to help with the code. Especially if you can fix the bugs while you are testing. It is not difficult to contribute bugfixes and patches to midPoint (see Development Participation).
You can also contribute the documentation. You have requested the feature therefore you should know how it works and that means you should be able to document it. Just let us know that you want to do it and we will grant you write access to our wiki.