gristlabs_grist-core

Commit Graph

Author	SHA1	Message	Date
Paul Fitzpatrick	8f023a6446	(core) implement authorization via query parameter Summary: This adds any parameters in a document url whose key ends in '_' into a `user.Link` object available in access control formulas and in setting up characteristic tables. This allows, for example, sending links to a document that contain a hard-to-guess token, and having that link grant access to a controlled part of the document (invoices for a specific customer for example). A `user.Origin` field is also added, set during rest api calls, but is only tested manually at this point. It could be elaborated for embedding use-cases. Test Plan: added test Reviewers: dsagal Reviewed By: dsagal Differential Revision: https://phab.getgrist.com/D2680	4 years ago
Dmitry S	8c788005c3	(core) Implement much of the general AccessRules UI. Summary: - Factored out ACLRuleCollection into its own file, and use for building UI. - Moved AccessRules out of UserManager to a page linked from left panel. - Changed default RulePart to be the last part of a rule for simpler code. - Implemented much of the UI for adding/deleting rules. - For now, editing the ACLFormula and Permissions is done using text inputs. - Implemented saving rules by syncing a bundle of them. - Fixed DocData to clean up action bundle in case of an early error. Test Plan: WIP planning to add some new browser tests for the UI Reviewers: paulfitz Reviewed By: paulfitz Differential Revision: https://phab.getgrist.com/D2678	4 years ago
Dmitry S	bc3a472324	(core) Implement new representation of ACL rules. Summary: - Added fields to _grist_ACLRules for the new Granular ACL representation - Include a corresponding migration. - Added ACLPermissions module with merging PermissionSets and converting to/from string. - Implemented parsing of ACL formulas and compiling them into JS functions. - Add automatic parsing of ACL formulas when ACLRules are added or updated. - Convert GranularAccess to load and interpret new-style rules. - Convert ACL UI to load and save new-style rules. For now, no attempt to do anything better on the server or UI side, only to reproduce previous behavior. Test Plan: Added unittests for new files; fixed those for existing files. Reviewers: paulfitz Reviewed By: paulfitz Differential Revision: https://phab.getgrist.com/D2664	4 years ago
Paul Fitzpatrick	3d3fe92bd0	(core) support access control on columns Summary: Adds a granular access clause for columns. Permissions can be specified for a set of columns within a table. Permissions accumulate over clauses, in a way that is intended as a placeholder pending final design. Test Plan: Added tests. Tested manually that updates to private columns are not sent to people who don't have access to them. There are a lot of extra tests needed and TODOs to be paid down after this experimental phase. Reviewers: dsagal Reviewed By: dsagal Differential Revision: https://phab.getgrist.com/D2651	4 years ago
Paul Fitzpatrick	c879393a8e	(core) support adding user characteristic tables for granular ACLs Summary: This is a prototype for expanding the conditions that can be used in granular ACLs. When processing ACLs, the following variables (called "characteristics") are now available in conditions: * UserID * Email * Name * Access (owners, editors, viewers) The set of variables can be expanded by adding a "characteristic" clause. This is a clause which specifies: * A tableId * The name of an existing characteristic * A colId The effect of the clause is to expand the available characteristics with all the columns in the table, with values taken from the record where there is a match between the specified characteristic and the specified column. Existing clauses are generalized somewhat to demonstrate and test the use these variables. That isn't the main point of this diff though, and I propose to leave generalizing+systematizing those clauses for a future diff. Issues I'm not dealing with here: * How clauses combine. (The scope on GranularAccessRowClause is a hack to save me worrying about that yet). * The full set of matching methods we'll allow. * Refreshing row access in clients when the tables mentioned in characteristic tables change. * Full CRUD permission control. * Default rules (part of combination). * Reporting errors in access rules. That said, with this diff it is possible to e.g. assign a City to editors by their email address or name, and have only rows for those Cities be visible in their client. Ability to modify those rows, and remain updates about them, remains under incomplete control. Test Plan: added tests Reviewers: dsagal Reviewed By: dsagal Differential Revision: https://phab.getgrist.com/D2642	4 years ago
Paul Fitzpatrick	a4929bde72	(core) add some row-level access control Summary: This implements a form of row-level access control where for a given table, you may specify that only owners have access to rows for which a given column has falsy values. For simplicity: * Only owners may edit that table. * Non-owners with the document open will have forced reloads whenever the table is modified. Baby steps... Test Plan: added tests Reviewers: dsagal Reviewed By: dsagal Differential Revision: https://phab.getgrist.com/D2633	4 years ago

6 Commits (de35be6b0a51d31d01bfb4057c271de2044e4c5d)