User that disabled the project version control

Hi,

 

I would like to know, if there is a database table or log file, that stores the name of the user who disabled the version control for a project. I searched for this information on event_log and audit_log (of the project and site admin) tables and log files but could not find this information.

 

Is there another place I could search for?

 

Thanks in advance,

Parents
  • Verified Answer

    The only place this might be recorded is in the Site Admin logs created by the use of the Site Admin UI. If you log in to Site Admin and go to the Servers tab and click on the name of your ALM server, the details of the log configuration for that server will display, including the location of the SA log.

    Whether or not the log actually contains the information probably depends on the log level setting. I don't know what log level detail is required to cause the info you want to be logged. If the log level wasn't adequate at the time, then there is no way to find out after the fact who disabled version control.
  • Hi, 

     

    Thanks for your answer. The project didn´t have the log level set to debbug, so the information was not loggeg to sa log files.

     

    Anyway, thanks for your answer.

     

    Regards,

  • you can keep the log level to the debug mode.

    Refer the attachment.

     

    You can still ask the DBA for tha activity log for a certain period, so that you can filter the requirement.

     

  • Use caution when you consider leaving your ALM server in debug mode.  This will effect performance for every user and every activity that they perform.  Disk space will be consumed at a much higher rate and the amount of memory that will be used will be increased.  If your location for the logs is a SAN or NAS drive then you will have a dramatic increase in network bandwidth consumption as well.

     

    Generally debug logs should only be considered when you are attempting to recreate a problem or error message so that you can get the greater detail to help resolve the problem and then you return the logs to a warning or none for normal day to day activities.

     

    If an admin task was performed accidentally or even maliciously and you want to know who did it, the first step is to make sure that you don't have many people using a common admin user.  Second, make sure the list of admin users is only as large as it absolutely has to be.  After that, finding out if specific actions were taken may be possible by evaluating logs but not all activities, especially admin activities are logged.  Could be a good enhancement request.

     

    Craig

Reply
  • Use caution when you consider leaving your ALM server in debug mode.  This will effect performance for every user and every activity that they perform.  Disk space will be consumed at a much higher rate and the amount of memory that will be used will be increased.  If your location for the logs is a SAN or NAS drive then you will have a dramatic increase in network bandwidth consumption as well.

     

    Generally debug logs should only be considered when you are attempting to recreate a problem or error message so that you can get the greater detail to help resolve the problem and then you return the logs to a warning or none for normal day to day activities.

     

    If an admin task was performed accidentally or even maliciously and you want to know who did it, the first step is to make sure that you don't have many people using a common admin user.  Second, make sure the list of admin users is only as large as it absolutely has to be.  After that, finding out if specific actions were taken may be possible by evaluating logs but not all activities, especially admin activities are logged.  Could be a good enhancement request.

     

    Craig

Children
  • In my environment we opted for another solution.

    I have implemented custom tools that use the Site Admin API to accomplish such tasks. "Site Admins" are designated, not within the ALM application, but through a configuration file read by the custom tools. For the ALM application we have defined a generic Site Admin user account with a secret password. Our named "site admins" use the custom tools which in turn use the generic Site Admin account behind the scenes. We track who is doing what by having the custom tools generate their own logs.