Loading

Structure and Permissions

A File Store is more than a folder. Inside a virtual store is a tree of folders and files in which every file keeps its earlier versions, and around it sits a set of permissions granted to security groups. This article explains both, so you can design a store that people can find things in and that only the right people can change.

Where to find it

Architect Panel → Data:

  • File Stores — the stores, their settings and their permissions
  • Large Uploads — upload sessions in progress and recently finished, including uploads into stores

Admin Panel → User Administration:

  • User Groups — the security groups a store is granted to

The folder tree

In a virtual store every entry names its parent, so folders nest to any depth. Each entry is either a file or a folder, and a file points at its current version. Replacing a file adds a new version rather than overwriting the old one, so earlier versions remain available.

Two consequences are worth planning for. A store grows faster than the number of files people think they have put in it, because every replacement is kept. And reorganising a large tree later is disruptive, because people have learned where things are.

Physical and virtual stores

A store is one or the other, not both. A virtual store is the managed library described above, and its files go to the installation's storage backend, whether that is local disk, S3 or Azure. A physical store simply lists a folder on the web server's own disk, with no versions; it does not work on an installation that keeps its files in S3 or Azure.

Permissions are per store, per group

Each grant names a security group and the permissions it holds on that store. People get the combination of everything granted to all their groups. The permissions are:

  • Read: open the store, browse its folders and download files. Without it, the store says "You do not have access to this file store."
  • Upload Files: add files. The Upload Files button only appears with this permission.
  • Create Folders: add folders. The Add Folder button only appears with this permission.
  • Edit Existing Files/Folders: rename entries.
  • Delete Files/Folders: remove entries. Deleting a folder removes everything below it, so grant this sparingly.

These are checked on the server for every action, whatever the screen shows.

Designing a store

  1. Draw the boundary around an audience. Permissions attach to the whole store, not to folders inside it. If two groups need different access, make two stores.
  2. Keep the tree shallow and obvious: by year, by type, by customer. Avoid mirroring an organisation chart that will change.
  3. Grant Read to everybody who needs to see the store, and the other four permissions only to the people who maintain it.
  4. Create the top-level folders yourself before opening the store to others, so the structure is set before files arrive.
  5. Review the grants at least once a year. Stores accumulate access as groups are repurposed and projects end.

Bringing store files into document control

A file in a store can be adopted as a document, gaining classification, an access log and review dates, while the store keeps the original. The store's own Read permission is still checked whenever the file is downloaded. See Bringing Documents In.

What goes wrong

  • Somebody can see a store but has no Upload Files button. None of their groups holds Upload Files on that store.
  • A deleted folder took more than expected with it. Folder deletion cascades to everything below. Restrict Delete Files/Folders to a small group.
  • A store is filling up storage. Every replacement keeps the previous version. Check whether people are uploading new copies of large files repeatedly.

Worked example

An organisation runs three virtual stores: "Public Assets", readable by everybody and maintained by the communications team; "Customer Contracts", readable and maintained by the account team only; and "HR Files", restricted to two people who hold every permission. Each has a shallow tree by year. Because the boundaries follow the audiences, the answer to "who can see the contracts?" is one line per store.

Recommendations

  • Separate stores by audience, not by folders within one store.
  • Design a shallow tree before loading files.
  • Keep Delete Files/Folders to a few people.
  • Remember versioning when estimating storage.
  • Review each store's grants periodically.