権限関係

まぁ色々と
権限周りって意外と難しくて、仕方なく今の仕様にしてるって側面が多いかなぁと・・・って事でせっかくなので・・・前提情報として
ぶりの呼びだし方にはBaoとInvokerの二つがあります。BaoはInvokerを扱いやすくするためのwrapAPIに過ぎません(内部でBaoInvokerを呼びだしてる)。なので頻繁に使う部分に関してはBaoでほぼカバーさせているモノの、定義が難しいとか定義すると混乱しそうな部分に関してBaoの対象外で直接Invokerを使うって事にしています。

で、この件について
id:nobeans:20060329:1143650295

実行ユーザが閲覧可能なデータの一覧を取得する。((A)と対応)
件数が多い場合はS2Pager的に取り扱えると良い。

ぶりはデータの制御はIDでしかしていないのでS2Pagerっぽい制御が難しくなっているんですね。
少なくとも今の仕様のDaoを作ってそれを指定することでぶりが使う、ぶりが認識するのはIDのみって仕様のままだとS2Pager的なことを実現するには限界があります。
特定ステータスのID一覧はInvokerのAPIを使うと取得できるのでそれでS2Pagerを使うか、filterManyをS2Pagerを使うように設定すれば良いのかなぁと思います。
＃filterManyはBaoからも使えるし

ステータスを問わずに取得、特定ステータスを指定しての取得のバリエーションがほしい。

ステータスを問わずに取得は即ちDaoの直接呼び出しですね。自由にしてください(笑)
とはいえ、Baoの定義で上手くいけそうなら有りかなぁと思ったことも・・・

その中から1つのデータを選んで、そのステータスでそのユーザに許可されているアクティビティ一覧を取得する。((B)と対応)

これはInvokerの機能としてあります。

いつの間にかステータスが進んでいた場合など、既に指定したアクティビティの実行権限がなければエラー。

これは難しい・・・エラーが起きたからってどうすればいいのか実行時にはだれも判らないし、とはいえ設計時に判る内容でもないし・・・

で、次のぶり(s2buri 0.3.0=1.0候補)の話しですが・・・
ParticipantProviderはS2AnAの同種のinterfaceを継承するように変更し、さらに最低二つのメソッドを独自に追加します。

userDataに関係するroleTypeが存在していることを確認する
boolean hasRoleUser(Object userData,String roleType)

userDataに関係するRoleを取得する
List getUser(Object userData,String roleType)

あと、Userに関するテーブルを一つ追加して、StateとUserを繋ぐテーブルを一つ追加します。それとDataに関しては最初に登録した人の情報を追加します
ってことでERDを書けば何をやろうとしてるか多分判ると思いますが、さくっと「ぶり内部用ACLを作るつもりです」
ActivityとデータとUserの関係をプログラマに制御させることはよっぽどメリットがない限りバグの原因になりかねないので多分しないです。