In #1449 (closed) we added a CSV export option for instance-level audit events. This is a feature that's required for customers who rely on ingesting this data into their own systems and generally for sharing with auditors as an evidence artifact.
Thank you @mattgonzales, I assumed that the project audit events would aggregate up into their respective group level audit events, where perhaps Program Management level type roles would be able to view the aggregated events from across the different projects under the group. I thought perhaps for roles at the Project level, they too would be able to review audit events for just the project they may be responsible for, and therefore be able to export the events at the project level. Is another issue needed to capture project audit events exports?
I assumed that the project audit events would aggregate up into their respective group level audit events, where perhaps Program Management level type roles would be able to view the aggregated events from across the different projects under the group.
@laurie_howitt That's where we're heading, so you're exactly right 😄
Is another issue needed to capture project audit events exports?
I believe so. I'm not aware of this issue existing already 🤔 It hasn't been previously requested by a customer, in the conversations I've been involved in, so it's not something we're actively tracking. If you've received that request, let's certainly capture it in an issue 👍🏻
@mattgonzales I've created this issue for project level export to CSV on gitlab.com, #262645. Not sure if you want to relate them to each other, but will leave that to you.
@laurie_howitt Thanks so much! I'll go ahead and relate them and also add both to %Awaiting further demand. If you or other CS team members could help link SF links in the comments to help indicate demand, that will help a lot with determining priority 😄
@mattgonzales I've shared the Audit Events API with my customer who was able to access the API. With the API producing JSON output, they're unable to consume for review and searching. There is free JSON to CSV converters out there, but these can be problematic. Customers response was:
This seems to be a stop gap arrangement / workaround.
We would require an option to either download a CSV files of the logs or somehow make it visible on the UI itself.
(similar to feature request : #8137 (closed) )
As the process of converting the Json to CSV file will be an overhead for the admin team.
This would be also problematic in case we have large number of audit events - here it becomes difficult to use the free online tools for JSON to CSV conversions.
@tancnle What's your opinion on the effort involved for an issue like this?
Given the work of the working group focused on simplifying groups and projects and the competing need of customers to have this capability on SaaS, I'd like to walk through this discussion and get your input 😃
@mattgonzales The effort to replicate this CSV export feature on Group should be trivial. The current problem we face, however, with CSV export is around the performance degradation when downloading large amount of data. We have two issues trying to tackle it (#266976 (closed) and #246742 (closed)) and I am actively working on those.
Are you aware of this issue from @asubramanian1? Could we reach consensus on a particular export that might circumvent or alleviate the performance concerns or are the two issue you're working on a separate effort altogether?
Yes, I did. #266976 (closed) helps to improve DB query time which will be beneficial for both stream and background job + polling approach. In other words, it is complimentary to any approach chosen in #257951 (closed) for Audit Events.
#246742 (closed) is figuring out if streaming is a feasible choice. We can regroup on the evaluation issue and decide which path to take for Audit Events. I can already see some favourable opinions on the background job + polling approach, so might be that something we could commit to.
@tancnle, @mattgonzales, is there enough information/consensus on a way forward now that could see this feature be assigned to a particular release perhaps?
@tancnle Thanks so much for the review and feedback. That's really helpful context 😄
@laurie_howitt I think we're too early in our assessment to commit to a milestone. I think we should wait for the outcome in #257951 (closed) to avoid having to work on this implementation twice since we already know there are limitations that will require a follow-up.
I'm happy to be proven wrong, however, if the engineers think it's a non-issue 😄
I agree, we should probably wait until we settle on a generalized CSV export approach. Right now we're doing both email and polling, and I'd like to standardize on a single approach so there is less to refactor later.
Also, there's a performance concern at the project level that obviously only gets larger at the group level. @tancnle is making some improvements that make performance manageable at the project level (example), but we need to evaluate whether it's possible to make it manageable at the group level. This is a BIG data table.
@djensen Could we use multiple approaches? I was thinking about two scenarios:
Exports of up to 30 days could use persistent polling
Exports 31+ days could use emailing a link
My understanding is we're trying to preserve the in-app experience and prevent having a user switch contexts to obtain the data they need, but it's also a pretty common experience to receive a separate url via email for large exports.
I guess my question is: what are our decision factors to decide when and how to commit to a particular implementation? Maybe this is a question for #257951 (closed)🤔
@djensen Gotcha. From my perspective, it seems like one approach isn't likely feasible because I think what I'm understanding is we're still trying to navigate the challenges of underlying database performance issues. Is that a fair assessment?
Maybe I'm not close enough to the deep dive on this though, so my apologies if that's a bad assumption 😄
@mattgonzales I think the database performance issues exist in any context. Emailing, polling, streaming - the database queries can be big and scary with any of those. Regardless of the download approach, we probably need to query in batches behind the scenes.
@djensen Makes sense. Is that something that could be solved by some "magic wand" scenario to change our database infrastructure? Or is this an inherent challenge given our volumes of data?
I'm just trying to figure out if we need to pursue another database change or not 😄
@mattgonzales if there is a magic wand, we have more than a few wizards around here who can wave it! ✨ But I think in this case we just need to be clever about how we're querying.