)]}'
{"keystone/api/roles.py":[{"author":{"_account_id":5046,"name":"Lance Bragstad","email":"lbragstad@redhat.com","username":"ldbragst"},"change_message_id":"408bdd038c596a673e12a87c33b27af4e112e68e","unresolved":false,"context_lines":[{"line_number":42,"context_line":"        return bool(role.get(\u0027domain_id\u0027))"},{"line_number":43,"context_line":""},{"line_number":44,"context_line":"    def get(self, role_id\u003dNone):"},{"line_number":45,"context_line":"        \"\"\"Get role or list roles."},{"line_number":46,"context_line":""},{"line_number":47,"context_line":"        GET/HEAD /v3/roles"},{"line_number":48,"context_line":"        GET/HEAD /v3/roles/{role_id}"},{"line_number":49,"context_line":"        \"\"\""},{"line_number":50,"context_line":"        if role_id is not None:"},{"line_number":51,"context_line":"            return self._get_role(role_id)"},{"line_number":52,"context_line":"        return self._list_roles()"}],"source_content_type":"text/x-python","patch_set":2,"id":"3f79a3b5_c59861c1","line":49,"range":{"start_line":45,"start_character":0,"end_line":49,"end_character":11},"updated":"2018-08-13 07:53:42.000000000","message":"nit: we don\u0027t really document these publicly in other APIs. I don\u0027t really care if we do:\n\n  def get(self, role_id\u003dNone):\n\nand just get right into the implementation, or if we just do:\n\n  def get(self, role_id\u003dNone):\n      # create a role\n\nI\u0027m just in favor of consistency. Something we can cleanup later I suppose, just something I noticed specifically on this review.","commit_id":"7ac58ea62aedf3730ac9632df5fb470bc5955518"},{"author":{"_account_id":5046,"name":"Lance Bragstad","email":"lbragstad@redhat.com","username":"ldbragst"},"change_message_id":"408bdd038c596a673e12a87c33b27af4e112e68e","unresolved":false,"context_lines":[{"line_number":73,"context_line":"                    # reraise the error after enforcement if needed."},{"line_number":74,"context_line":"                    raise err"},{"line_number":75,"context_line":"            else:"},{"line_number":76,"context_line":"                ENFORCER.enforce_call(action\u003d\u0027identity:get_domain_role\u0027,"},{"line_number":77,"context_line":"                                      member_target_type\u003d\u0027role\u0027,"},{"line_number":78,"context_line":"                                      member_target\u003drole)"},{"line_number":79,"context_line":"        return self.wrap_member(role)"}],"source_content_type":"text/x-python","patch_set":2,"id":"3f79a3b5_a5b9a515","line":76,"range":{"start_line":76,"start_character":55,"end_line":76,"end_character":70},"updated":"2018-08-13 07:53:42.000000000","message":"I\u0027m just rambling here - but I\u0027d like to see this go away in favor of the role API just being smart enough to handle scope properly. For example, calling GET /roles with a domain-scoped token is equivalent in my eyes. Or calling POST /roles with a domain scoped token would be the equivalent to creating a domain-role.\n\nAgain, just rambling but the try/except/finally here seems like it could be simplified at the expense of removing the domain-roles API. Looking at this API now that we\u0027re implementing flask support feels like domain-roles were implemented in a way the works around the admin-ness bug :(\n\nMaybe we can make a not to revisit this. Maybe a hallway track at the PTG.","commit_id":"7ac58ea62aedf3730ac9632df5fb470bc5955518"}]}
