)]}'
{"/PATCHSET_LEVEL":[{"author":{"_account_id":14250,"name":"Grzegorz Grasza","email":"xek@redhat.com","username":"xek"},"change_message_id":"3a2a768b78c56a5bca29e89b0b3da0f367d0c192","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":2,"id":"dc02f49f_847730a3","updated":"2024-07-12 14:27:07.000000000","message":"A release note might be in order","commit_id":"82b22aca4ac731a5dce90450c99b3f4e829c4d88"},{"author":{"_account_id":8064,"name":"Jake Yip","email":"jake.yip@ardc.edu.au","username":"jake"},"change_message_id":"d9b67c33b7523e627781bf9e6769be76d09f7b2c","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":2,"id":"d339fba4_ca8accfc","updated":"2024-04-19 00:53:38.000000000","message":"Hi! I\u0027m interested in this as we use App Cred extensively and this affects us.\n\nDoes this approach means updating implied roles after an App Cred is created won\u0027t update the effective roles?","commit_id":"82b22aca4ac731a5dce90450c99b3f4e829c4d88"},{"author":{"_account_id":27900,"name":"Artem Goncharov","email":"artem.goncharov@gmail.com","username":"gtema"},"change_message_id":"16d8ff6ec3607d1129c833bf02fc5f599e2f651d","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":2,"id":"e6d5068f_93abdbef","in_reply_to":"d339fba4_ca8accfc","updated":"2024-04-29 13:59:52.000000000","message":"you can\u0027t update roles of existing appcred.\nThis change fixes the fact that AppCred created without explicit specification of the roles (using roles of the current token) is not respecting inherited roles resulting in AppCred not having all expected roles.","commit_id":"82b22aca4ac731a5dce90450c99b3f4e829c4d88"},{"author":{"_account_id":28619,"name":"Dmitriy Rabotyagov","email":"noonedeadpunk@gmail.com","username":"noonedeadpunk"},"change_message_id":"82bc9c6a67bd3cb60ec5671279f582f14a41a3c6","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":2,"id":"b061fe26_c299b63d","in_reply_to":"dc02f49f_847730a3","updated":"2024-07-15 13:15:38.000000000","message":"I\u0027ve added a release note in a follow up patch - I hope that will be fine, as I don\u0027t want to mess up with a nicely voted patch.\n\nFor backports I\u0027ll squash these 2 changes.","commit_id":"82b22aca4ac731a5dce90450c99b3f4e829c4d88"},{"author":{"_account_id":31542,"name":"Andrew Bonney","email":"andrew.bonney@bbc.co.uk","username":"andrewbonney"},"change_message_id":"90f4f09380bf58caf81cc035f841b72b2e9f2a47","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":2,"id":"e8bdfb89_b9953b88","in_reply_to":"e6d5068f_93abdbef","updated":"2024-05-01 10:29:55.000000000","message":"If this doesn\u0027t apply to existing app creds I\u0027m not sure it\u0027s sufficient. In the case where we originally noted this, an app cred had a \u0027member\u0027 role, and changes revealed in an upgrade meant this was then useless without the implied \u0027reader\u0027 role, requiring everyone to re-generate their app creds despite no changes on their part.\n\nMy concern is this will just result in the same issue presenting itself in the future if there are further changes to the role hierarchy. It\u0027s particularly confusing from a user perspective if this was to happen, as if they compare the app credential roles to a standard user\u0027s permissions against a project (where only the top level role may be displayed, not the implied ones), it looks like it should work, but the behaviour under the hood differs.","commit_id":"82b22aca4ac731a5dce90450c99b3f4e829c4d88"}]}