3 ms·

It looks like your access control is table level. Have you considered what it will take to provide row/column level controls? Also, the report builder looks li

It looks like your access control is table level. Have you considered what it will take to provide row/column level controls? Also, the report builder looks like it doesn't allow you to set up complex reports (range queries). Can you add an abstract WHERE clause constructor? That would let you do things like collect all orders in the last week that were over 20 dollars, late on their delivery, or fulfilled by the new guy. You might want to look at BI tools like Pentaho or Microstrategy to see if you can build something similar on the analysis end. Finally, do you offer change tracking and backups? No one wants to lose a LOB database because someone ragequit.

thaumaturgy 11y ago
> Have you considered what it will take to provide row/column level controls? FWIW I did this for a client application and it wasn't real fun. Took a few tries to come up with something that was reasonable at column-level resolution. Figure you need at least read and write permissions, you need to have table-level granularity, you want to have column-level granularity, you want to make it easy to manage groups of permissions (roles), but you also want it to be easy to create users with exceptions to those roles. For example, how would you create permissions for a group that gives you access to all of a table except a specific column? You need, basically, ACLs, and afaik there isn't a standard recommendation for that yet (that I could find). I settled on a roles table and a permissions table, with descriptors with wildcards for different operations (like, "read-client-address", "write-client-notes", "∗-client-∗"), and allow/disallow/inherit options. For instance, a "demo" account has "disallow ∗, allow read-client-∗, disallow read-client-name", etc. On login the permissions are loaded for the user signing in and then each DB operation checks to see if the operation is allowed() in a function that resolves wildcards and priority and does a few other tricky things. There are probably better ways to do it, but anyway, the moral is that there should be a good reason for needing more granularity in permissions before someone decides to implement it.
mistermann 11y ago
> You might want to look at BI tools like Pentaho or Microstrategy to see if you can build something similar on the analysis end. Or just provide an OData feed so users can do that themselves in PowerBI (or whatever).
semperdark 11y ago
It won't be very fun to make, but the architecture should support column level controls for sure. Row level I'd have to look into in more depth. Right now we already have a system for hiding columns from specific tables where they aren't needed, and it's not just hiding them frontend, the column data isn't queried. We can probably hook into that. That's a good point, the report builder doesn't support OR at the moment. The interface for that should be interesting.. We may just allow custom SQL queries and be done with it. We definitely plan to get into BI/analysis, I'll check those out. We backup and log literally everything. The user actions aren't shown to Organization admins yet, but that's only because we haven't built a frontend for it. We're working on showing a list of actions taken by connected users. All changes to forms and submissions are also diff logged, and you can reset to any older version. The frontend for that has some minor bugginess that I'm working out, though.

thaumaturgy 11y ago

> Have you considered what it will take to provide row/column level controls? FWIW I did this for a client application and it wasn't real fun. Took a few tries to come up with something that was reasonable at column-level resolution. Figure you need at least read and write permissions, you need to have table-level granularity, you want to have column-level granularity, you want to make it easy to manage groups of permissions (roles), but you also want it to be easy to create users with exceptions to those roles. For example, how would you create permissions for a group that gives you access to all of a table except a specific column? You need, basically, ACLs, and afaik there isn't a standard recommendation for that yet (that I could find). I settled on a roles table and a permissions table, with descriptors with wildcards for different operations (like, "read-client-address", "write-client-notes", "∗-client-∗"), and allow/disallow/inherit options. For instance, a "demo" account has "disallow ∗, allow read-client-∗, disallow read-client-name", etc. On login the permissions are loaded for the user signing in and then each DB operation checks to see if the operation is allowed() in a function that resolves wildcards and priority and does a few other tricky things. There are probably better ways to do it, but anyway, the moral is that there should be a good reason for needing more granularity in permissions before someone decides to implement it.

mistermann 11y ago

> You might want to look at BI tools like Pentaho or Microstrategy to see if you can build something similar on the analysis end. Or just provide an OData feed so users can do that themselves in PowerBI (or whatever).

semperdark 11y ago

It won't be very fun to make, but the architecture should support column level controls for sure. Row level I'd have to look into in more depth. Right now we already have a system for hiding columns from specific tables where they aren't needed, and it's not just hiding them frontend, the column data isn't queried. We can probably hook into that. That's a good point, the report builder doesn't support OR at the moment. The interface for that should be interesting.. We may just allow custom SQL queries and be done with it. We definitely plan to get into BI/analysis, I'll check those out. We backup and log literally everything. The user actions aren't shown to Organization admins yet, but that's only because we haven't built a frontend for it. We're working on showing a list of actions taken by connected users. All changes to forms and submissions are also diff logged, and you can reset to any older version. The frontend for that has some minor bugginess that I'm working out, though.