seto1

@HungDV2022 createへの変更ありがとうございます。テストがエラーになってしまっているようですので確認お願いします。

@HungDV2022 ご対応ありがとうございます。 @ryuring 確認しました。問題なさそうです。

@ryuring ``` bin/cake create jwt ``` ありがとうございます。確かに先に `bin/cake setup install` を実行しないと使えないですね。 InstallationsService->createJwtを https://github.com/baserproject/basercms/blob/5.1.x/plugins/bc-installer/src/Service/InstallationsService.php#L517 BcApiUtilに移動して、baser-coreのコマンドにするのはどうでしょう。 https://github.com/baserproject/basercms/blob/5.1.x/plugins/baser-core/src/Utility/BcApiUtil.php 一応以下のコマンドで作成できるはできるので、そこまで強い要望ではないです。 ``` openssl genrsa -out config/jwt.key 1024 openssl rsa -in config/jwt.key -outform PEM -pubout -out...

- 管理システム内でもAPIを使用しているので許可ルールは必要 - 認証プレフィックス設定が不要? - アクセスルールグループとアクセスルール一覧で表示タイプの違いがある点は揃えたほうがいい

beforeFindとBcBlog.BlogPosts.beforeFindで取得できる情報が異なりますね。 baser5.0系だとBcBlog.BlogPosts.beforeFindでもクエリが取得できてたんですが、5.1系だとarrayになってます。 baserのイベント周りの調整が必要かもしれません。 ```

@ryuring > beforeFindの重複 解消したいですね。それで beforeFind と BcBlog.BlogPosts.beforeFind の挙動が揃うのであれば特に。 > 検索パラメーターの一部書き換えをどうやってやるか 既存のイベントで対応できるのに新しくイベントを増やしたくないという気持ちはありますね。 例えば検索条件のブログコンテンツIDの変更でしたら以下で対応可能です。 まあ、無理矢理感はあります。 関数化してもっと使いやすくすることは可能だと思いますけど。 クエリの書き換えの需要はあると思うので、なにかもっといいベストプラクティスがあればいいんですけど検索してもなかなか見つかりませんね。 イベントを増やすことでシンプルになるのであればありかもしれません。 ```

サービスクラスのメソッドが呼び出される際に毎回発火するイベントがあるなら使いやすそうですけど難しそうですね。 https://www.php.net/manual/ja/language.oop5.magic.php getIndexに個別でイベントを追加すると、サービスクラスの他の関数にもイベントを追加したくなってコード量が大幅に増えてしまいそうです。 もしくは、せっかくサービスクラスにInterfaceを使っているので、任意のクラスに変更できるようになればイベント以上に自由度が上がりますね。

■サービスクラスの切り替え 複数のプラグインから条件を変更したい場合、単にサービスクラスを切り替えるようにするだけでは難しい。 ■where条件の上書き where関数の3つめの引数にtrueを渡すと条件をリセットできるものの、ブログ記事の公開状態の条件などもリセットされてしまう。 https://discourse.cakephp.org/t/remove-where-condition-from-query/1900 ■Queryを一度配列に変換して条件を変更しやすくする 複雑な条件が指定された場合に難しそう。 試作 ``` public function beforeFind(EventInterface $event) { $query = $event->getData(0); if ($query->getRepository()->getAlias() === 'BlogPosts') { $array = $this->whereToArray($query); $array['AND'][6]['BlogPosts.blog_content_id ='] = 2; $query->where($array,...

案1. permission_groupsテーブルにuser_group_idカラムを追加してユーザーグループごとにデータを分ける 案2. そのアクセスグループに属する有効なアクセスルールが存在する場合にアクセスグループを削除できないようにする 案3. アクセスグループ編集画面から削除ボタンを消して管理用の別の画面を作る 案4. 削除ボタンを押した際にすべてのアクセスグループに影響する旨のアラートを表示する

@ryuring アクセスルールグループの利用状態（status）も共通ですがどうしましょう。 一次対応としてなら、利用状態のチェックボックス付近にメッセージ追加でしょうか。 利用状態はすべてのユーザーグループで共通です、みたいな感じで。