Hi to all SC member,
Is there any tips or tutorial provide guide to limit user to only can insert, view and edit the data belong’s to themself?
Please advice, thank you.
The first thing you need to do is identify the user. You can do that with the Security Module. When you apply the Security Module, a global variable is created that can be used to identify the user within the apps. You can also use the User Groups within that module to set permissions for Insert, Update, Delete, etc. on specific apps.
The Security Module is applied via a wizard, so it is pretty easy to set up. It will create all of the tables it needs. There are some samples in the Samples Code that you can look at as well.
[QUOTE=lesliez;18632]Hi to all SC member,
Is there any tips or tutorial provide guide to limit user to only can insert, view and edit the data belong’s to themself?
Please advice, thank you.[/QUOTE]
The useual approach would be to define a creator field in the appropiate tables where you need this. This creatorid is used in the logon procedure and applied to a global variable i.e. [glob_creator]. In every sql where you need this to happen you apply the ‘where creator=[glob_creator]’. Make the creator field read-only by setting clicking the labelfield radio button on the fields description page. Other option, remove it from your screen in edit fields. Hope this helps.
1 Like
Hi Travelr,
I’ve already setup Security for Group.
Hi Albert,
Should I make a new field in the user table to identify user identity? Then add relation between the user table and the data table? Can that work?
It depends on what you exactly want. Is everybody allowed to look, but only the owner may alter, or is everybody only allowed to see/modify his/her own data. It’s - technically spoken - not a big issue, but it will influence your design. Besides that it matters if the user is only altering his/her own ‘profile’ data or a manager who is only allowed to work with his own pool of employees.
In general it is necessary to see who’s the owner of a record. Sometimes you can derive that, i.e. on departmentid. Sometimes you can’t. In that situation I add a field to this table containing the owner as described earlier. In the authentication table I add most-of-the-time an initial which is used in my updates. The reason is that on the initials I can see who it is, which is comfortable when somebody is deleting a user instead of inactivating him/her. In general I alway want to know who has made the mutation although you can do that by setting the log on. But it requires a lot of analizing when you have some issue to solve as the log is great as an audit trail, but not very accessable.
If you can describe a bit more precise of what you want to achieve I will try to give you some better advise.
Hi,
I need some advice from you guys.
I almost come to a conclusion that I will create an additional field in the Data Table, the additional field will be “owner”. So I was thinking this “owner” will be a hidden field when the Owner enter a new data and the “owner” field data will be the user’s Email Global Variable.
So in the future, to only display the User’s own data, will be recognise by the “owner” field email address.
The Problem:
But I find that there will be a problem if the owner change their email address. I cannot stop them and don’t allow them to change email address.
My plan (need advice):
In the generated security user data table, is it ok that I add an additional field into it called “ownerid” and set Auto-increment to it and set it index? So in the Data Table, I can link a foreign key field to the Data Table.
In this way, My data can recognise Owner by “ownerid” and the Owner can change whatever email address they like.
My question:
- Can the plan work?
- Can the Security User table contain 2 Primary Key?
I’m not a programmer so I’m not sure about 2 Primary Key in a table. Will that cause conflict to SC security module?
Please advice, thank you.
There can only be one primary key, but you can create a second unique index. Owner doesn’t need to be a hidden field, just remove it from the screen. The field will still be there.
Yes the email can change and that’s why I don’t recommend it to use it as a userid. To change the userid you need to create a manual sql update as Scriptcase cannot generate cange of primary key.
Hi Albert,
So now for the purpose of forcing user to use email as login username, I can use the scripts/macros to achieve that.
For the data owner, as you advice, I will create an additional field in the Security Module generated “User” table, name the field “ownerid” and set it Unique, Index and Auto-Increment.
So in the future, I will use “ownerid” as the row identifier.
Is that correct? Please advice, thank you.
Hi Travelr,
I have created the Security using wizard for Group.
I check the login app, the global variable only have “usr_login” and “usr_email”.
May I know how to get the “user_group” global variable so that I can use that to redirect user. Thanks.
[QUOTE=lesliez;18696]Hi Travelr,
I have created the Security using wizard for Group.
I check the login app, the global variable only have “usr_login” and “usr_email”.
May I know how to get the “user_group” global variable so that I can use that to redirect user. Thanks.[/QUOTE]
You have to dive into the code I’m affraid. Somewhere the group is fetched to prepare the visiblity of menu items etc. If the variable is not exposed you can do so by setting a global variable of your own like:
[usr_group]=the group variable;
Hi Albert,
I’m sorry I don’t understand this line;
If the variable is not exposed you can do so by setting a global variable of your own like:
[usr_group]=the group variable;
How to create own variable with the groupid? Is it on event to run SQL statement to get the user’s groupid and set the return result as global variable? Some hints please. Thank you.
I create the group id global variable in the Login app, onValidate event. Here is a sample of what I do to create it:
$gsql = “SELECT
group_id
FROM users_groups
WHERE login = $slogin”;
sc_lookup(rsg, $gsql);
if(count({rsg}) > 0)
{
$user_group_member = {rsg[0][0]};
sc_set_global($user_group_member);
}
The macro sc_set_global will be discontinued soon according to the manual.
So
$user_group_member = {rsg[0][0]};
sc_set_global($user_group_member);
should be written as
[user_group_member] = {rsg[0][0]};
Hello,
I had thought like you. But I have read elsewhere on the web that it is dangerous to use email as a recognition key. What I am pretty sure: it is better to use the nickname or user. How to manage it is another matter.
Who is capable of producing that here? Nothing on SC. Or rather, a few months ago I saw a video dealing with this problem. But how to find her?