Yes, I was just thinking about filtering of the change log as well. For example, change logs probably need to be filtered by tenancy and/or role/capability.
Example, as a user, i'm not interested in delivery service changes outside my tenancy nor should i see them at all. Nor should I see certain types of changes. I.e. server changes. So I think the change log endpoints are going to need to be enhanced to support this more advanced filtering. Jeremy On Fri, Mar 23, 2018 at 10:50 AM, Chris Lemmons <[email protected]> wrote: > 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 adjusting the filter). Just spitballing, of > course, but the principle of "have as much data as is reasonable and > provide powerful tools to manipulate it" goes a long way. > > On Fri, Mar 23, 2018 at 10:11 AM, Jeremy Mitchell <[email protected]> > wrote: > > 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 <[email protected]> > wrote: > > > >> 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 the changelog with a whole bunch of: > >> > >> myusername - Updated server ['Foo'] with id: 42 > >> > >> But I'd be quite interested in this: > >> > >> myusername - Updated server ['Foo'] with id 42: Changed 'origin' from > >> 'http://foo.example.com' to 'http://bar.example.com'. > >> > >> I think that moves it from being spammy to being useful. Might take a > >> bit of thought to make sure we don't create epic changelog messages > >> when someone creates a whole new object or changes a large number of > >> things, but overall I think it would be very useful. > >> > >> WRT the DSRs, I think that considering them to be Change Logs > >> themselves might work at some point, but it's not quite there yet. I > >> would include the changes to DSRs. > >> > >> On Wed, Mar 21, 2018 at 10:46 AM, Dewayne Richardson < > [email protected]> > >> wrote: > >> > 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 < > >> [email protected]> > >> > wrote: > >> > > >> >> 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 should EVERY POST, PUT > >> >> and DELETE trigger a change log entry? Or should it be optional and > >> >> determine by the developer? > >> >> > >> >> I ask because I'm adding endpoints for create, update and delete of > >> >> delivery service request comments and it feels like too much to > create a > >> >> change log entry for that. I'd hate to pollute the change log for > minor > >> >> stuff. > >> >> > >> >> To me, it seems like it should be optional and determined by the API > >> >> developer. > >> >> > >> >> Jeremy > >> >> > >> >
