mirror of
https://github.com/gristlabs/grist-core.git
synced 2024-09-28 07:20:48 +00:00
21b0ac3eff
Summary: Track 'data size' in ActiveDoc alongside row count. Measure it at most once every 5 minutes after each change as before, or after every change when it becomes high enough to matter. A document is now considered to be approaching/exceeding 'the data limit' if either the data size or the row count is approaching/exceeding its own limit. Unrelated: tweaked teamFreeFeatures.snapshotWindow based on Quip comments Test Plan: Tested manually that data size is now logged after every change once it gets high enough, but only if the row limit isn't also too high. Still too early for automated tests. Reviewers: georgegevoian Reviewed By: georgegevoian Differential Revision: https://phab.getgrist.com/D3341
61 lines
3.3 KiB
TypeScript
61 lines
3.3 KiB
TypeScript
export interface SnapshotWindow {
|
|
count: number;
|
|
unit: 'days' | 'month' | 'year';
|
|
}
|
|
|
|
// A product is essentially a list of flags and limits that we may enforce/support.
|
|
export interface Features {
|
|
vanityDomain?: boolean; // are user-selected domains allowed (unenforced) (default: true)
|
|
|
|
workspaces?: boolean; // are workspaces shown in web interface (default: true)
|
|
// (this was intended as something we can turn off to shut down
|
|
// web access to content while leaving access to billing)
|
|
|
|
/**
|
|
* Some optional limits. Since orgs can change plans, limits will typically be checked
|
|
* at the point of creation. E.g. adding someone new to a document, or creating a
|
|
* new document. If, after an operation, the limit would be exceeded, that operation
|
|
* is denied. That means it is possible to exceed limits if the limits were not in
|
|
* place when shares/docs were originally being added. The action that would need
|
|
* to be taken when infringement is pre-existing is not so obvious.
|
|
*/
|
|
|
|
maxSharesPerDoc?: number; // Maximum number of users that can be granted access to a
|
|
// particular doc. Doesn't count users granted access at
|
|
// workspace or organization level. Doesn't count billable
|
|
// users if applicable (default: unlimited)
|
|
|
|
maxSharesPerDocPerRole?: {[role: string]: number}; // As maxSharesPerDoc, but
|
|
// for specific roles. Roles are named as in app/common/roles.
|
|
// Applied independently to maxSharesPerDoc.
|
|
// (default: unlimited)
|
|
maxSharesPerWorkspace?: number; // Maximum number of users that can be granted access to
|
|
// a particular workspace. Doesn't count users granted access
|
|
// at organizational level, or billable users (default: unlimited)
|
|
|
|
maxDocsPerOrg?: number; // Maximum number of documents allowed per org.
|
|
// (default: unlimited)
|
|
maxWorkspacesPerOrg?: number; // Maximum number of workspaces allowed per org.
|
|
// (default: unlimited)
|
|
|
|
readOnlyDocs?: boolean; // if set, docs can only be read, not written.
|
|
|
|
snapshotWindow?: SnapshotWindow; // if set, controls how far back snapshots are kept.
|
|
|
|
baseMaxRowsPerDocument?: number; // If set, establishes a default maximum on the
|
|
// number of rows (total) in a single document.
|
|
// Actual max for a document may be higher.
|
|
baseMaxApiUnitsPerDocumentPerDay?: number; // Similar for api calls.
|
|
baseMaxDataSizePerDocument?: number; // Similar maximum for number of bytes of 'normal' data in a document
|
|
|
|
gracePeriodDays?: number; // Duration of the grace period in days, before entering delete-only mode
|
|
}
|
|
|
|
// Check whether it is possible to add members at the org level. There's no flag
|
|
// for this right now, it isn't enforced at the API level, it is just a bluff.
|
|
// For now, when maxWorkspacesPerOrg is 1, we should assume members can't be added
|
|
// to org (even though this is not enforced).
|
|
export function canAddOrgMembers(features: Features): boolean {
|
|
return features.maxWorkspacesPerOrg !== 1;
|
|
}
|