Mujinn » Mujinn-問合せ対応

チケットの概要はちゃんと書いほしいんだが
メッセージリンク貼り付けただけだったら何をするのか全然分からん

以下、ChatWorkから推測

[To:7260386]玉城 聖士さん
お世話になっております。

すいません、引用した件なんですが、1施設抜けておりました。
【プライベートプールヴィラもとぶ】も三名ユーザー追加をお願いできますでしょうか。

また、これは質問なんですが、
【運用】の権限がある施設は弊社でユーザー追加を行ったんですが、権限を【運用】ではないものに設定しまった為、権限をのみを変えようとしたところ、変更する事が出来ませんでした。
権限を変えたい場合はユーザー追加を再度行うしか方法はないのでしょうか。

お手数おかけしますが、ご確認の程よろしくお願いいたします。


玉城 聖士
株式会社 ゴールドバリュークリエーション
[返信 aid=9756503 to=153917641-2127310466199199744]高野太聖さん
【プライベートプールヴィラもとぶ】のユーザー追加について承知いたしました。
設定できましたら、ご連絡差し上げます。


権限ごとに追加・編集等どこまでできるのか、整理致しますので
少々お時間いただければと思います。
恐れ入りますが当面の間は、権限変更が上手くいかない場合は私に依頼いただきますようお願いいたします。

manageerサイトのユーザーアカウントの認可周りを整理して伝えるってことで良いよね

manageerサイトのユーザーアカウントの認可周り

{施設毎のスキーマ}.users.mygroupで持ってるっぽい？
実装見る

試しにClaude使ってみた

◼︎質問
http://localhost/managersite
上で、r0100.usersテーブルの情報から機能を認可する制御はありますか？

◼︎回答

調査結果
1. managersiteの所在
FuelPHPアプリで、コントローラは fuel/app/classes/controller/managersite/*.php（例: employeemaster.php, member.php など約40ファイル）、モデルは fuel/app/classes/model/managersite/user.php、ビューは fuel/app/views/managersite/*.smarty。ルーティングは fuel/app/config/routes.php。全managersiteコントローラの基底クラスは fuel/app/classes/controller/managerbase.php（Controller_ManagerBase）。

2. usersテーブルとスキーマについて
fuel/app/config/db.php:9-42 の通り、default/systemmanager 接続はいずれも dbname=systemmanager を指しており、usersテーブル（fuel/app/migrations/005_create_users.php）はこの systemmanager スキーマに存在する。"r0100"はコード中では宿泊施設(inn)ごとの予約データ用DBスキーマ名の例（fuel/app/tasks/events.php:50, fuel/app/classes/controller/guestbase.php:459 等）であり、認可判定に使われるusersテーブルとは別物。よってご質問の「r0100.users」という直接参照は見つからず（grep -rn "r0100.users" はヒットなし）、認可はsystemmanagerスキーマのusersテーブルで行われている。

3. usersテーブルのカラムと認可

モデル定義: fuel/app/classes/model/managersite/user.php:12-104。カラムに mygroup(int, 権限グループ), housekeeper_flg(tinyint), deleted_flg など。
権限定数: fuel/app/config/code.php:65-80 で C_AUTHORITY_USER=0, HOUSEKEEPER=1, HOUSEKEEPER_MANAGER=2, OP=5, ADMIN=7, SYSTEM=9 を定義し、コメントで「テーブルusers.groupの一桁目」がこの権限値であると明記。
4. 認証・認可の実装箇所

ログイン/セッション: fuel/app/config/auth.php（driver: Simpleauth）、fuel/app/config/simpleauth.php:37（table_name => 'users'）を通じて FuelPHP標準の Auth パッケージ（fuel/packages/auth）がusersテーブルを参照。
共通before処理: fuel/app/classes/controller/managerbase.php:31-65 の before() で Auth::check() により未ログインならログアウト処理。
個別コントローラでのロールベース制御: substr(Auth::get('mygroup'), -1) < Config::get("C_AUTHORITY_OP") というパターンで、mygroupの1桁目権限が閾値未満なら Response::redirect('/messages/auth_level_error.html') してアクセス拒否。該当例:
fuel/app/classes/controller/managersite/employeemaster.php:35
fuel/app/classes/controller/managersite/facilitymaster.php:36
fuel/app/classes/controller/managersite/egkeeperdata.php:36
fuel/app/classes/controller/managersite/housecleaning.php:35
fuel/app/classes/controller/printersetting.php:10, keyvoxapitest.php:10, aiqainput.php:10（mygroup != '109'で保守権限限定）
ログイン時の分岐: fuel/app/classes/controller/managersite/member.php:361,366 で C_AUTHORITY_HOUSEKEEPER/HOUSEKEEPER_MANAGER により遷移先を分岐。
画面(メニュー)表示制御: fuel/app/views/managermenu.smarty:822,843,855,902,947,960 で Auth::get('mygroup') の値によりメニュー項目の表示/非表示を切替。
まとめ: managersiteの認可はミドルウェアやデコレーターではなく、各コントローラのbefore()メソッド内で Auth::get('mygroup')（usersテーブルのmygroupカラム）を直接比較するコードパターンで実装されている。usersテーブル自体はr0100ではなくsystemmanagerスキーマに存在する。

はい、あります。ただし「r0100.users」という直接参照ではなく、少し補足が必要です。

前提の補足
usersテーブルはr0100ではなくsystemmanagerスキーマに存在します（fuel/app/config/db.php:9-42）。
r0100のようなスキーマ名は宿泊施設(inn)ごとの予約データ用DBの命名例で、認可に使うusersテーブルとは別物です（fuel/app/tasks/events.php:50 等）。
grep -rn "r0100.users" はヒットしませんでした。
認可制御の実態
managersiteではusersテーブルのmygroupカラム（権限グループ）を使った認可制御があります。

カラム/権限定義

モデル: fuel/app/classes/model/managersite/user.php:12-104 — mygroup, housekeeper_flg, deleted_flg等
権限定数: fuel/app/config/code.php:65-80 — C_AUTHORITY_USER=0, HOUSEKEEPER=1, HOUSEKEEPER_MANAGER=2, OP=5, ADMIN=7, SYSTEM=9（users.mygroupの一桁目がこの値）
認証: FuelPHP標準のSimpleauth（fuel/app/config/simpleauth.php:37 でtable_name => 'users'指定）

共通ログインチェック: fuel/app/classes/controller/managerbase.php:31-65のbefore()でAuth::check()

個別機能ごとの権限チェック: 各コントローラのbefore()で substr(Auth::get('mygroup'), -1) < Config::get("C_AUTHORITY_OP") のようなパターンで閾値未満ならauth_level_error.htmlへリダイレクト

employeemaster.php:35、facilitymaster.php:36、egkeeperdata.php:36、housecleaning.php:35 など
保守系機能（printersetting.php, keyvoxapitest.php, aiqainput.php）はmygroup != '109'で限定
メニュー表示制御: fuel/app/views/managermenu.smarty:822,843,855,902,947,960 でAuth::get('mygroup')によりメニュー項目の表示/非表示を切替

まとめ: ミドルウェアやデコレーターのような共通機構ではなく、各コントローラのbefore()内に直書きされたmygroup値の比較パターンで機能ごとの認可を行っています。ただしこれはr0100スキーマではなくsystemmanagerスキーマのusersテーブルです。

はい、あります。ただし「r0100.users」という直接参照ではなく、少し補足が必要です。
前提の補足
usersテーブルはr0100ではなくsystemmanagerスキーマに存在します（fuel/app/config/db.php:9-42）。
r0100のようなスキーマ名は宿泊施設(inn)ごとの予約データ用DBの命名例で、認可に使うusersテーブルとは別物です（fuel/app/tasks/events.php:50 等）。
grep -rn "r0100.users" はヒットしませんでした。
認可制御の実態
managersiteではusersテーブルのmygroupカラム（権限グループ）を使った認可制御があります。

ファぁっ？！？！！？？？
そんなことある？？？？？？？

回答にちょっと突っ込んでみる

◼︎質問
r0100にもusersテーブルはあります。
以下のDDLになっています。
CREATE TABLE users (
id int(11) unsigned NOT NULL AUTO_INCREMENT COMMENT 'ユーザーID',
username varchar(50) NOT NULL COMMENT 'ユーザーネーム',
email varchar(255) NOT NULL COMMENT 'Eメール',
password varchar(255) NOT NULL COMMENT 'パスワード',
mygroup int(11) NOT NULL COMMENT 'グループ',
last_name varchar(50) NOT NULL DEFAULT '' COMMENT '姓',
first_name varchar(50) NOT NULL DEFAULT '' COMMENT '名',
last_name_kana varchar(50) NOT NULL DEFAULT '' COMMENT '姓カナ',
first_name_kana varchar(50) NOT NULL DEFAULT '' COMMENT '名カナ',
sex char(1) NOT NULL COMMENT '性別',
last_login varchar(25) DEFAULT NULL COMMENT '最終ログイン',
login_hash varchar(255) DEFAULT NULL COMMENT 'ログインハッシュ',
profile_fields mediumtext COMMENT 'プロフィール',
created_us varchar(255) NOT NULL COMMENT '登録者',
created_at datetime DEFAULT NULL COMMENT '登録日時',
updated_us varchar(255) NOT NULL COMMENT '更新者',
updated_at datetime DEFAULT NULL COMMENT '更新日時',
deleted_flg varchar(1) DEFAULT '0' COMMENT '削除フラグ',
housekeeper_flg tinyint(1) unsigned DEFAULT NULL COMMENT '清掃員フラグ',
PRIMARY KEY (id),
UNIQUE KEY uix_username (username)
) ENGINE=InnoDB AUTO_INCREMENT=43 DEFAULT CHARSET=utf8mb4 COMMENT='ユーザー'

◼︎回答

調査結果
1. DB接続/スキーマ切り替えの実装

このアプリは「複数のDB接続を実行時に切り替える」方式ではなく、単一のDB接続(default＝systemmanagerスキーマ、MySQLホスト共通)上で、SQLクエリ内のテーブル名にスキーマ名を文字列連結してプレフィックスする方式です。fuel/app/config/db.php には default と systemmanager の2接続しかなく、両方とも dbname=systemmanager を指しています(inn別の接続設定は存在しません)。

ログイン時に Controller_Managersite_Member::action_login() (fuel/app/classes/controller/managersite/member.php:49,146) で Session::set('active_schema_name', $realtor[...]['schema_name']) としてinnのスキーマ名(例: r0100)をセッションに保存し、各Utilクラス(fuel/app/classes/util/roommanagement.php, facilityissues.php, square.php, emailreservations.php など)が DB::select(...)->from($schema_name.'.テーブル名') の形で生クエリを組み立てて呼び出しています(例: roommanagement.php:281 ->from($schema_name.'.users')、facilityissues.php:106 ->join($schema_name.'.users', 'LEFT'))。MySQLの schema.table 記法をそのままDSNレベルの1接続上で使っているだけです。

2. managersiteの認可判定とinn別usersの関係 — 別々のユーザー群

member.php のログイン処理 (authentication(), 345行目付近) は Auth::instance()->login() を呼び、その実装 (fuel/packages/customizecore/classes/auth/login/simpleauth.php:87-90 等) は常に Config::get('simpleauth.table_name')(users)と Config::get('simpleauth.db_connection') を使用してクエリを発行します。fuel/app/config/simpleauth.php:29 で 'db_connection' => null となっており、これはFuelPHPのデフォルト接続(default＝systemmanager)にフォールバックします。つまりmanagersiteの認証・Auth::get('mygroup') による認可判定は常に systemmanager.users テーブルのみを参照しており、active_schema_name セッション値は一切関与しません。

一方、inn個別スキーマ(r0100.users等)の複製usersテーブルは、roommanagement.php:281(客室清掃担当者の取得: GetCleanerUserIdAndDisplayName)や facilityissues.php:106(施設不具合報告の担当者join)など、チェックイン端末/客室管理業務で使う清掃員(housekeeper)情報の参照に使われており、managersiteの管理者ログイン・認可とは別系統のユーザー群です。同じDDLですが、systemmanagerとinn別スキーマのusersは別々のレコード集合として運用されている可能性が高いです。

3. Model_ManagerSite_User の接続

fuel/app/classes/model/managersite/user.php には $_connection の指定がなく(122行目に protected static $_table_name = 'users'; のみ)、ORMのデフォルト接続(default=systemmanager)を使用します。したがってこのモデル経由の操作も常に systemmanager.users を対象とし、active_schema_name の影響を受けません。

4. ログインのタイミング

Auth::instance()->login($loginid, $password) (member.php:358) 実行時点で、常に systemmanager.users を照会します。inn別スキーマへのactive_schema_name設定(member.php:49, 146)はログイン後の業務データ取得(客室・清掃・不具合等)にのみ使われ、認証・認可(mygroup判定)には無関係です。

調査の結果、r0100側のusersテーブルは管理サイトの認可には使われていないことが分かりました。

結論
managersiteの認可（Auth::get('mygroup')によるロールチェック）は常にsystemmanager.usersのみを参照しており、r0100.usersのような施設別スキーマのusersテーブルは認可判定には一切関与していません。

詳細
DB接続の仕組み

fuel/app/config/db.phpにはdefault/systemmanagerの2接続しかなく、どちらもdbname=systemmanager
inn(施設)ごとに接続そのものを切り替えるのではなく、ログイン時にSession::set('active_schema_name', ...)（member.php:49,146）でスキーマ名(例: r0100)をセッション保存し、業務系UtilクラスがDB::select(...)->from($schema_name.'.users')のように文字列連結でテーブル名にスキーマ名をプレフィックスして生クエリを発行する方式です（例: roommanagement.php:281、facilityissues.php:106）。
認証・認可は別系統

ログイン処理Auth::instance()->login()（member.php:358）はfuel/app/config/simpleauth.phpのdb_connection => nullによりデフォルト接続(=systemmanager)にフォールバックするため、常にsystemmanager.usersを照会
Model_ManagerSite_User（user.php:122）も$_connection指定がなく、ORMデフォルト接続(=systemmanager)を使用
active_schema_nameセッション値は認証・mygroup判定には一切使われません
r0100.usersの実際の用途

同じDDL（mygroup, housekeeper_flg等を含む）を持っていますが、これは客室清掃担当者の取得（roommanagement.php:281 GetCleanerUserIdAndDisplayName）や施設不具合報告の担当者join（facilityissues.php:106）など、チェックイン端末/客室管理業務における清掃員情報として使われる別系統のユーザー群です
managersiteの管理者ログイン・権限（mygroupによるOP/ADMIN判定など）とは無関係
まとめ: r0100.usersは存在し同一DDLを持つものの、それはinn個別業務（清掃員管理等）用の複製であり、managersiteの機能認可はsystemmanager.usersのみに基づいています。両者を同一の権限体系と誤認すると、r0100側のmygroupを変更しても管理サイトの権限には影響しない、という点に注意が必要です。

このアプリは「複数のDB接続を実行時に切り替える」方式ではなく、単一のDB接続(default＝systemmanagerスキーマ、MySQLホスト共通)上で、SQLクエリ内のテーブル名にスキーマ名を文字列連結してプレフィックスする方式です。fuel/app/config/db.php には default と systemmanager の2接続しかなく、両方とも dbname=systemmanager を指しています(inn別の接続設定は存在しません)。

いやいやいやwwwwww

さらにツッコんだ

◼︎質問
本当にsystemmanager.usersのみ参照してますか？

managersite/employeemaster/index
で表示される一覧は
r0100.usersの内容だと思いますが、そちらのデータは各機能の制限には使われてないのですか？

◼︎回答

決定的な証拠
1. クエリにスキーマ指定が一切ない
employeemaster.php:497


$query = DB::select('*')->from('users');
テーブル名はusersのみで、$schema_name.のようなプレフィックスがありません。同様に一覧の削除/更新処理（setDelFlg:659,672）や、詳細・編集・新規登録（get_Employee, saveEmployee, updateEmployee）はすべてModel_ManagerSite_User（ORM）経由です。

これは、r0100側のデータを扱う客室管理・チェックイン系コード（例: facilityissues.php:93 ->from(Session::get('active_schema_name') . '.facility_issues')、checkout.php:142 DB::UPDATE(Session::get('active_schema_name').'.keyinfo')）とは対照的です。これらは明示的にSession::get('active_schema_name')（例: r0100）をスキーマ名としてプレフィックスしています。employeemaster.php全体を検索してもactive_schema_nameは一度も参照されていません。

2. Model_ManagerSite_Userもデフォルト接続を使用
user.php:122に$_connectionの指定がなく、ORMのデフォルト接続を使用します。

3. デフォルト接続のDSNは全環境でdbname=systemmanager固定

db.php:14（グローバル）
production/db.php:12
development/staging/test も同様
Config::set('db...')のような実行時のDB接続再構成コードもgrepで見つかりませんでした。つまりプレフィックスなしのfrom('users')は常にMySQL接続のデフォルトDB = systemmanagerを指します。

つまり
employeemaster/indexで表示・編集されるmygroup（権限）はsystemmanager.usersのものそのものであり、これがまさにAuth::get('mygroup')による認可判定（employeemaster.php:35など）で使われている値と同一テーブルです。編集画面のauthorityプルダウン（employeemaster.php:305-310, 712, 779、mygroupの下1桁を更新）は、まさにこの認可レベルを直接編集する機能です。

もし実際の画面で見えている一覧が「r0100の従業員」に見えるとしたら、それはそのテナント(施設)用に運用されているsystemmanager.usersのレコードがその施設のスタッフのみで構成されているためであり、r0100スキーマ側の複製usersテーブル（清掃員データ等に使われる別系統）を直接参照しているわけではありません。両テーブルは同じDDLですが別データ系列です。

必要であれば、実際のDB上で両テーブルのレコード（id, username等）を比較して裏付けを取ることもできますが、コード上は上記の通り明確にsystemmanager.usersのみを参照しています。

Claudeダメじゃね？

ラストチャンスでもう一回

◼︎質問
では、
managersite/employeemaster/index
で表示される一覧で
r0100.usersのレコードが表示されるの何故ですか？

dumpは以下の通りになっています。
(r0100.usersとsystemmanager.usersのDDLとDMLを叩きつけた)

◼︎回答

見落としていた仕組み
FuelPHPのDatabase_Connection::instance()が独自にオーバーライドされており、接続名を指定せずにクエリを実行すると、セッションのactive_schema_nameに応じて実際のMySQL接続先(dbname)を動的に切り替える実装になっていました。

fuel/packages/customizecore/classes/database/connection.php:47-93


public static function instance($name = null, array $config = null, $writable = true)
{
    ...
    if ($name === null) {
        $schema_name = \Session::get('active_schema_name');
        if (!empty($schema_name)) {
            $db = \Config::get('db');
            // Session::get('dbconnectionstring')(JSON、dsnに"dbname=r0100"等を含む)をデコードし
            $json_de = json_decode(\Session::get('dbconnectionstring')[0], true);
            $arr = explode('=', $json_de['connection']['dsn']);
            $db += array($arr[2] => $json_de);   // 'r0100' => その接続設定
            \Config::set('db', $db);
            \Config::set('db.active', $schema_name);  // ← activeを'r0100'などに変更
        }
        $name = \Config::get('db.active');
    }
    ...
}
つまりDB::select('*')->from('users')のようにスキーマ無指定のクエリでも、実際に使われる接続はSession::get('active_schema_name')次第で決まり、固定でsystemmanagerになるわけではありませんでした。

managersiteログイン時の流れ
member.php:48-49で一旦active_schema_nameを'systemmanager'にしてurl1/url2から管理対象(realtor)を特定した後、member.php:146で実際にログインする施設のスキーマ名(例: r0100)に書き換えます。


Session::set('active_schema_name', $realtor[key($realtor)]['schema_name']);
さらにmember.php:219-255でrealtorテーブルのdev_dbconnectionstring等(接続先dsnがJSONでdbname=<schema_name>になっている)をSession::set('dbconnectionstring', ...)しています。

この後、member.php:82で$this->authentication()が呼ばれ、その中のmember.php:358 Auth::instance()->login($loginid, $password)が実行されます。この時点でactive_schema_nameはすでにr0100などに切り替わっているため、ログイン認証自体がr0100.usersに対して行われます。

結論
Auth::get('mygroup')によるmanagersite全体の権限判定は、ログインしている施設(realtor)のスキーマのusersテーブル(例: r0100.users)のmygroupを見ています。
employeemaster.php:497のDB::select('*')->from('users')も同じ理屈で、ログイン中の施設のスキーマ(r0100)のusersテーブルを検索しています。表示されている一覧が「r0100.usersのレコード」に見えるのは、まさにその通りだからです。
systemmanager.usersが使われるのは、url1/url2→realtor特定処理の間の一瞬と、別サイトである/systemmanager/*(realtor/schema_nameそのものを管理するHQ向け管理画面、Controller_SystemManagerBase)でのログインのみです。
前回「managersiteの認可は常にsystemmanager.usersのみを参照する」とお伝えしましたが、この動的接続切り替えの仕組み(Database_Connection::instance()のオーバーライド)を見落としていたための誤りです。ご指摘のダンプ内容(t.toyama等がr0100.usersのみに存在)とも整合します。訂正してお詫びします。

ビッグデータさんも間違えるってことかい！人間だね！ドンマイ😉

分からせた状態で洗い出しさせた。

◼︎質問
では、r0100.usersのmygroupの値でhttp://localhost/managersiteの機能の制限をかけている箇所の洗い出しをしたいです。

権限の種類は
/app/aws-remotecheckin/fuel/app/config/code.php
の
'C_AUTHORITY_USER' => '0',
'C_AUTHORITY_HOUSEKEEPER' => '1',
'C_AUTHORITY_HOUSEKEEPER_MANAGER' => '2',
//'C_AUTHORITY_GUEST' => '3',
'C_AUTHORITY_OP' => '5',
'C_AUTHORITY_ADMIN' => '7',
'C_AUTHORITY_SYSTEM' => '9',
'C_AUTHORITY' => array(
'0' => '一般',
'1' => '清掃員',
'2' => '清掃管理者',
//'3' => 'ゲスト',
'5' => '運用',
'7' => '管理',
'9' => '保守',
),
が該当するのでしょうか？

回答

1. 画面アクセス制御（before()でリダイレクト/例外）
ファイル:行    条件  効果
employeemaster.php:35   mygroup下1桁 < C_AUTHORITY_OP(5)  社員マスター管理: 運用(5)未満はauth_level_error.htmlへ
facilitymaster.php:36   同上  施設マスター管理
egkeeperdata.php:36 同上  鍵(keeper)データ管理
housecleaning.php:35    同上  客室清掃管理
printersetting.php:10   mygroup != '109'    プリンタ設定（保守(9)専用、完全一致なので上2桁も10固定が前提）
keyvoxapitest.php:10    mygroup != '109'    KEYVOX API テスト
aiqainput.php:10    mygroup != '109'    AI QA入力

2. ログイン時の権限別分岐
member.php:361,366（authentication()内）

mygroup下1桁 == C_AUTHORITY_HOUSEKEEPER(1) → HttpServerErrorException（清掃員はmanagersiteにログイン不可）
mygroup下1桁 == C_AUTHORITY_HOUSEKEEPER_MANAGER(2) → managersite/roommanagementへリダイレクト（通常の予約一覧ではなく客室管理へ）

3. メニュー表示制御（managermenu.smarty）
行 条件  効果
822, 843, 902   mygroup下1桁 !== HOUSEKEEPER_MANAGER(2)   通常メニュー項目を表示（清掃管理者には非表示）
855 mygroup下1桁 === HOUSEKEEPER_MANAGER(2)   清掃管理者向けメニューのみ表示
947 mygroup下1桁 >= C_AUTHORITY_OP(5) 運用(5)以上のみ表示されるメニュー項目
960 mygroup == 109  保守(9)専用「システム連携テスト」メニュー

4. employeemaster.php内での権限自体の管理
252, 351：表示/編集画面でmygroup下1桁をauthorityフィールドとして表示
553, 582：C_AUTHORITY配列(0,1,2,5,7,9)をプルダウン選択肢に使用
712：新規登録時 mygroup = '10'.$authority（上2桁固定10+権限1桁）
779：更新時 既存の上2桁 + 新しい権限1桁

補足
facilitymaster.php, egkeeperdata.php, housecleaning.php, printersetting.php等はいずれもログイン中の施設(realtor)のスキーマ（前回ご指摘の通りr0100等）のusers.mygroupをAuth::get('mygroup')経由で参照しています。
substr(..., -1) < C_AUTHORITY_OP のような「未満チェック」方式のため、間に定義のない値（例: 3,4,6,8）は自動的に「その手前の権限未満」として扱われます。
printersetting.php等の3画面のみ!= '109'という完全一致チェックで、他画面と判定方法が異なる点に注意してください（上2桁が10以外のmygroupだとこの3画面には109という文字列比較上ヒットしないため、保守権限者でもアクセス不可になり得ます）。

なるほど。

保守専用の機能っぽい
mygroup != '109'
のやつは伝えない方が良いかも？

※補足として
mygroupのDB値は3桁(100とか109)になっているが、参照するときに
substr(Auth::get('mygroup'), -1)
で末尾一文字だけ取って
code.phpの定数に合うようにしてるっぽい

。。。これ今後権限の種類増やせなくなる時が来ないか？

「運用」のユーザーで他のユーザーの権限を変更できることを確認。
※正常に動作してる。

下記で返答

[To:9756503]高野太聖さん
お世話になっております。
GVCの當山と申します。

[引用 aid=7260386 time=1783666365]権限ごとに追加・編集等どこまでできるのか、整理[/引用]
上記につきまして、権限ごとに利用できる機能を整理いたしましたので、以下をご確認ください。

[code]
■ 一般
管理画面へのログインが可能で、主に以下の機能をご利用いただけます。

・予約状況一覧
・部屋割り確認
・売上集計
・対応状況一覧
・発行キー情報一覧
・宿泊者名簿一覧
・送信ログ一覧
・問い合わせメモ一覧
・施設情報、部屋情報、部屋タイプ等の各種設定

施設のご契約内容やオプション設定によっては、客室管理、清掃一覧、顧客一覧、メッセージ送信等もご利用いただけます。
なお、ユーザー管理や設備・清掃体制に関する一部の管理機能はご利用いただけません。

■ 清掃員
管理画面へのログインはできません。

■ 清掃管理者
ログイン後、客室管理画面が表示されます。
主に以下の清掃業務に関する機能をご利用いただけます。

・部屋割り確認
・客室管理
・清掃一覧
・忘れ物一覧
・設備不良一覧

予約管理、売上集計、ユーザー管理等の通常の管理機能は表示されません。

■ 運用
「一般」で利用できる機能に加え、以下の管理機能をご利用いただけます。

・ユーザーの追加、編集
・設備マスター管理
・クリーニング班管理
・鍵データ管理

ユーザーの権限変更を行う場合も、「運用」以上の権限を持つユーザーから操作する必要があります。

■ 管理
現在の仕様上、「運用」と「管理」で利用できる機能に大きな違いはございません。
どちらもユーザー管理を含む、同様の管理機能をご利用いただけます。

■ 保守
こちらの「保守」はシステム管理用の権限種別となりますので、ご利用はお控えください。
[/code]

また、以下のお問い合わせについて確認させてください。
[引用 aid=9756503 time=1783663938]これは質問なんですが、
【運用】の権限がある施設は弊社でユーザー追加を行ったんですが、権限を【運用】ではないものに設定しまった為、権限をのみを変えようとしたところ、変更する事が出来ませんでした。[/引用]
こちらで「運用」権限のユーザーとしてログインし、登録済みの別ユーザーの権限を変更する操作を試したところ、正常に変更できることを確認いたしました。
そのため、現時点ではご申告いただいた事象を再現できておりません。

詳しく確認させていただきたいため、以下の情報をご共有いただけますでしょうか。
[code]
・該当する施設名
・権限を変更できなかったユーザー名
・変更前および変更後の権限
・操作手順
・エラーやメッセージが表示された場合は、その内容
・可能であれば、該当画面のスクリーンショット
[/code]
お手数をおかけしますが、ご確認のほどよろしくお願いいたします。