Jump to content
Salesforce and other SMB Solutions are coming soon. ×

Restrict Field Access on Content of other field


kirkrr
 Share

Recommended Posts

I have a set of fields in a bug tracking DB. As long as the bug status is "OPEN" I want the fields to be editable; if any other status, then no edits are allowed.

 

Attaching the following code to a field, does the trick FOR ONE FIELD

 

If [ Issues Tracking::Status = "Open" ] 
    Go to Field [ Issues Tracking::Subject ] [ Select/perform ] 
End If 

 

The question: Is there a way to use SELF or some other technique, so that this code (or some other completely different technique), can be applied to a dozen fields without changing the code for each.

Link to comment
Share on other sites

I'm going to assume that is a script trigger attached to your field(s)?

 

Instead of setting a condition for each specific field, why not look @ the converse condition, so:

 

If [ Issues Tracking::Status ≠ "Open" ]
Commit Record/Request[No Dialog]
End If

 

Attach this script to the onobjectenter trigger for fields. If debug is not open then it will automatically commit the record, which has the effect of denying user access to enter the field, rather crude but effective.

 

Not in 10? Are you just attaching a script to each field like a button, and then if debug is open you want to go to the field clicked? If so then I dunno of a way that is "soft coded". All the good options are in 10 for this kind of thing.

Link to comment
Share on other sites

Why not do it in the Privilege Set? Set up a formula for editing in the Issue Tracking table, requiring that Status = "Open". Now whenever it's not the record itself it not editable.

Link to comment
Share on other sites

Why not do it in the Privilege Set? Set up a formula for editing in the Issue Tracking table, requiring that Status = "Open". Now whenever it's not the record itself it not editable.

 

cos that's too easy!

Link to comment
Share on other sites

'cause the data is in a single TO, with both client problem reporting, and resolution reporting in the same layout. Status for the problem requires seeing the reported information; client review of the status requires viewing the resolution.

 

Hence the field level lockout requirement....

 

Yes, I could redesign the interface, or the tables, but this was supposed to be a simple exercise, using the FM issue tracking sample as a basis.

 

FM10 server, but FM9Adv development smiley-frown

AND deployed in IWP, with having to deal with IEs unique and irrational behavior, and all other browsers, that behave pretty consistently and are close to W3C standards compliant.

 

The field level conditional lockout works in FM, but not IWP, so maybe redesign is in the offing.

Link to comment
Share on other sites

Why not do it in the Privilege Set? Set up a formula for editing in the Issue Tracking table, requiring that Status = "Open". Now whenever it's not the record itself it not editable.

 

Back to the aspect that it is a single TO, so attempting field level locks, which don't seem to work in IWP.

 

I could either redesign the TOs to have one for problems and one for resolutions.

 

or ...

 

2 layouts, one with the results fields enterable (for resolutions), and one without (user).

 

Then either could be managed by privileges.

 

Don't know how to manage field level access by privileges.... ?

 

Sorry, Daniel - no script triggers. (FM9), just scripts directly attached to fields.

Link to comment
Share on other sites

Why not do it in the Privilege Set? Set up a formula for editing in the Issue Tracking table, requiring that Status = "Open". Now whenever it's not the record itself it not editable.

 

OK, Allan, I'm confused. :confused: I can manage field level access on or off by privileges, but how do I do that conditionally, based on a "status" field???

 

I have the resolution fields blocked from user input this way.

 

I need to block USER field entry as soon as a resolution is in process or closed, so that the "target" does not move.....

Link to comment
Share on other sites

OK, Allan, I'm confused. :confused: I can manage field level access on or off by privileges, but how do I do that conditionally, based on a "status" field???

 

Let's assume that everyone who is not you (the developer) uses a privilege set called "Users". For "Records", the Users Privilege Set is set to "custom": {See Fig One below}

 

When you open Custom Privileges, you get a list of tables and what the Users Priv Set folks have, in the way of privileges, per each table. Issue Tracking is one of the tables. It has a setting for the right to Create, the right to Edit, the right to View, the right to Delete, and field-level access for each individual field (view only/modify/no access). The one you're interested in is the EDIT privs; you want "limited": {See Fig Two below}

 

When you pick "limited", you get a formula box just like a calculation field's field def or the "specify calculation" part of a Set Field script step. You input:

 

Case (Status = "Open", 1, 0)

 

Now any individual RECORD in the table Issue Tracking is not editable to folks assigned to the Users privilege set except when the value of the field Status is "Open".

 

No scripting necessary.

Link to comment
Share on other sites

MOST AWESOME! smiley-tongue-out

 

I was dorking around with the limited / custom for individual fields in FIELD ACCESS, and shutting off edit rights, but this was an all or nothing proposition. To get that to work, I had to create a read only layout and an entry layout, and navigate conditionally, based on privilege set - an arduous road at best.

 

I had not tried out limited on edits; the thought just did not occur to me as a path.

 

Seems like I always take the longest/toughest path, based on ignorance of the alternatives. Thanks, I'll get right into this! smiley-laughing

Link to comment
Share on other sites

 Share



×
×
  • Create New...

Important Information

Terms of Use