Re: Traffic Ops Change log

And while I think a robust and detailed changelog is a first step, some finer filtering mechanisms on the other end may be valuable as well. For example, it might be useful at some point in the future to have the default view of the changelog elide the DSR changes (which could be viewed easily by

Re: Traffic Ops Change log

Can't argue with that. Our change log needs to be more robust imo. Like you said, what exactly changed on server with id=42? On Fri, Mar 23, 2018 at 9:08 AM, Chris Lemmons wrote: > The changelog exists to answer the question, "Who made things this way > and when?" > > I

Re: Traffic Ops Change log

The changelog exists to answer the question, "Who made things this way and when?" I think we do need changelog entries on everything change that changes things, but those comments aren't useful unless they tell us what changed and what the old and new values are. So, I'm not in favour of filling

Re: Traffic Ops Change log

IMO, I don't think it's necessary to pollute the Change Log with Delivery Service Requests (DSRs) comments. I think DSRs are turning out to be the Change Log for Delivery Services and comments on those are Change Log noise. -Dew On Wed, Mar 21, 2018 at 10:24 AM, Jeremy Mitchell

Traffic Ops Change log

Currently, every POST (create), PUT (update) or DELETE (delete) TO API endpoint (or most of them) create a change log entry. For example when i PUT /api/cachegroups/4 it creates this CL entry: myusername - Updated Cachegroup named 'Foo' with id: 57 Question: In the golang rewrite of the TO API