Constructing and enforcing access control policies

This application is a continuation of U.S. application Ser. No. 18/483,723, filed Oct. 10, 2023, which claims the benefit of U.S. Provisional Application No. 63/414,862 titled “Constructing and Enforcing Access Control Policies in a Realtime System based on a Visual Application Designer,” filed on Oct. 10, 2022, each of which is incorporated herein by reference.

The subject matter described relates generally to constructing and enforcing access control policies for customized user interfaces.

User interfaces may be used to display data from a database. However, these user interfaces may expose portions of the database that are unintentional or undesired (e.g., confidential information). These user interfaces may expose these portions visually or otherwise (e.g., the client loads data from the database, thus exposing it even if that data is not displayed by an interface).

Embodiments herein relate to constructing and enforcing access control policies for user interfaces, especially for customized user interfaces that can dynamically change in real time (e.g., due to users making changes simultaneously).

In some aspects, the techniques described herein relate to a method including: receiving a schema of user interface including an arrangement of interface elements, each element configured to display data from cells of a database; receiving a user permission for the user interface, the user permission specifying one or more users allowed to access the user interface; receiving an element permission for an interface element of the user interface, the element permission specifying data (e.g., records) of the interface element accessible to users of the user interface; generating a policy object for the user interface based on the user permission and the element permission, the policy object specifying which cells of the database can be accessed by the user interface; receiving a query from a client device associated with a user to implement a local instance of the user interface; and serving the query according to the policy object, wherein serving the query includes providing data from the database that the user interface provides access to without providing other data from the database that should not be accessible according to the policy object.

The figures and the following description describe certain embodiments by way of illustration only. One skilled in the art will readily recognize from the following description that alternative embodiments of the structures and methods may be employed without departing from the principles described. Wherever practicable, similar or like reference numbers are used in the figures to indicate similar or like functionality. Where elements share a common numeral followed by a different letter, this indicates the elements are similar or identical. A reference to the numeral alone generally refers to any one or any combination of such elements unless the context indicates otherwise.

1 FIG. 100 110 140 140 170 140 100 100 is a block diagram of a networked computing environment suitable for enabling user interfaces, databases, and permissions, according to one or more embodiments. In the embodiment shown, the networked computing environmentincludes a server, a first client deviceA, and a second client deviceB, all connected via a network. Although two client devicesare shown, the networked computing environmentcan include any number of client devices. In other embodiments, the networked computing environmentincludes different or additional elements. In addition, the functions may be distributed among the elements in a different manner than described.

110 110 140 140 110 2 FIG. The serverhosts and manages databases and user interfaces. In one embodiment, the servermanages permissions for user interfaces dynamically such that only the data from a database that is needed to provide the intended user interface is provided to client devices. The permissions (and thus data needed) by a particular user interface may be determined by stepping through or otherwise traversing the various elements of the user interface and building a permission set that may be stored in a policy object. Thus, data that should not be accessible by a particular client device(e.g., confidential information) is not unintentionally exposed by provision of the user interface. Various embodiments of the serveris described in greater detail with respect to.

140 110 140 140 The client devicesare computing devices with which users can access and edit the databases and interfaces managed by the server. Example client devices include desktop computers, laptop computers, smartphone, tablets, etc. The client devicesA andB may enable users to interact with the databases via a user interface accessed via a browser, a dedicated software application executing on the client devices, or any other suitable software.

170 100 170 170 170 170 170 170 The networkprovides the communication channels via which the other elements of the networked computing environmentcommunicate. The networkcan include any combination of local area and/or wide area networks, using both wired and/or wireless communication systems. In one embodiment, the networkuses standard communications technologies and/or protocols. For example, the networkcan include communication links using technologies such as Ethernet, 802.11, worldwide interoperability for microwave access (WiMAX), 3G, 4G, 5G, code division multiple access (CDMA), digital subscriber line (DSL), etc. Examples of networking protocols used for communicating via the networkinclude multiprotocol label switching (MPLS), transmission control protocol/Internet protocol (TCP/IP), hypertext transport protocol (HTTP), simple mail transfer protocol (SMTP), and file transfer protocol (FTP). Data exchanged over the networkmay be represented using any suitable format, such as hypertext markup language (HTML) or extensible markup language (XML). In some embodiments, all or some of the communication links of the networkmay be encrypted using any suitable technique or techniques.

2 FIG. 110 110 210 227 237 247 257 267 110 is a block diagram of the server, according to one or more embodiments. In the embodiment shown, the serverincludes modules including a data store, an interface manager module, a policy object module, an interface generator module, a policy enforcer module, and a payload module. In other embodiments, the serverincludes different or additional modules. In addition, the functions may be distributed among the modules in a different manner than described.

210 110 210 110 210 140 110 The data storeincludes one or more computer-readable media that store databases managed by the server. Although the data storeis shown as a single element within the serverfor convenience, the data storemay be distributed across multiple computing devices (e.g., as a distributed database). Similarly, individual databases may be hosted by client devices(or other computing devices) with the servermanaging synchronization between databases but not storing the databases themselves.

210 As used herein, “data” may refer to a set of structured data. For example, data may be a table, a spreadsheet, or a JSON file. A “database” may refer to a collection of structured data (e.g., in table format) for which relations between the data can be derived. For example, the database may comprise tables stored in data store, and the relations between the tables may be derived using a common column. The data or the database may be structured as a two-dimensional matrix of cells, and as such have rows and columns. A cell refers to an individual unit of data and its metadata. A cell may have a type (e.g., number, text, Boolean, error), a value (e.g., a user-entered value or a computed result), a formula value (e.g., an expression), a formatted value (e.g., the value formatted to a string such as $1.23), a format (e.g., a number format such as a date (Nov. 12 2013) or a text format such as background color, text color, typeface, font size, bold, italic, underline, strikethrough, etc.), a text format run (e.g., a section of text within the cell with a particular format), a hyperlink (e.g., a URL), or a pivot table anchored to the cell.

3 FIG. 3 FIG. 3 FIG. 3 FIG. 3 FIG. 300 300 301 303 305 307 301 303 305 301 303 303 301 300 301 is a diagram of an example database. The databaseincludes three tables,,and relations between the tables. Each table inincludes multiple cells (e.g., cell). In the example of, each table includes a single column and multiple rows. Tablelists example projects (e.g., “Healthier Concession Stands” and “Improve Safety of Petting Zoo”). Tablelists example tasks for the project “Healthier Concession Stands” of table 1 (e.g., “Call Nutrition Consultant” and “Design New Menus”). Tablelists assignees that can be assigned to projects in tableand tasks in table. In the example of, “Emma” and “Joe” are each assigned to a single task in tableand Tom is assigned to the “Build New Ride” project of table. Databasemay include additional tables not illustrated in, such as additional tables that list tasks for other projects in table.

I.A Generating Interfaces

2 FIG. 227 140 300 Referring back to, the interface managerenables a user (via a client device) to construct a user interface that selectively displays data from a database (e.g., database). Additionally, an interface may allow a user to edit data in the database. For example, if the database includes a table of tasks for a project and the status of each task, a user may add or remove tasks or change the status of a task by interacting with the interface. For convenience, interfaces are described herein as displaying data from a single database. However this is not required. An interface may display data from multiple databases, and multiple different interfaces may display data from a single database.

300 An interface may include an arrangement of one or more elements. An element is a portion of the interface that displays data according to a predetermined format. Some elements display data of a database according to a predetermined format. For example, some elements display data from cells of a database (e.g., database). Data from a cell displayed in an element may be referred to as a “record.” An example element is a list, a grid, a gallery, a calendar, a timeline, and a chart. Among other possible element types, an element may be a multi-record element, a single-record element, or a presentational element. A multi-record element displays multiple records, thus displaying data from multiple cells. A single-record element displays a single record, thus displaying data from a single cell. A presentational element does not display a record (e.g., a presentation element just includes text providing instructions on how to use the interface). A single-record element may be linked to a multi-record element (e.g., a single-record element displays data from a cell based on a record selected in the multi-record element). Element types are further described below in the context of various examples.

4 4 FIGS.A-C 4 4 FIGS.A andB 4 FIG.C 4 FIG.C 3 FIG. 140 403 405 407 409 411 413 409 415 407 300 300 301 303 305 illustrate an example of a user designing a user interface (via a client device).illustrate an interface generatorwhich allows the user to design an interface. The user can add elements by selecting the “add element” button at the bottom and dragging an element to the center of the screen.illustrates a draft interface with four interface elements. Elementis a text box displaying text from a cell of a database (or it may be a presentational element). Elementis a bar graph plotting data from cells of the database. Elementis a number element that displays data from cells of the database. Elementis a pie chart plotting data from cells of the database. Recordis an example record of elementand recordis an example record of element. For clarity, note that the data displayed by the elements indoes not correspond to the data in database. An example interface generator with elements displaying data from databasemay include, for example, a first element listing projects from table(this may be a multi-record element), a second element listing tasks from table(e.g., it lists tasks for the project selected in the first element, and a third element listing assignee from table. The third element is an example of a single-record element linked to the first or second element (e.g., it lists the assignee for the project or task selected in the first or second element (this may be based on the table relations illustrated in)).

2 FIG. 227 227 Referring back to, the interface managerenables a user constructing an interface to specify a “user permission” for the interface. A user permission provides other users the ability to access the interface (these users may be referred to as “collaborators”). Providing a user access an interface may or may not grant a that user access to the database. Among other advantages, granting access to an interface but not to the database enables the interface to present tailored or custom information to a collaborator without allowing the collaborator to view potentially harmful or confidential information in the database. The interface managermay enable the user to assign a permission level to a collaborator, such as creator, editor, commenter, or read only. The creator permission level enables the collaborator to (e.g., fully) edit the interface. For example, a creator collaborator is able to add a new element to the interface. An editor collaborator can edit records of elements in the interface (thus editing cells in the database) but not edit the elements themselves (e.g., add a new element). A commenter collaborator can comment on records but not edit records. A read only collaborator can view the interface but not edit or comment on the interface.

4 FIG.C 4 FIG.D 417 403 419 419 421 419 423 In the example of, a user can specify a user permission by first selecting the share indicator. Responsive to this, the interface generatormay display the example user permission interfaceillustrated in. The user permission interfaceincludes a contact fieldwhere a user can specify identifying information for a collaborator (e.g., an email address). The user permission interfacealso includes a permission level selector, which allows the user to specify the permission level for a collaborator.

2 FIG. 419 227 Referring back to, in addition to, or alternative to, a user assigning permissions for an interface (e.g., via), the interface managerenables a user to specify permissions for elements of the interface (“element permissions”). An element permission specifies which records of an element (or multiple elements) a collaborator can view (e.g., view the record or view data linked to that record), edit, comment, or some combination thereof (thus specifying which cells of the database the collaborator can view, edit, etc. through the interface). For example, an element permission specifies whether a collaborator can view all records or only records associated with that collaborator. In a more specific example, if an element includes a list of projects (specified in a database), the element may display all projects to a collaborator or the element may only display projects assigned to that collaborator, depending on the element permission. In some embodiments, a user may be able to specify custom rules for an element permission. In these embodiments, the user may provide logical conditions describing who can view certain records. For example, cells marked as “secret” or “confidential” (in the database) can only be seen in an element by a predetermined set of collaborators or collaborators that meet a specified condition. An element permission may depend on the type of element. For example, an element permission for a multi-record element may specify which actions a user can perform (e.g., view, edit, or comment) to the multiple records displayed by that element, while an element permission for a single-record element may specify which actions a user can perform (e.g., edit it or not) to the single record displayed by that element.

4 4 FIGS.E andF 425 427 425 427 403 425 427 are example element permission interfaces,that enable a user to specify an element permission for an element. Element permission interfacesandmay be displayed by the interface generatorwhen a user selects an element. The specifics of the element permission interface may depend on the type of element. As indicated in element permission interface, a user may enable a collaborator to view or edit records, in addition to adding/deleting records and allowing a collaborator to open record details. It also allows a user to specify whether a collaborator can view all records (“All records”), only records associated with the collaborator (“Viewer's records only”), or a custom set of records (Specific records”). As indicated in element permission, a user may enable a collaborator to filter, sort, and search records; click into record details; edit records; and add records.

Since an element permission is specific to an element (or multiple elements), an interface may include multiple elements, each with a different element permission. For example, a first element in an interface may allow a collaborator to view but not edit all records, a second element in the interface may allow the collaborator to only view records associated with that collaborator but the collaborator can edit those records, and a third element may have a custom element permission which, for example, enables some collaborators to view and edit a set of records but prohibits other collaborators from seeing (or editing) that set of records. Thus, the combination of a user permission and element permissions enables a user to conveniently create highly customized interfaces that display tailored information to each collaborator. Furthermore, the combination of a user permission and element permissions for an interface may result in each collaborator viewing different records in different elements of the interface.

If a first element is connected or associated with (e.g., dependent on) a second element, the element permission of the second element may affect the element permission of the first element. For example, if (a) a first element lists projects and a second element lists tasks for each project in the first list and (b) the element permission of the first element only allows a collaborator to view records (in this case, projects) associated with that collaborator, then the second element may only list tasks for projects that the collaborator is associated with (instead of listing tasks for all projects). Said differently, element permissions may affect each other when the elements are linked to each other. For example, a user may choose whether an element listing tasks for a project should only show tasks for the selected project (e.g., creating a link) or whether it should just show a static set of tasks (e.g., remaining unlinked). Elements may be connected or associated with each other if the elements are configured to display data from cells that are related to each other in the database.

I.B Generating a Policy Object

227 403 237 After the interface managergenerates an interface (e.g., based on a user interacting with the interface generator), the policy object modulemay generate a policy object for the interface. A policy object for an interface specifies which permissions (also “access control policies”) are granted by that interface for a given user. More specifically, a policy object specifies which cells of the database can be accessed (e.g., read or edited) by a user interacting with the interface. The policy may specify this for all users who can interact with the interface. The policy object may also specify which actions a user can perform to the interface, such as whether a collaborator can delete rows or clear cells. The policy object prevents unauthorized users (users not specified by the user permission) from accessing the interface. The policy object also prevents a collaborator from viewing or editing records in the interface they are not authorized to view or edit (specified by the element permissions).

237 237 227 237 The policy object modulemay generate the policy object based on the user permission and the element permissions of the interface. Thus, the policy object modulemay generate a new (e.g., unique) policy object for each interface generated by the interface manager. Furthermore, since interfaces can be dynamically modified and changed, the policy object modulemay regularly update the policy object or generate a new policy object if an interface is modified. This is further described below.

237 237 237 237 To generate the policy object, the policy object modulemay aggregate the user permission and the element permissions together. The policy object modulemay traverse the schema of the interface and compile the policy object. For example, the policy object moduletraverses the (e.g., entire) interface and analyzes each element of the interface to determine what information they will use to render properly (e.g., table name, column name, column type, cell values). More specifically, for each element in an interface, the policy object moduledetermines which cells of the database that element grants access to based on the associated element permission.

In some embodiments, the policy object includes a list of rules. The policy object may include a dependency graph, which specifies how access to individual cells, rows, columns, tables, etc. of the database are linked together. Said differently, a dependency graph may specify a hierarchy of permissions for the database. A dependency graph is useful because often access to a portion of the database (e.g., a cell) is dependent on access to another portion of the database (e.g., another cell). For example, if the database includes a table with rows and columns, the policy object may include a table policy specifying which actions can be performed to that table and which users are allowed to perform those actions (said differently, the table policy specifies which users can access (e.g., read or write) the table). The table policy may include a column policy (e.g., for each column of the table). A column policy specifies which actions can be performed to that column and which users are allowed to perform those actions. A column policy may include a row policy (e.g., for each cell of the column). A row policy specifies which actions can be performed to row cells of a given column and which users are allowed to perform those actions. Thus, the ability to access a cell may require access to the row of that cell, which may require access to the column of that cell, which may require access to the table. Thus, for example, if a collaborator has access to the table, but not the column or row of a cell, the user may not have access to that cell. In this way the table policy (with the included column and row policies) specifies who can access each cell of the table.

I.C Enforcing the Policy Object

247 140 140 247 140 247 To implement an interface (e.g., to display and allow a user to interact with an interface), the interface generatorprovides an instance of the interface to a client device(e.g., generates the interface on a client device). For example, the interface generatorprovides the interface to a collaborator via their client device. The interface generatormay provide an instance of the interface via a webpage.

247 140 140 140 110 140 110 110 The interface generatormay provide a local instance of the interface to a client deviceassociated with a user in response to a query from the client device. Furthermore, to continue implementing the interface, the client devicemay transmit queries to server. More specifically, as previously described, an interface includes records that display data from cells of a database (or multiple databases). To retrieve this data so it can be displayed in the interface, a client devicemay send queries to the server. Furthermore, a user may edit cells of a database by interacting with an interface. These edits may also be implemented via queries transmitted to the server. Queries for data may be sent for other reasons as well. As used herein, a query is an access request associated with a user. There may be different query types, such as a “read” query, a “write” query, and a “schema change” query. A read query is a request to read data in a cell (or multiple cells) of a database. If a read query from a client device is granted, a standing data connection (also “persistence data connection”) may be established between the instance of the user interface on the client device and the cell (or cells) of the database. Due to a standing data connection, if data in the cell (or multiple cells) is edited, the updated data will be automatically transmitted to the client device (e.g., without the client device sending a subsequent read query for that cell (or cells)). A write query is a request to write/edit data in a cell (or multiple cells) of a database. A schema change query is a request to change the interface itself e.g., to edit an element of the interface.

257 140 140 140 110 257 The policy enforcerreceives queries for an interface from a client deviceand determines via the policy object (for that interface) whether the queries should be granted or denied. Said differently, the policy object is used to filter the data sent to a client deviceand used to reject writes to data that's not (a) visible and (b) editable to the user, resulting in the client deviceonly receiving data from the serverit is authorized to receive. For example, the policy enforcerreferences a policy object to determine whether a collaborator associated with a query has access to (or the ability to edit) a cell of a database.

257 140 305 301 110 140 3 FIG. The policy enforcermay sequentially process queries (e.g., in a queue) for an interface or database, even if the queries are received from different client devices. Said differently, queries may be processed one at a time. For example, if a granted first query changes a collaborator assigned to a project from collaborator “A” to collaborator “B” (e.g., a relation between tableandinis changed such that collaborator “B” is now able to edit the project but collaborator “A” is now prevented from editing the project) and a second subsequent query from collaborator “A” (e.g., received directly after the first query) attempts to change one of the tasks of the project, the second query may be rejected since collaborator “A” is no longer assigned to the project. The order in which the queries are processed may be based on when they were received by the serveror sent by a client device. Processing queries sequentially may help prevent query conflicts and helps enable real time collaboration between users on the same interface.

257 257 257 257 In embodiments where the policy object includes a dependency graph, the policy enforcermay determine whether a query (e.g., to access a cell) should be granted by traversing the dependency graph to determine if there is any path that grants access (e.g., to that cell). For example, if a query associated with a user is requesting access to a cell in a table, the policy enforcermay first determine whether policy object includes a table policy that grants the user access to that table. If so, the policy enforcermay then determine whether the table policy includes a column policy that grants the user access to the column of the requested cell. If so, the policy enforcermay then determine whether the column policy includes a row policy that grants the user access to the row of the requested cell.

I.D Updating the Policy Object

257 237 237 237 110 140 In some cases, the action of a query (accepted by the policy enforcer) changes the interface (or the underlying database) such that the policy object becomes outdated or inadequate for the new interface. In these situations, the policy object modulemay (e.g., responsive to determining the policy object is inadequate) update or reconstruct the policy object (e.g., generate a new policy object) based on the change. The policy object modulemay dynamically react in real time to these changes. Example changes that may render a policy object inadequate include changes to the schema of the interface, such as deleting a table or column of the database, changing a column type of a column in the database, or updating the page layout of the interface. For example, if the action affects the interface itself (e.g., edits an element of the interface or adds a new element), the current policy object may be deleted and the policy object modulemay generate a new policy object based on the updated interface. In this situation, if any collaborators are accessing the interface, the servermay request each client deviceto refresh their interface so the new policy object can be implemented and enforced.

257 237 257 237 257 237 257 As previously described, the policy enforcermay sequentially process queries for an interface. If the policy object moduleupdates or generates a new policy object responsive to a granted query, the policy enforcermay wait until the policy object moduleis done before the next query (e.g., in the queue) is processed. Among other advantages, this helps prevent query conflicts that may occur if queries were processed in parallel or if the policy enforcerdid not wait until the policy object modulewas done updating a policy object (or generating a new policy object). Thus, the policy enforcermay eventually deny a subsequent query after referencing the updated policy object (even though the previous (un-updated) policy object would have granted the second query).

257 257 In some situations, after a new policy object is generated (or updated), queries that were previously granted (according to the old policy object) may be reevaluated (e.g., by the policy enforcer) to determine whether those previous queries should be granted according to the new policy object. For example, the policy enforcedreevaluates (e.g., all) granted read queries that established a standing data connection (thus helping prevent client devices from receiving data via that standing data connection that they no longer have access to according to the new policy object). Queries may be reevaluated when the dependencies used to grant those queries are affected by a change (that resulted in the new policy object). For example, a previously granted query may be revaluated: (a) if a row of the database is deleted that the previous query was authorized because of that row (e.g., the user could previously “see” a task because they were assigned the project, but the project is now deleted); (b) when a cell value is changed and the previous query was authorized because of that cell (e.g., a task is re-assigned from one collaborator to the other); and/or (c) when the time changes and the previous query was authorized based on the time (e.g., a collaborator only see tasks created within 24 hours and it is now more than 24 hours since the task was created).

I.E Payload Filtering

140 140 As previously described, due to a read query previously granted according to a policy object, an instance of a user interface on a first client deviceassociated with a user may have standing access to a set of cells of the database (previously referred to as a standing data connection but may also be referred to as the user interface “subscribing to” or “having a subscription to” the set of cells). Thus, if any changes occur to those cells, those changes may be transmitted to the first client deviceso that the interface displayed by that first client device is up to date. For example, if the second client device creates a new column of data, the new column of data may be transmitted to a first client device.

267 267 140 267 140 140 To do this, the payload moduleaccumulates changes to the database or to the interface. The payload modulepackages those changes into a payload and transmits the payload to one or more client devices. The payload modulemay transmit a payload responsive to a change, within a threshold time period (e.g., immediately) of a change, after a threshold number of changes occur or after a threshold amount of time has passed since the last payload transmission. Thus, a change made by one client device(via a query) may be quickly propagated to (e.g., all) other client devicesaccessing the interface. This may help create a rich and real time collaborative experience for the users.

267 140 267 140 257 140 257 140 257 140 However, as previously discussed, different collaborators may have restricted access to different sets of data in the database due to the user permission and element permissions of the interface. Thus, in many cases, the payload moduleshould not provide all changes to all client devices. Said differently, the payload moduleshould not blindly send the same payload to each client deviceas this may result in a collaborator receiving data (e.g., sensitive information) they do not have access to. Thus, the policy enforcermay inspect a payload to be transmitted to a client deviceaccording to the policy object to determine whether the payload includes any data changes a collaborator associated with that client device does not have access to (e.g., by traversing a dependency graph of the policy object). If so, the policy enforcermay filter out the unauthorized changes from the payload before the payload is transmitted to the client device. The policy enforcermay perform this inspection for each payload for each client device.

140 140 140 110 Thus, each client devicemay receive a customized or unique payload which only includes changes the user of the client deviceis authorized to receive. In this way, a client devicemay only receive data from the serverit is authorized to receive. Thus, an interface may only display data it is authorized to display. Among other advantages, customized payloads help increase data protection. In contrast, conventional systems may send all updates or data to a client device and then use an interface to only display select updates or select data. However, since the updates or data are stored on the client device, malicious actors may find ways to access restricted portions of those updates or data, thus exposing potentially sensitive information. Additionally, or alternatively, errors in interfaces of conventional systems may result in the interface displaying unintentional portions of the data set or the updates.

5 FIG. 5 FIG. 2 FIG. 500 500 110 500 140 140 500 110 110 300 illustrates a methodfor implementing a customized data policy object for a user interface. In the example of, the methodis performed by server, however one or more steps of methodmay instead be performed by a client device (e.g., within a browser running on client deviceA orB). Instructions for the methodmay be stored as program code that is executable by a computing system (e.g., server). For example, the method may be performed using the functionality and data of the components of servershown in. The steps may be performed in different orders. The methodcan include greater or fewer steps than described herein. Additionally, the steps can be performed in different order, or by different components than described herein.

510 110 At step, the serverreceives a schema of user interface comprising an arrangement of interface elements. The schema specifies the layout, organization, and structure of the interface. Each element is configured to display data from cells of a database.

520 110 540 At step, the serverreceives a user permission for the user interface. The user permission specifies one or more users allowed to access the user interface. In some embodiments, the user permission further specifies an permission level for each of the one or more users. In these embodiments, the policy object (step) is generated further based on the permission levels.

530 110 At step, the serverreceives an element permission for an interface element of the user interface. The element permission specifies data of the interface element accessible to users of the user interface.

540 110 At step, the servergenerates a policy object for the user interface based on the user permission and the element permission. The policy object specifies which cells of the database can be accessed by the user interface. The policy object may be a list of rules specifying which cells of the database can be accessed by each of the one or more users. The policy object may prevent the client device associated with the user from accessing cells of the database the user is not authorized to access. In some embodiments, the policy object includes a dependency graph.

550 110 At step, the serverreceives a query from a client device associated with a user to implement a local instance of the user interface.

560 110 At step, the serverserves the query according to the policy object by providing a local instance of the user interface. Providing the local instance includes providing data from the database that the user interface provides access to without providing other data from the database should not be accessible according to the policy object.

If the policy object includes a dependency graph, serving the query according to the policy object may include traversing the dependency graph to determine whether the user has access to a cell specified in the query.

500 110 110 110 110 In some embodiments, the methodfurther includes the serverreceiving an update to one or more cells of the database. The server may record or track this update and any other updates to the cells or the interface. The servergenerates a customized payload for the client device according to the policy object. The customized payload indicates changes to the one or more cells of the database that the user of the client device is authorized to access according to the policy object. The servertransmits the customized payload to the client device. The customized payload enables the client device to update the local instance of the user interface. In some embodiments, the serveraggregates the update, any additional updates to cells of the database, and any updates to the interface into a payload, and removes (e.g., filters out) updates in the payload that the user of the client device is not authorized to access according to the policy object.

500 110 110 In some embodiments, the methodfurther includes the serverreceiving an update to the schema of the interface that renders the policy object inadequate. Responsive to determining this, the servermay render the policy object invalid, may update the policy object based on the update, generate a new policy object based on the update, or some combination thereof.

500 110 110 110 110 In some embodiments, the methodfurther includes the serverreceiving multiple queries requesting access to cells of the database, and processing the multiple queries sequentially in a queue according to the policy object. Responsive to determining a first query in the queue affects a dependency of the policy object, the servermay delay processing subsequent queries in the queue until the policy object is updated or a new policy object is generated. In some embodiments, the serverprocesses the subsequent queries in the queue according to the updated policy object or the new policy object. Processing the subsequent queries in the queue may include the serverdenying a subsequent query in the queue according to the updated policy object or the new policy object, where the subsequent query would have been accepted according to the policy object.

500 110 In some embodiments, the query is a read query and the methodfurther comprises, responsive to granting the read query according to the policy object, establishing a standing data connection between the database and the instance of the user interface. Due to the standing data connection, the servermay automatically send updated data to the instance of the user interface responsive to data changes in the database.

In the above descriptions, permissions are often described in the context of a single database, however this is not required. Permissions may be in the context of multiple different databases. For example, a policy object for an interface may specify which cells of multiple databases can be accessed by a user of the interface.

In the above descriptions, permissions are described relative to an interface. However, user may specify a user permission that specifies one or more users that can access a database (or multiple databases). This access may or may not grant access to an interface that displays data from that database (or multiple databases).

6 FIG. 600 110 140 600 602 604 600 602 604 620 622 606 612 620 618 612 608 610 614 616 622 600 is a block diagram illustrating an example computersuitable for use as the serveror a client device. The example computerincludes at least one processorcoupled to a chipset. If the computerincludes multiple processors, the processors may execute a task individually or collectively. The chipsetincludes a memory controller huband an input/output (I/O) controller hub. A memoryand a graphics adapterare coupled to the memory controller hub, and a displayis coupled to the graphics adapter. A storage device, keyboard, pointing device, and network adapterare coupled to the I/O controller hub. Other embodiments of the computerhave different architectures.

6 FIG. 608 606 602 614 610 600 612 618 616 600 In the embodiment shown in, the storage deviceis a non-transitory computer-readable storage medium such as a hard drive, compact disk read-only memory (CD-ROM), DVD, or a solid-state memory device. The memoryholds instructions and data used by the processor. The pointing deviceis a mouse, track ball, touchscreen, or other type of pointing device, and is used in combination with the keyboard(which may be an on-screen keyboard) to input data into the computer system. The graphics adapterdisplays images and other information on the display. The network adaptercouples the computer systemto one or more computer networks.

Some portions of above description describe the embodiments in terms of algorithmic processes or operations. These algorithmic descriptions and representations are commonly used by those skilled in the computing arts to convey the substance of their work effectively to others skilled in the art. These operations, while described functionally, computationally, or logically, are understood to be implemented by computer programs comprising instructions for execution by a processor or equivalent electrical circuits, microcode, or the like. Furthermore, it has also proven convenient at times, to refer to these arrangements of functional operations as modules, without loss of generality. The described operations and their associated modules may be embodied in software, firmware, hardware, or any combinations thereof.

As used herein, any reference to “one embodiment” or “an embodiment” means that a particular element, feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment. The appearances of the phrase “in one embodiment” in various places in the specification are not necessarily all referring to the same embodiment. Similarly, use of “a” or “an” preceding an element or component is done merely for convenience. This description should be understood to mean that one or more of the elements or components are present unless it is obvious that it is meant otherwise.

Where values are described as “approximate” or “substantially” (or their derivatives), such values should be construed as accurate +/−10% unless another meaning is apparent from the context. From example, “approximately ten” should be understood to mean “in a range from nine to eleven.”

As used herein, the terms “comprises,” “comprising,” “includes,” “including,” “has,” “having” or any other variation thereof, are intended to cover a non-exclusive inclusion. For example, a process, method, article, or apparatus that comprises a list of elements is not necessarily limited to only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Further, unless expressly stated to the contrary, “or” refers to an inclusive or and not to an exclusive or. For example, a condition A or B is satisfied by any one of the following: A is true (or present) and B is false (or not present), A is false (or not present) and B is true (or present), and both A and B are true (or present).

Upon reading this disclosure, those of skill in the art will appreciate still additional alternative structural and functional designs for a system and a process for providing partial synchronization of database tables. Thus, while particular embodiments and applications have been illustrated and described, it is to be understood that the described subject matter is not limited to the precise construction and components disclosed. The scope of protection should be limited only by the following claims.