Sitefinity Audit Trail - Feature Previews & Betas - Feature Previews & Betas - Progress Community
 Feature Previews & Betas

Sitefinity Audit Trail

  • Sitefinity Audit Trail
  • Hi all,

    We are starting the work on Sitefinity “Audit Trail Log” and would welcome you to share requirements on this feature. 

    • Have you worked on a project which required that user actions are logged?
    • On what occasions should logging occur ?
    • How do you expect to interact with the logged data (export, reports, etc.)?

      We look forward to receiving your feedback. Thanks in advance for your time!

      Regards,
      Kalina
  • Well since SF still does not have a recycle bin for pages I would love to be able to show a customer that they deleted the page and it didnot vanishing by itself.

    One thing is for sure. history of pages are filling up databases and there is no way to limit the history of pages to lets say the 10 last versions. So I would prefere an option that would let you specify how many audit trails should be kept. 

     I never had the need of an Audit Trail Log but need many other things on the feedback portal.

     Wondering if this is a feature request from the portal!!!

    Markus

     

     

  • Knowing who might have deleted a page or template is something beneficial. As Markus stated, it helps when clients say they didn't do it, or even your own team members. From a content, page, and template standpoint, having the history is important. I would be ok with the limited versions as we normally don't make so many random changes where 10 or so would be an issue. Maybe a way to spec that per site??

    Other things that would be of value are who created users or adjusted permissions. Even making changes to the settings. Right now I don't think that information is available even by digging through the DB.

    I don't have a need for an exporting feature at the momen, but a general reporting by person, action, or section would be a good starting point.

    Richard

  •  

    There are some things I would think go kind of that way but would also help but concerns more the user then changes


    1)have a log when users logged in/out (again it would be nice if we could limit)

    2)under pages show who last changed a page instead of the owner. So in teams if
    someone sees that Markus changed something John could go and talk to him.

    For me the last edited by  in Revision History is enough.


     Markus
  • Easiest thing is to take some knowledge from existing top CMS Dotnetnuke features. It has so much things you can look into.

     

  • There are important investor relations compliance considerations...

    "The Corporation will maintain a log indicating the date that Material Information is posted and/or removed from its web site. The minimum retention period for Material Information on the web site will be two years."

    This applies to ALL CONTENT... pages, files, images, documents, etc...
    The Revision History feature here is not enough... it doesn't track deletions (and it would need to retain the state / content at the time of deletion).  Also, this need to track when any type of file gets changed / get deleted.

    And, I know this isn't an "audit trail" feature specifically, but clients want to be able to diff two versions of the same document.

  • This is great. I like the idea of an audit log. Especially being able to identity who deleted a page or content block. Who changed a configuration setting.

    I would like to suggest that the log should be secure, even other admins can't go in and delete entries. One would need direct access to the data tables to do that.

    The ability to pipe off the audit data to another storage source so even people with access to the data tables can't delete there actions. I don't want the audit to grow my database to a massive size either.

    I would like to be able to raise my own audit events through the Event system.

    I would like to be able to search the audit. Type in a key word and find all the references. Specify a user and track what they have done on the site. Really important that the audit data is accessible and presentable.

    Levels of Auditing allowing me to do basic auditing to verbose like auditing.

    I am not fussed at "what" can be audited on the first release as that can always be increased over time. But its the functionality of the audit and the ability to extend it that is the most important stuff on day one.

     

  • Hi all,
    and thanks for the valuable feedback!
    In regards to Audit Trail, Sitefinity will require the use of external tools for storing the logs and visualizing reports based on them. Please, review below and confirm that the recommended set up can work for you.
    Architecture overview

    • Sitefinity Audit Log will collect log entries and submit them to
    • Elasticsearch, which will store the entries, and use
    • Kibana, to visualize real time reports based on them

    What is the benefit
    Since Audit Logs contain a lot of structured information, there is a need for analytics framework to process the collected data and generate valuable reports on top of it. We believe that  Elasticsearch + Kibana provide a good solution.

    What this will require on your side

    • Installation of Elasticsearch  (details are here)
    • Set up of Kibana (details are here)

      Preferably, these should be installed on a server in the same network as the web site. Also, the server should be visible to the users accessing the reports.

      Can you please verify that the set up outlined above can work in your current
      infrastructure?
      Are there any additional questions you might have?

      Regards,
      - Kalina
  • Those tools would be perfectly suitable for doing the analytics on the audit log. Installation of those tools wouldn't pose any issue in our hosting environments.

    From a compliance auditing perspective, this would be great... as long as all the necessary audit data is being made available the the analytics tools.

     I'd still hope that deletions can be restored inside Sitefinity (recycle bin feature).

  • No concerns from me.
  • Kali,

      Will it be logging logins/logouts as well? ....will we have an API to push things into it as well by any chance?

  • Hi Steve,

    Yes, we will log logins to the Backend, including unsuccessful login attempts. We are planning to provide API and extensibility points.

    It would be helpful to learn more on how you are planning to customize/extend audit trail.Just to make sure we are covering for those scenarios.

    Regards,
    Kalina

     

  • This sounded like a great idea... until I saw it was for only Enterprise editions.

  • Agree.  At least make it an option for other editions!