Comments
-
That is better, and simpler - one call and a filter beats two calls and arithmetic. The active flag is right there in each member object, so there is no reason to do it the way I described. On the 50 cap, one thing worth adding for anyone scripting this. The endpoint returns isLast, so that is the condition to loop on -…
-
Small correction to my own answer above, before it misleads anyone. I said /rest/api/3/group/member includes inactive users by default and that you should pass includeInactiveUsers=false. That is backwards. The default is false, so deactivated accounts are already excluded, and passing false changes nothing. The real thing…
-
You are right, @Gabriela - LeanZero, and thank you for catching it - I had that parameter backwards. The default is false, so deactivated accounts are already excluded and passing false changes nothing. The exposure is the opposite of what I described: the API returns fewer members than admin.atlassian.com does, and the…
-
Hi Sana, Gabriela already put the finger on the real problem - the two auth systems. Worth restating in one line because it catches almost everyone: <site>.atlassian.net/rest/api/3/... takes your email plus a personal API token as basic auth, while api.atlassian.com/admin/... takes an organisation API key as a Bearer…
-
That is great news, Missy - and the billing count going from 32 to 31 is the part that actually proves it. The UI status is cosmetic, the billable number is not, so you now have real confirmation rather than a hopeful one. Two things worth keeping in mind, since you will probably do this again for other clients: The change…
-
Hi Daniel, Before building the report, it is worth separating two questions, because they produce very different lists: 1. Who has access to a project - this is a configuration question. 2. Who is actually working in a project - this is a data question. Nikola's script answers the first one. If you need the second one, the…
-
Good luck Missy, I hope it works! One practical thing to watch, because this is usually where it silently fails: removing her from the project is not enough on its own. If her account still has Jira product access - directly, or through a default access group - she stays a licensed user, and adding her back will just make…
-
Thank you Cristian, this is exactly the pattern I kept running into. Your second point is the one that surprises people the most, and it goes one level deeper than group membership. A permission scheme rarely grants to a user directly - it grants to a project role, the role holds a group, and the group holds the people. So…
-
Hi @Missy , You are right, and thank you for quoting the policy line — that is the part I missed in my first answer. What you describe did not match what I expected, so before replying again I spent some time going through the guest documentation and the open tickets on jira.atlassian.com. Guest access is quite new, and…
-
Hi @Kimberle Lovitt, I think the missing Access menu and the "cannot create issues" error are the same problem, not two separate ones. In a team-managed project, the Access section is only shown to someone who holds the Administrator role inside that project. If you do not hold that role, the menu is not empty — it is not…
-
Hi @Missy, Short answer: you do not need to delete and re-invite anyone, and that is exactly what you should avoid. The important thing is that an Atlassian account is identified by an accountId, which is global and belongs to the person, not to your site. Assignee, reporter, watchers, comments and issue history all store…
