Divisions and local permissions
National, state and local group — and exactly who can see which people.
Quick answers
6 questions · click to openHow does Cobber decide which people someone can see?
By the division their role sits at. A national role sees everyone; a state role sees that state and the local groups under it; a local role sees only people in that group's electorates.
Does this apply to campaigns and exports too?
Yes, and it's applied to the query rather than hidden in the interface — so there's no route by which a local admin reaches other people's records.
How does a person end up in a local group?
By their electorate, which Cobber works out from their address. Local groups cover electorates, so the address does the sorting for you.
Can I move someone to a different local group by hand?
Yes. There's a manual override on the person, for the cases where the electorate isn't the right answer.
What about people with no address?
They can't be placed, so they won't appear for admins at local level. That's the practical reason addresses matter at import time.
Do we have to use local groups at all?
No. A smaller organisation can run entirely at national level and add local groups later, once there are enough people to be worth dividing.
Divisions are the backbone of everything Cobber does with permissions. Get them right and distributed organising works; get them wrong and either nobody can see anything, or everybody can see everything.
The hierarchy
| Level | Sees |
|---|---|
| National | Everyone in the organisation. |
| State | That state, and every local group under it. |
| Local group | People in that group's electorates, and nobody else. |
How a person ends up in a local group
Local groups cover electorates. Cobber works out a person’s federal electorate, state electorate and LGA from their address, and that places them.
You don’t maintain a mapping by hand, and you don’t have to sort people into local groups yourself. It’s also why an import without addresses leaves people invisible to admins at local level — see importing a spreadsheet.
For the cases where the electorate isn’t the right answer — someone who organises in the local group next door, say — there’s a manual override on the person.
It’s enforced on the query, not the screen
This is worth understanding, because it changes what you can safely delegate.
Scoping is applied when the data is fetched, not by hiding things in the interface. A local admin building a campaign, running an export or searching people is working from a set that never contained anyone else’s records in the first place. There’s no URL to guess and no filter to remove.
That’s what makes it reasonable to give a volunteer local organiser a login.
Common mistakes
| Symptom | Cause and fix |
|---|---|
| An organiser sees nobody | Their role is at a local group with no people placed in it yet — usually because addresses are missing. |
| Two people get different counts from the same filters | Working as intended. Their roles sit at different divisions. |
| A member turns up in the wrong local group | Their address puts them in that electorate. Use the manual override if the address is right but the local group isn't. |
| Head office wants a local group's numbers | Anyone at state or national level already sees them — no need to ask the local group to export anything. |