How is everyone handling record security, when requirements require dynamic visi

I was thinking a bit more about this over the weekend and it occurs to me that there may be another approach to solve the issue of determining membership of these private groups without using so much of a workaround. What if you created a new group (with a less strict permission level), something along the lines of "X Record Superuser Viewers" - and add whichever groups will always see all record listings as members of that group. That way your expression could check for membership of that group (from a constant or whatever), without needing to "see" the private groups. This would also protect you from issues if the "doesuserbelongtogroupnamed()" rule's permissions ever get changed without warning.

Yes, that would solve some potential issues and be a bit cleaner for sure. doesUserBelongToGroupNamed() is my custom rule though - however we are familiar with Appian rule permissions changing, doesUserBelongToGroup() is one that changed to be more restrictive after Group_Functions v 1.3.

Thanks for all the suggestions!

Hi csteward,

It appears that for your Default Filter, you are passing in a list of record ID's using the "IN" operator.

Have you managed to run any performance tests for when the number of record ID's grows larger? eg. for MS SQL, the max # of parameters is 2100, but for MySQL it appears to be 65k+ (from a quick google search).

Hi jonathan, I have not ran any performance tests yet but will be doing so shortly - I will report back here with my results.

I was able to run a few performance tests today, and the results are not exciting. With 24,771 records in the DB - I'm receiving memory threshold errors as the Record refuses to load:

Error evaluating function 'queryruleexec' : Memory threshold reached during output conversion (rule: [QR_SIR_All], type: [CDTSoftwareInstallRequestDT999], threshold: [1,048,576 bytes], objects successfully converted: [20,468]

So, this method may not work for me. It is also concerning as I have users who will need to view 150,000 records - might have to try something along the lines of the 'best practice' route, hopefully that will perform better. ugh.

Oh yeah - do you have a columnSelection implemented in your query entity? I'm assuming that you don't since you appear to be reusing a rule that just returns all records. Use an alternate (similar) rule wherein you restrict the returned data to just the id column; it will cut the data used dramatically, and provably make the query faster.

The query rule was returning all columns - unfortunately when I implement 2 new query rules (one taking the loggedininitiator() parameter) with just the fldID as the only other column, I'm still seeing issues loading the Record with only 24,771 rows.

ERROR org.hibernate.util.JDBCExceptionReporter - The incoming tabular data stream (TDS) remote procedure call (RPC) protocol stream is incorrect. Too many parameters were provided in this RPC request. The maximum is 2100.

Does your new query work when there are fewer records? I'm unfamiliar with the error message you posted so I'm not sure whether it's maybe a syntax issue in your new rule or whether you've hit a hard limit for the "in" operator that I've never seen before.

Well the expression works fine when pasted into the rules interface, it spits out 24,771 process ID's - so I'm assuming it is a limit that has been hit. I'm working on another load test (user in 10,000+ groups), we'll see how that goes then I will start removing some rows from the DB to see if I can identify the actual limit.

Well, with a user in 9,010 groups, that user can barely operate in the system - logging in takes almost a minute and the Reports and Records tabs themselves throw the error below, before any Reports or Record headers are even loaded on those main pages (can't even get to the record I was trying to test).. So, looks like it is back to the drawing board again..

2015-07-14 22:36:56,543 [ajp-/0.0.0.0:8009-2] ERROR org.hibernate.util.JDBCExceptionReporter - The incoming tabular data stream (TDS) remote procedure call (RPC) protocol stream is incorrect. Too many parameters were provided in this RPC request. The maximum is 2100.
2015-07-14 22:36:57,955 [ajp-/0.0.0.0:8009-1] ERROR org.hibernate.util.JDBCExceptionReporter - The incoming tabular data stream (TDS) remote procedure call (RPC) protocol stream is incorrect. Too many parameters were provided in this RPC request. The maximum is 2100.
2015-07-14 22:36:57,958 [ajp-/0.0.0.0:8009-1] ERROR com.appiancorp.rest.shared.FallbackExceptionMapper - Internal Server Error on REST API invocation.
org.hibernate.exception.SQLGrammarException: could not execute query