)]}'
{"/PATCHSET_LEVEL":[{"author":{"_account_id":27665,"name":"Markus Hentsch","email":"markus.hentsch@cloudandheat.com","username":"mhen"},"change_message_id":"ed89b3e7c623e0e9273b287b521ffe9c9f255244","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":3,"id":"c0034713_34d610e6","updated":"2023-11-09 16:56:26.000000000","message":"I made the Keystone protection tests in Zuul non-voting as per recommendation on IRC [1].\n\nThe fix for keystone-tempest-tests is here: https://review.opendev.org/c/openstack/keystone-tempest-plugin/+/900545\n\nAfter that, a follow-up patchset will need to make them voting again.\n\n[1] https://meetings.opendev.org/irclogs/%23openstack-keystone/%23openstack-keystone.2023-11-08.log.html#t2023-11-08T15:44:46","commit_id":"d3d1c604e01c7b9ec0d423171e993a31311bc281"},{"author":{"_account_id":13478,"name":"Boris Bobrov","email":"b.bobrov@sap.com","username":"bbobrov"},"change_message_id":"e77de92e1e24bc2eca5d38365a1551a294bb9e75","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":3,"id":"a320968c_f730bd1a","updated":"2023-11-26 03:10:48.000000000","message":"This looks like a change to the API behavior and breaking of the API stability for the users, who do not enforce scope.","commit_id":"d3d1c604e01c7b9ec0d423171e993a31311bc281"},{"author":{"_account_id":7414,"name":"David Wilde","email":"dwilde@redhat.com","username":"d34dh0r53"},"change_message_id":"0fa56f42864ddb90f379ea5a431aa52e0abd919e","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":3,"id":"2db6928a_991c8214","updated":"2023-11-15 15:03:16.000000000","message":"recheck - updated gates","commit_id":"d3d1c604e01c7b9ec0d423171e993a31311bc281"}],"keystone/api/domains.py":[{"author":{"_account_id":27665,"name":"Markus Hentsch","email":"markus.hentsch@cloudandheat.com","username":"mhen"},"change_message_id":"30ae8854ad6fe463168fcf9f5e93aa1974336a1d","unresolved":true,"context_lines":[{"line_number":101,"context_line":"        filters \u003d [\u0027name\u0027, \u0027enabled\u0027]"},{"line_number":102,"context_line":"        target \u003d None"},{"line_number":103,"context_line":"        if self.oslo_context.domain_id:"},{"line_number":104,"context_line":"            target \u003d {\u0027domain\u0027: {\u0027id\u0027: self.oslo_context.domain_id}}"},{"line_number":105,"context_line":"        ENFORCER.enforce_call(action\u003d\u0027identity:list_domains\u0027,"},{"line_number":106,"context_line":"                              filters\u003dfilters,"},{"line_number":107,"context_line":"                              target_attr\u003dtarget)"}],"source_content_type":"text/x-python","patch_set":1,"id":"237c937d_ab647a4c","line":104,"updated":"2023-11-03 09:52:32.000000000","message":"Note that for the RBAC `target` I decided to mimic the nested structure that list_groups uses [1] adopted to domains. In contrast, list_projects does it differently [2] (flat structure). This only influences the way that the policy rule check has to be implemented. In this case it is \"...:%(target.domain.id)s\" as implemented in the default rule in \"keystone/common/policies/domain.py\" of this patchset.\n\n[1] https://opendev.org/openstack/keystone/src/commit/7ee35794e94ea3d5519ccbb0ba72260c67c66ca8/keystone/api/groups.py#L80\n[2] https://opendev.org/openstack/keystone/src/commit/7ee35794e94ea3d5519ccbb0ba72260c67c66ca8/keystone/api/projects.py#L119","commit_id":"dc2b0d6bf7b454ecc80b8366acbe111dc6f50621"}]}