Michael Adamski
I would like to essentially copy the functionality of the `export` feature in the GROUPS tab but have it routed through `messages` such that a user finds a form, which contains scenarios which only allows for permissible and associated groups of theirs to be populated. They choose which group and submit. This will then run the functionality mentioned earlier but from my admin privileged account and send an email to them with an attachment CSV containing the contact information for the requested group with all device information being visible.
0
Comments
Please sign in to leave a comment.
Hey Michael!
What information in particular are you looking to include in that groups export? Would this be for a single group or multiple groups?
I ask because we expose all of this data via the REST API. The get members in a shift API call will show who is in the shift of a group and what the escalation details are. For each member in there, you could then use the people devices API call to get their contact details.
You would have to reconfigure things a bit to allow for this scenario as follows:
So it would require some scripting and a bit of tinkering, but it would be possible.
Does that make sense?
Happy Tuesday!
--- Travis
It does, kind of. Not entirely sure how to pull this off, especially when it comes to building the CSV file attachment which will be included in the email for downloading by the recipient requester.
Additionally, it sounds a little expensive. Let's say that a group supervisor is seeking the group information for group A, of which, we have 50 users (hypothetical). What you said above makes me think we would need to first run an API get request to retrieve all users in the group and then loop through those members, each time running an additional request against that individual member for their personal information.
There doesn't exist a more succinct API endpoint that contains all of this information?
Also, there seemed to be a bit of confusion based on my explanation of the use-case so allow me to explain a little better this time. We would be building scenarios that will pre-populate a group name in a form for request by the Group Supervisor. We only want them to have access to group member info for groups of which they are authorized to view. They would then choose the proper scenario and submit the form.
That form would run an API call which should gather all relevant information for all members of that group. Contact info, devices, shift hrs, positions etc (not positive of all the fields that are available here -- I was just brought on to the team). Then in our Inbound script, I'm assuming, I am going to want to then take the response object, parse through it, and build out a readable CSV file for the requesting Group Supervisor, then assign that to a variable which is available in a form, and include it as an attachment for download in the email which is sent out to that requester.
Does this give a clearer picture of what I am trying to accomplish here?
I'm not sure how to build the CSV just yet, but I know it's possible for sure. However, it looks like maybe you don't offer the functionality of attaching a newly created CSV file to a form -- am I correct?
If I build a CSV in an inbound integration script, what are my options moving forward? Can I host it on xMatters and provide a link for download in the proceeding email or even better, is it possible to include it as an attachment. So far, doesn't look like either are possible. Let me know thought, thanks!
Hi Michael,
It is not currently possible to build and attach a file (.csv or otherwise) as part of triggering an xMatters Event as part of an API-based call.
It may be possible to use an xMatters Agent to run the script (which runs in a VM or host that you provide), that can create a file and store it somewhere web accessible. You can then generate a link to that file and include the link as a property in the actual Trigger Event API call.
The other advantage that the xMatters Agent brings is that it does not have the 60 second execution time limit that the scripts running in a Cloud-hosted Inbound or Outbound Integration are limited to.
But, yes, from a process perspective, you would need to get the details of the shift (e.g. it's members, escalations, etc.) first, and then iterate through each user to get the device information.
The "Get Members In a Shift" API call does return direct "self" links to each member, so it makes it a little easier to request the Users details, but you do need to make additional calls to get the Device(s).
Hope that provides some guidance.
Michael, to follow up, I was investigating the Dropbox API, but the Integration Builder is appending a weird charset to the Content-Type and Dropbox rejects the API call. If I can get through this we wouldn't need the agent in the middle.
But, as Jordan mentioned, the agent could generate an actual file and then you'd need a place to put that file and generate or build a link and include that in the notification.
If I get the Dropbox thing sorted out I'll post back.
Wonderful. Both of you have been very helpful thus far. Thanks again so much and I'm looking forward to hearing about your progress on the Dropbox API project.