Contributions
Re: How can i get a reviewer state in script
Greetings, I fought this battle; the only way to get the reviewer state is via the 'review summary', which is actually ALL the information about the review. You get that by sending (replace 'review_id' with your own review number or variable): command: "ReviewService.getReviewSummary", args: { reviewId: review_id, clientBuild: 8200, active: true } I talk about this a little bit in another thread; it's awfully poorly documented, but it works. Under the result of that, you'll find a reviewParticipantsarray which contains the information you are looking for, specifically the assignmentState. I mostly gate on whether or not the reviewer is in state /^FINISHED_/ because I can't find any enumeration of all the possible assignmentstates. I hope this helps! It was really frustrating to get to this point, and the easier I can make it for anyone else, the better. -- Morgan p.s. I've written a rudimentary Ruby library to help with this, but permission to release it is still going through my management chain. :-/1.3KViews0likes0CommentsRe: Getting the state of reviewers/participants via JSON API?
Greetings, I strongly disagree; there is absolutely no information about what is required for that call. There is no information about what 'active' means, or why passing true and false returns the exact same data, but in a vaguely different order. Or why passing ANYTHING that I've tried for clientGuid results in a NullPointerException. Or what valid values for clientBuildare, or even WHY those values are required to get a ReviewSummary. Your documentation for the ReviewService.getReviewSummary call in your own post (which I read many times trying to understand this) implies that just reviewId, clientBuild and clientGuid are required, but clientGuidisn't, active is, and that's not called out. Your JavaDoc iscompletely lacking for updateToken, active, and consolidationMethods, all of which are also apparently parameters, except that reviewId, clientBuild, and active are the only ones that are required. I have no idea what those other parameters do, nor does anyone who isn't on your team and has access to the source code. It is impossible to implement to that documentation without flailing around, guessing at valid values, and tripping on the solution. I'm sure it's easier for you folks, because you already know what they all mean, but your documentation makes no attempt to explain those parameters. This is endemic in your docs. 'Documentation' that consists exclusively of: public interface ClientBuildRequest A request to get client build number public interface ClientGuidRequest A request to get client guid number is half-hearted JavaDoc at best, and probably machine generated. You need to explain what valid values are, and explain what it's used for, so the callers can have any marginal idea of how to build something for it. Properties are not documented unless an unrelatedcaller understands which to use, and why to use them. Those properties, and that call (one of the most important in your set of calls) are not documented. I really do appreciate the API, and it's not the worst I've had to reverse-engineer, but the documentation DEFINITELY needs to be written, especially for that critical call. -- Morgan3.6KViews1like0CommentsRe: Getting the state of reviewers/participants via JSON API?
Greetings, Through almost no help of the docs, I discovered that I can elide the clientGuid and provide active: true and I get the review summary. Essentially: { command: "ReviewService.getReviewSummary", args: { clientBuild: 9200, reviewId: 900101, active: true } } will return the useful information. I only found this out because I sent: { command: "ReviewService.getReviewSummary", args: { blah: "fake" } } and the error message listed the known entities, one of which was 'active'. I guessed at the client build, just throwing a number in there that was related to Code Collaborator at one point. I don't know if it's relevant, but it doesn't work without it. The documentation is misleading, unfortunately. -- Morgan3.7KViews0likes3CommentsGetting the state of reviewers/participants via JSON API?
Greetings, I'm trying to use your JSON API to retrieve the state of the reviewers on a review. I don't seem to be able to find that information anywhere in the API reference. I can retrieve the list of participants, and their roles, but I can't retrieve whether they've approved the review or not, yet. I don't need to know the larger reviewPhase, but rather WHO of the people listed as participants has actually reviewed/approvedthe code yet. Your in-app JavaDoc based documentation is exceedingly difficult to search through, and essentially unusable in places. For instance, I can find no reasonable way to determine what clientGuid and clientBuild are for the other parameters forReviewService.getReviewSummary. So while that might be a useful call for what I'm doing (I don't know, the documentation doesn't say), I can't actually call it to learn because there's no documentation on how to obtain the non-review ID parameters. I would appreciate any kind of pointers or information you can provide on how to determine the State (as displayed in the code review page) of each participant in a code review, via your JSON API. It seems a somewhat fundamental capability of a code review system. -- Morgan3.7KViews0likes5Comments