みんなに優しく、解りやすくをモットーに開設しています。 以下のルールを守りみんなで助け合いましょう。
1.ファイルメーカーで解らない事があればここで質問して下さい。 何方でも、ご質問・ご回答お願いします。 （優しく回答しましょう）
You are not logged in.
Pages: 1
File Maker Proを工程管理に使用しております。
工程管理の中で不良が出たときに、作成者権限のないに管理者にデータを削除してもらおうとしております。
そのため、スクリプトに「アカウントを追加」を付加しましたが、スクリプトを走らせると
「使用したアクセス権ではこの操作を実行できません」というダイアログが出てきます。
作成者権限のないに管理者に一時的にアクセス権を与える方法を教えてください。
よろしくお願いします。
バージョンと環境をまず最初に書きましょう。
［スクリプトを完全アクセス権で実行］というオプションがスクリプト毎に設定できます。
FileMaker Pro 13 以前であれば、スクリプトの編集ダイアログで
［スクリプトを完全アクセス権で実行］チェックオン
FileMaker Pro 14 以降であれば、スクリプトワークスペースで対象のスクリプトの編集状態で
［スクリプト］メニューから［完全アクセス権を付与］を選びます。（スクリプトパネル（左側の一覧）に人型のアイコンが表示されます）
https://www.filemaker.com/help/14/fmp/j … 15.18.html
データを削除（レコードを削除）したい場合は［レコード/検索条件削除］でレコードが消えます。
［アカウントを追加］では目的には合わないでしょう。
https://www.filemaker.com/help/14/fmp/j … 5.120.html
Last edited by Moz (2016-01-26 16:56:21)
Offline
スクリプトを完全アクセス権で実行
とすると誰もがそのスクリプトを実行できちゃいますよ。
フラグを立てる程度にして、
管理者がそのレコード削除とする。
とか方法を考えた方がいいかも、です。
Offline
作成者権限のないに管理者は、削除権限を持たせれば良いのですから、普通にアクセス権セットで設定できるのでは。
作成者には、作成権限と編集権限を持たせる。
管理者には、編集権減と削除権限を持たせる、
という事で良いのでは。
Offline
バージョンと環境をまず最初に書きましょう。
［スクリプトを完全アクセス権で実行］というオプションがスクリプト毎に設定できます。
FileMaker Pro 13 以前であれば、スクリプトの編集ダイアログで
［スクリプトを完全アクセス権で実行］チェックオンFileMaker Pro 14 以降であれば、スクリプトワークスペースで対象のスクリプトの編集状態で
［スクリプト］メニューから［完全アクセス権を付与］を選びます。（スクリプトパネル（左側の一覧）に人型のアイコンが表示されます）https://www.filemaker.com/help/14/fmp/j … 15.18.html
データを削除（レコードを削除）したい場合は［レコード/検索条件削除］でレコードが消えます。
［アカウントを追加］では目的には合わないでしょう。
https://www.filemaker.com/help/14/fmp/j … 5.120.html
失礼しましたバージョンはサーバとも１２でWIN7です。
削除ボタンを作成し、設定したスクリプトは
「レコード/検索条件削除」で「スクリプトを完全アクセス権で実行」にチェックオンしました。
ボタンを押すのは「全てのテーブルでの作成及び編集」する作成者権限者ですが業務の管理者なので利用が制限できると考えています。
ボタンを押しましたが、「使用したアクセス権ではこの操作を実行できません」と同じ表示がでます。
そのアカウントのスクリプトに対する権限が［すべてアクセスなし］になっているのでしょう。
［すべて実行のみ可能］に変更すれば実行できます。
完全アクセス権で実行するように設定しても誰でも実行できるわけではなく、
スクリプトを実行する権限がある場合にアカウントの権限では実行できないスクリプトステップがあっても実行できるようになります。
上で他の方も指摘されていますがスクリプトの実行権限があり、
スクリプトメニューやボタンなどからスクリプトの実行ができてしまうと他のアカウントでも削除できてしまいます。
そちらへの対策も検討したほうがよいでしょう。
Last edited by Moz (2016-01-27 09:04:34)
Offline
書き忘れ（汗）
もうひとつの可能性として、レコードを削除するテーブルが別のファイルの場合、
完全アクセス権を付与して実行しても別のファイルで削除の権限がなければエラーが出ます。
Offline
書き忘れ（汗）
もうひとつの可能性として、レコードを削除するテーブルが別のファイルの場合、
完全アクセス権を付与して実行しても別のファイルで削除の権限がなければエラーが出ます。
同じテーブルの作成者権限者のアクセス権を確認しましたが、スクリプトは「すべて実行のみ可能」になっておりました。
又、同じテーブルで削除させるスクリプトを作成し実行させています。
上手くいかないですね。
テーブルと書いているのはファイルのことですよね。
ボタンではなくスクリプトをスクリプトメニューから実行した際はどうなりますか？
スクリプトメニューに表示のチェックをしていれば作成者権限者のアカウントからも実行できるでしょう。
ステータスツールバーの削除ボタンおよびレコードメニューの［レコード削除...］は
完全アクセス権を持つアカウントと作成者権限者のアカウントそれぞれどのようになっていますか？
［レコード/検索条件削除］のステップを含むスクリプトをサブスクリプトとして実行されている場合、
サブスクリプトにも完全アクセス権を与える必要があります。
設定が誤っているのではと思われますが確認してみて下さい。
レコードの作成と編集、スクリプトの実行の権限をもつアカウントを追加してあります。
ボタンからそれぞれ完全アクセス権を与えた削除スクリプトと与えていない削除スクリプトを呼び出します。
http://yahoo.jp/box/PARuAi
完全アクセス権：
アカウント：Admin
パスワード：空欄
制限ユーザー
アカウント：User
パスワード：空欄
Offline
テーブルと書いているのはファイルのことですよね。
ボタンではなくスクリプトをスクリプトメニューから実行した際はどうなりますか？
スクリプトメニューに表示のチェックをしていれば作成者権限者のアカウントからも実行できるでしょう。ステータスツールバーの削除ボタンおよびレコードメニューの［レコード削除...］は
完全アクセス権を持つアカウントと作成者権限者のアカウントそれぞれどのようになっていますか？［レコード/検索条件削除］のステップを含むスクリプトをサブスクリプトとして実行されている場合、
サブスクリプトにも完全アクセス権を与える必要があります。設定が誤っているのではと思われますが確認してみて下さい。
レコードの作成と編集、スクリプトの実行の権限をもつアカウントを追加してあります。
ボタンからそれぞれ完全アクセス権を与えた削除スクリプトと与えていない削除スクリプトを呼び出します。
http://yahoo.jp/box/PARuAi完全アクセス権：
アカウント：Admin
パスワード：空欄制限ユーザー
アカウント：User
パスワード：空欄
済みません。ファイルの事です。
ボタンではなくスクリプトをスクリプトメニューから実行した際はどうなりますか？
スクリプトメニューに表示のチェックをしていれば作成者権限者のアカウントからも実行できるでしょう。
作成者権限でスクリプトメニューから実行しましたが「操作を実行できません」と同じ表示がでます。
ステータスツールバーの削除ボタンおよびレコードメニューの［レコード削除...］は
完全アクセス権を持つアカウントと作成者権限者のアカウントそれぞれどのようになっていますか？
完全アクセス権ではレコード削除が見えておりますが、作成者権限では見えません。
［レコード/検索条件削除］のステップを含むスクリプトをサブスクリプトとして実行されている場合、
サブスクリプトにも完全アクセス権を与える必要があります。
余り意味が分からないのですが、工程管理DBファイルに削除スクリプトを作成しています。
サンプルDB作成頂き大変有難う御座います。
工程管理DBと比較しました。
ファイルオプションアカウントがサンプルDBはAdminでしたのでUserに変更しましたが、サンプルDBでは削除できます。
アクセス権及び削除スクリプトは同じでした。
こちらでも新規サンプルDBを作成しましたが、作成者権限で削除できました。
従い、工程管理DBが何か違いがあるような？
リレーションが沢山あるのと、分離式？と呼ばれているので、それが理由でしょうか？
余り意味が分からないのですが、工程管理DBファイルに削除スクリプトを作成しています。
Aというスクリプトの中で［スクリプト実行］でBという別のスクリプトを実行しているような場合、
Aのスクリプトに完全アクセス権を与えても、Bのスクリプトの中で使われている実行できないスクリプトステップは実行できません。
この場合はBのスクリプトにも完全アクセス権を与える必要があるということです。
リレーションが沢山あるのと、分離式？と呼ばれているので、それが理由でしょうか？
これでしょう......
上ですでに書きましたがスクリプトが作成されているファイルと実際にテーブルがあるファイルが異なる場合
テーブルがあるファイル側での完全アクセス権がありませんのでスクリプトステップは実行できません。
テーブルがあるファイル側で削除の権限を得る必要があります。
・Bのファイルに設置した削除用のスクリプトに完全アクセス権を与えて削除する
・Bのファイルでレコード削除のカスタムアクセス権を設定して（グローバル格納のフィールドにフラグを立てるなど）
Aのスクリプトの削除スクリプトからフラグを立てて削除を行う
などの工夫が必要です。
Offline
とりあえずのサンプル
http://yahoo.jp/box/nfkjjL
Offline
とりあえずのサンプル
http://yahoo.jp/box/nfkjjL
何度も作成頂き有難う御座います。
インタフェースのファイルオプションのアカウントをUserに切替、（完全アクセス権で削除）と（一時的に権限を得る）でレコード削除出来ることを確認しました。
スクリプトの（一時的に権限を得る）は理解が難しそうなので、（完全アクセス権で削除）で試そうと考えています。
確認ですがレコード削除（完全アクセス権）のフィールド設定[テーブル：：＿ID；＄ID]はこちらで使っております工程管理番号に置き換えても良いと思われるのですが。
インタフェース側からデータ側のレコードを検索させるための役目でしょうか。
インタフェース側からデータ側のレコードを検索させるための役目でしょうか。
テーブルの主キーです。
呼び方は様々ですがデータベースの基本として各テーブルにデータベース全体を通して1意の値を持つフィールドは必須です。
「工程管理番号」が主キーで一意の値ならば利用して差し支えありません。
Last edited by Moz (2016-01-28 15:46:07)
Offline
MoZ様
有難う御座います。
データ側でスクリプトを作れるとは今まで知りませんでした。
お蔭様でテスト環境で成功しました。
来週には本番でテスト後、正式に使用する予定です。
サンプル内の二つのスクリプトで私が使用したことがないのがあります。
今後の設計に活かしたいので大変申し訳ありませんが、必要性についてご説明頂けないでしょうか。
〇印がその部分です。
〇If[Get(対象レコード数）]
スクリプト実行
End If
〇ウインドウの固定
〇変数を設定 [＄ID：値：Get（スクリプト引数）]
〇If[IsEmpty（＄ID）]
〇現在のスクリプト終了
〇End If
検索モードに切替
レイアウト切替
フィールド設定
検索実行
〇If[Get(対象レコード数）]
レコード/検索条件削除
End If
ウインドウを閉じる
〇If[Get(対象レコード数）]
スクリプト実行
End If
レコードを削除するのですからレコードが存在しなかったり
対象レコードが表示されていない状態では実行する必要がありません。
対象レコードがある場合のみ実行します。
〇ウインドウの固定
〇変数を設定 [＄ID：値：Get（スクリプト引数）]
〇If[IsEmpty（＄ID）]
〇現在のスクリプト終了
〇End If
［ウインドウの固定］はスクリプト中の画面描画を省略させスクリプトの実行速度を向上させます。
スクリプト実行の際にインタフェースファイルで表示中のレコードの主キー（__ID）を引数として渡しています。
データファイル側の［変数の設定］で引数を受け取ります。（ファイル間で値の受け渡しを行う場合の手法のひとつです）
続く If では引数が渡されなかったり空欄だったりすると続くステップを実行する必要がないのでスクリプトを終了します。
［現在のスクリプト終了］の前に［ウインドウを閉じる］を追加したほうが良いですね。
最後の If は検索の結果がなかった場合はレコードを削除できない（必要がない）ので
レコードがあった場合のみ［レコード/検索条件削除］を実行します。
スクリプトは組んだとおりにしか動きませんが途中で与えられるはずの値が想定外になったり、
あるはずのレコードがなかったりすることがないとは言い切れません。
そのような場合に備えた組み立てが大切だと思います。
Offline
Moz様
想定外の対応策も今後組み入れ利用者からの苦情も無くしたいと思います。
本日本番環境でテストし正式に動かしております。
少し脇道にそれますが分離DBの場合、別ファイルとリレーションはインターフェース側の設定のみと思うのでが、
データ側でも必要であった記憶があります。
その様な条件はあるのでしょうか。
それにしても分離DBは初心者には邪魔くさく難しいですね。
ファイルとのリレーションはできないので
別ファイルのテーブルに基づくテーブルオカレンスとのリレーションのことですかね？
あるいはデータファイル側でもリレーションを作る必要があるか否かですかね？
前者は必要があれば作ることもあるかなあと思いますが、敢えて作ることはないですね。
後者は例えば "注文" と "注文明細" の親子的な構造で構成しているケースで
"注文" テーブルのフィールドで "小計" のような計算結果を必要とした場合は作らざるを得ません。
それらの是非を問うのは答えの無い宗教戦争になるので不毛なことだと個人的には考えています。
分離は便利ですがお察しの通り面倒と感じられる部分があるのも事実なので
必要に応じて分離にしたりしなかったりと選択すればよいでしょう。
Last edited by Moz (2016-02-01 16:49:28)
Offline
分離ファイルの場合、インターフェース側はスクリプト等の実施権限を管理し、データ側ではデータその物の管理権限で管理が必要です。一般的にはそれを同じように設定しておき、同じグループで管理するのですが、場合によっては、別のくくりで管理も可能です。複雑になりますが、数百人にアクセスがある様なシステムですと、部署毎にインターフェースが異なり、階層毎に編集権等が異なるようになる事があり、その組み合わせで多くのアクセス権を作る必要があるので、ファイル毎にアクセス権を管理すると逆にシンプルになる可能性もあります。
そのような場合には、アカウント毎のアクセス権管理を行うファイルを作り、そこから自動的に各ファイルのアカウントを作成したりできるようにしたり、または、LDAP を使って管理したりするのが一般的でしょうね。
Offline
ファイルとのリレーションはできないので
別ファイルのテーブルに基づくテーブルオカレンスとのリレーションのことですかね？
あるいはデータファイル側でもリレーションを作る必要があるか否かですかね？前者は必要があれば作ることもあるかなあと思いますが、敢えて作ることはないですね。
後者は例えば "注文" と "注文明細" の親子的な構造で構成しているケースで
"注文" テーブルのフィールドで "小計" のような計算結果を必要とした場合は作らざるを得ません。それらの是非を問うのは答えの無い宗教戦争になるので不毛なことだと個人的には考えています。
分離は便利ですがお察しの通り面倒と感じられる部分があるのも事実なので
必要に応じて分離にしたりしなかったりと選択すればよいでしょう。
例えばサンプルDB（４０７１）に対し新規作成したファイルとリレーションさせる場合、データかインタフェースのどちらが良いのでしょうか。
リレーションさせないとルックアップができないので、確認したかったのですが。
フィールドオプションで［入力値の自動化］-［ルックアップ値］を使いたいならデータファイルですね。
インタフェースファイルにはテーブルはありませんよね？ルックアップの設定ができません。
Offline
お蔭様で工程管理ファイルはUserでレコード削除できるようになりましたが、下記エラー表示がでるようになりました。
表示タイミングには規則性がなく、管理者権限やプログラム作成・修正時にも発生しており頻度は少なくはありません。
現在はキャンセルを押しています。
解決方法はないでしょうか。
工程管理を開く
次のアカウントを使用して「工程管理」を開く
●アカウント名とパウワード（A）
アカウント名「 」
パスワード「 」
パスワード変更ボタン OKボタン キャンセルボタン
ODBCタイプのテーブルはインターフェイスファイルにもあります。
データファイルだけでは動作がしなかったそうです。
分離ファイルは運営途中から変更したためでしょうか、外部データソースとリレーションは混在しているような気がします。
今回の不具合に関係するのでしょうか。また正しくはどちらなのでしょうか？
データ インターフェイス
テーブル 〇 ODBCのみ〇
スクリプト × 〇
外部ﾃﾞｰﾀｿｰｽ
ﾘﾚｰｼｮﾝｼｯﾌﾟ
以上
ダイアログで［アカウント名］と書かれた入力欄には何も表示されていないのですか？
また、キャンセルした状態で正しく動作するのですか？
ODBCタイプのテーブルはインターフェイスファイルにもあります。
データファイルだけでは動作がしなかったそうです。
ODBC というのは外部データソースに ODBC を選択した ESS のことですよね？
"データファイルだけでは動作がしなかった" の意味が分かりません。
具体的にどのような状態でしょう？
データファイルを開く際にダイアログが表示される場合次のような原因が考えられます。
ファイルオプションで［次のアカウントを使用してログイン］が無効になっており
インタフェースファイルを開いているアカウントと同じアカウント情報（アカウント名・パスワード）のアカウントが存在しない。
ファイルオプションで［次のアカウントを使用してログイン］は有効になっているが
あとからアカウント名やパスワードを変更してしまった。
※ファイルオプションには存在しないアカウント名やパスワードも指定でき
セキュリティからアカウント情報を変更しても追従して反映されることはありません。
必ずしも双方のファイルにアカウント情報を同じように作っておく必要はありません。
ファイルオプションで［次のアカウントを使用してログイン］が正しく設定されていれば
そのアカウント情報を使ってデータファイルは開かれます。
Offline
Ｍｏｚ様
回答が遅くなり申し訳ありません。
久しぶりにＦＭの仕事をしております。
本日も時々ですが、工程管理と関係なくところで
工程管理を開く
次のアカウントを使用して「工程管理」を開く
●アカウント名とパウワード（A）
アカウント名「 会社名」
パスワード「 」
パスワード変更ボタン OKボタン キャンセルボタン
が表示します。
ダイアログで［アカウント名］と書かれた入力欄には何も表示されていないのですか？
⇒会社名です。ＦＭインストール時の名称と思われます。
また、キャンセルした状態で正しく動作するのですか？
⇒キャンセルすると正しく動作します。
ODBCタイプのテーブルはインターフェイスファイルにもあります。
データファイルだけでは動作がしなかったそうです。
ODBC というのは外部データソースに ODBC を選択した ESS のことですよね？
⇒外部データソースのタイプがＯＤＢＣのことです。ＥＳＳとは知識不足で？
"データファイルだけでは動作がしなかった" の意味が分かりません。
具体的にどのような状態でしょう？
⇒ＦＭのテーブルはデータだけにあるのですが、ＯＤＢＣはインターフェイスにも登録しないとスクリプトやリレーションを動かなかったと聞いております。
データファイルを開く際にダイアログが表示される場合次のような原因が考えられます。
ファイルオプションで［次のアカウントを使用してログイン］が無効になっており
インタフェースファイルを開いているアカウントと同じアカウント情報（アカウント名・パスワード）のアカウントが存在しない。
ファイルオプションで［次のアカウントを使用してログイン］は有効になっているが
あとからアカウント名やパスワードを変更してしまった。
※ファイルオプションには存在しないアカウント名やパスワードも指定でき
セキュリティからアカウント情報を変更しても追従して反映されることはありません。
必ずしも双方のファイルにアカウント情報を同じように作っておく必要はありません。
ファイルオプションで［次のアカウントを使用してログイン］が正しく設定されていれば
そのアカウント情報を使ってデータファイルは開かれます。
⇒データとインターフェイスのファイルオプションを確認しましたが、作成者権限のｕｓｅｒが登録されており従来と変わりません。
必ずしも双方のファイルにアカウント情報を同じように作っておく必要はありません。
ファイルオプションで［次のアカウントを使用してログイン］が正しく設定されていれば
そのアカウント情報を使ってデータファイルは開かれます。
⇒データとインターフェイスのファイルオプションを確認しましたが、作成者権限のｕｓｅｒが登録されており従来と変わりません。
"従来と変わらない" とは具体的に？
質問者さんの報告だけでは上記引用部分の
"［次のアカウントを使用してログイン］が正しく設定されている" については依然として不明なままです。
別の可能性として「工程管理」のいずれかのトリガで実行されるスクリプトに［再ログイン］スクリプトステップが含まれているとか。
質問者さんが自身で確認していない伝聞情報が散見するのが気になりますね。
ファイル作成者または作業を行った方にファイル全容を確認するのが先決でしょう。
Offline
Pages: 1
[ Generated in 0.006 seconds, 7 queries executed - Memory usage: 622.84 KiB (Peak: 675.74 KiB) ]