editing LoggedInUser details

greg

I set up a new form named Update for Staff object for
want staff to use this form to update their own details only.

I added this rule to the Staff object to allow only the logged in user
to edit their details:

If LoggedInStaff.ID<>Staff.ID Then
PROTECT Staff FROM ALL EXCEPT Administrator AND
System

I also added a process UpdateStaffDetails

FIND Staff WHERE Staff.ID=LoggedInSystemUser.ID and then
VIEW Staff USING Main

When I tried to VIEW Staff USING Update the system reported an error:

Syntax error at token "Update", (column 18-). Was expecting tokens:
<STRING_LITERAL> or <IDENTIFIER>

What am I doing wrong?

aware_support2

You are probably getting the error because the form name uses a reserved word - there is Update action in the rule language. If you change the name the problem should go away. Also, your PROTECT rule will disallow a staff member to edit his own details because it specifically protects Staff object from Staff access level.

There is an easier way in the system to achieve what you want without adding any processes or rules:

Specify (in the form editor) that the new Staff form should be used only for Staff access level.
Set Staff access level for object Staff as 'Creator: modify, others: read-only'.
Add menu item of type 'Change login details'. When a user clicks this item, the system will display his details for editing using the form specified for his access level (see #1). The system will automatically determine the logged-in user and his object type.

greg

Change of the form's name has fixed the first problem.

Regarding user access to their details, my aim was to let a user to change their data, for example, change their password. I did not want to set access level to

'Creator: modify, others:read-only'

because a record can be created by someone else, for example, imported from file, but I wanted a user to be able to access some of their own details. And I thought that this rule is doing exactly that.

aware_support2

'Creator: modify, others: read-only' will work for you because the system uses attribute LoginName to determine who is the creator (actually, the owner) of the instance. Non-intelligent objects will have attribute LoginName added to them if there is an creator-dependent access defined for the object. In case of intelligent objects, like Staff, attribute LoginName is already part of the object, and its value will be the login name of the registered staff member - even if it was created by an administrator or the system.

That is why you do not need the additional rule.

greg

Thanks for explaining this point to me. I had no idea how a creator is traced.