Provide a public API (as part of the Aha! REST API) which can be authenticated against using an Ideas Portal SSO token (JWT) the same way as we do authentication for the web version of Ideas Portal. This means the API's logged in user would be an "Ideas Portal" user rather than an "employee"/"application" user. The API should support at least the following functions:
List ideas viewable to the current user, with pagination and filters such as category, specific IDs, ideas created by me, etc.
Retrieve details of a specific idea
Create an idea
Edit an idea (that was created by that user)
Attach a file to an idea
Vote for an idea / Unvote for an idea
Subscribe to an idea / Unsubscribe from an idea
Comment on an idea
Our scenario is that we have both a device client and a web client. While our customers (businesses) have access to both the device and the web versions, the employees of our customers will commonly have access to only one or the other, based on the types of features they need access to. We want to be able to gather feedback from both device users and web users. Currently we are looking at embedding the web version of Aha! Ideas Portal into our device client (app), however this comes with various challenges such as:
Due to the browser support of Aha! Ideas Portal, some older devices used by our customers are not supported and cannot perform basic functions such as filtering, voting or creating an idea
Even for browsers which do currently work, this method of embedding the Ideas Portal inside our app is not something officially supported by Aha! and so we are not able to guarantee to our customers that it will continue to work. Additionally, there are some specific (minor) bugs even now which we are unable to work around
Aha! Ideas Portal does not support editing the description of an idea on Android devices currently
Any messages we display to our customers based on the actions inside the web version of Aha! are unstable as they rely on HTML IDs of your elements inside Ideas Portal which could be changed at any time
By having an API which allows users to authenticate as a portal user and take the same actions they can currently take in your web interface, we could build a bespoke UI to access the Ideas Portal within our device client, and hence avoid issues such as the above.
NB: One approach we could seemingly take would be to utilize the email parameter on the existing APIs where an action can be taken "as" a specific portal user. In that case, authentication would still be for the entire API client application, rather than the portal user. This option would be significantly less preferable to us, as would require a server call to our servers for every request as our servers would need to hold the authentication token, whereas for our preferred approach (as explained above) the authentication token would be separate for each portal user (the same way as in the web interface) and most requests could be made directly from the client to the Aha! server.