Multiple questions on new EP5 Users Administration

[Ryan_Wakefield]

While looking more details at the new EP5 Users Administration section, I noticed that it is very skimpy in a lot of areas and missing options in others. So I wanted to put out there some questions regarding it.

1. I noticed that when you get a list of users for a specific user group, or a list of user groups for a specific user, you only received back the ID numbers for those items. Because we only get the ID numbers back, we now have to execute a second query for "Get a specific user." to find out who exactly that user is or we have to run the "Get a specific user group." to find out what user group that is exactly. Why were the details surrounding the name of the User Group or the details of the User that is returned not included in the main method?
2. Secondly, I noticed that when you want to query for a specific user, the only option is to query for them based upon their User ID number and if you don't have that number, you are kind of SOL. Is there a reason an option wasn't included to query for a user by their Username or even email wasn't included?
3. When you are going to create a new user, the options to set on the user are really limited. What was the reasoning behind not opening up the options to set the user as a Service Account or that the account expires after X date?
4. One extremely big variable in my mind that is missing from the "Replace an existing user" method is the option to disable a user. I can't believe that this variable was left off of this release as this is kind of a crucial feature that is missing. Can you explain why this was not added during this initial release with the ability to enable/disable an account being something so core to OnBase?
5. It seems to me that the initial release of this administration of the Users section was primarily target at customers that utilize OnBase authentication. Why was it target at what I would imagine is such a small piece of the overall pie of customers where I am assuming use some sort of AD - Enhanced or LDAP authentication?
6. My final question is based upon my previous 5 questions above. With the initial release of this functionality being so limited, is there any chance that you will be releasing a version 2 of the REST API that will add in the functionalities as explained above? I ask this because while I absolutely love the fact that users can be administrated through the REST API now, it doesn't do me much good with it missing so many pieces.

There are other things I want to bring up surrounding the methods under the "Users" grouping, but this is just the start and I figured it would at least get a discussion going surrounding the future of this section of methods.

Thanks.

[Tyler_Conn]

Hey Ryan,

Great questions as always.

To more broadly answer some of the items below, the ultimate goal of these administrative APIs is to support the modern configuration screens, which are actively being built out for EP6. The scope of the configuration options that we have made available through the APIs is very specific to those used most often by the administrators in a hosted environment. While we are ultimately building these APIs out for EP6, we wanted to provide some of the endpoints which were already completed with EP5 in an attempt to be more continuous with our deployments. Items such as Account Expiration, Service vs Regular Accounts, and locking/unlocking user accounts are all within scope for our configuration screens, and you should absolutely look for this in subsequent releases of our Admin APIs. The backporting of these APIs has yet to be determined but is very much limited by our bandwidth as we push forward with other initiatives for EP6. 

Digging into two of your more specific questions below, we are following Hyland's standards for base item retrieval, meaning returning the most streamline, yet informative objects that can support the UIs. There is absolutely a balance here between too much info and not enough (i.e. name may be a great candidate to add in the future but the entire user object would not), while keeping our primary goal of being as performant as possible in mind.

We are actively looking into an enhancement to our framework called Expand Parameters, which would allow you to say "Give me all users and their emails/real names", however we expect some performance hits with these optional endpoints. I do not currently have an ETA on when you can expect this enhancement to be added.

As always, feel free to fill out an Idea on the Ideas Portal for enhancements that you see as being valuable to add in future releases. Calling out anything you believe we missed or use cases you'd like to see covered would be extremely valuable for our future development efforts.

Hopefully that provides some additional clarity. 

Tyler Conn
Product Owner
Configuration Services and Change Control