GRID now has a Permissions model to allow Administrators to apply finer control over which people can access particular Activities, Base Layers and Projects. To accommodate this, Groups are available to manage internal and external accessibility to certain content.

Without permissions set, the GRID application is essentially the same view for all users – with one caveat where Internal and External layer access settings differentiate what an internal and external user sees (see Section 6.13).

When permissions are set, it is possible to create many views of GRID – whereby visibility of Activities, Base Layers and Projects is dependent on what Group a user has been added to.

GRID can be a single view for all, or with Permissions applied, can be tailored views to different groups of people.

So what are Groups?

Groups are a collection of users with a common access requirement. The concept of Groups for permissions modelling and security is common in many file systems and applications. Here are some examples of how they might be applied in GRID:

• Several external landcare officers are involved in controlling weeds within a catchment.
• Only certain internal staff are allowed to see Declared Rare Flora data

Some other important notes about how Groups behave in GRID:

• Groups can be nominated as Internal or External (e.g. Only Internal people can be assigned to an Internal Group and vice-versa).
• Members of a Group will have access to Activities and Base Layers that have been associated with that Group, and all other users will not see that content.
• Members of a Group can only edit or assign features to Projects that have been associated with that Group.

So what sorts of things can the Administrator do? Let’s break down some scenarios…