0

I have 2 applications, Controls and Tests.

Controls application has the cross-reference of Tests application.

Controls application has a Record Permission field 'Control Owner'. Tests application has a Record Permission field 'Test Performer'.

I have to validate these fields such that:

Control Owner and Test Performer cannot be the same User/Group.

System should not allow the selection of a User as 'Control Owner' if the user is listed as the Test Performer for any of the linked tests in the control.

Similarly, System should not allow the selection of a User as 'Test Performer' if the user is listed as the Control Owner for any of the linked controls for the test.

I tried adding a calculated field that would give me a flag indicating whether the users selected are same or no.

Please help!

Flak DiNenno
  • 2,193
  • 4
  • 30
  • 57
Tanveer Shaikh
  • 1,678
  • 14
  • 27

3 Answers3

1

Tanveer, I think that scenario you described can't be configured in Archer using available functionality. At least I can't come up with a solution based on my experience with Archer platform. The issue is that Archer doesn't allow you to calculate or filter user lists or cross-reference selections dynamically. And this is what you truly need in this case.

I can propose the following work-arounds though. I don't like both of them, but sometimes you've got to compromise.

  1. You can create a daily/weekly/monthly scheduled report. Someone from business will receive it showing a list of records where user names/groups match each other in Controls and Test applications. Business user will follow up and get all issues addressed manually.

  2. You can implement this functionality with custom object controlling user selection in Controls and Test applications. So you will need actually two custom objects.

    [a] You need a calculated field that will copy the value of the selected users via cross reference.

    [b] Custom object will hide this field from the end user by setting attribute display = none.

    [c] Custom object will need to override "Save" and "Apply" buttons in such a way that it will provide a validation of the selected users/groups and will compare them with a hidden calculated field where users/groups from the referenced record are stored. If the list has at least one common object, you can notify end user and make him fix it before record can be saved.

    [d] Note that calculated field will not work until the record is saved. This means that if a new record is added via "Add New" list provided by the cross-reference field, then you will have to create a cookie object in the web-browser in custom object 1 and read it with custom object 2 (and vice versa). Cookie will store selected users/groups in form 1 and custom object in form 2 will read it and decide if end user's selection in form 2 is correct.

    This is a complex two-sided custom object (two custom object will have to "communicate" with each other). I have implemented a similar behavior with cookie passing between custom objects before, but I recommend you to avoid solutions like this if possible. They are complex to code, complex to debug and complex to support.
    You can still use scheduled report to control data integrity in this case.

I hope this helps to some extend. Good luck!

Stan Utevski
  • 582
  • 2
  • 9
0

I have another solution for this, please advice whether it will work... I will create a calculated field called ControlEqualsTest and will have a value of True if the usergroup in Control equals usergroup in Test. During submit/save/apply, if ControlEqualsTest is True, then will fail the submit/save/apply with an error message

kishore
  • 1
  • You solution would work if you tell me how you plan to "fail" record submission. Archer can't prevent you from saving the record if the record is already opened in Edit mode. Am I wrong? – Stan Utevski Mar 10 '16 at 05:29
0

I found an working approach recently, the solution is to create an off layout hidden field and make it required only when the two record permission fields are the same

kishore
  • 1
  • 2
  • If I understand correctly, to check if two RPs have the same value, we will need a calculated field. Calculation will have to take place. So, if user selects same users in both the RPs and saves the record, it is an issue. How would it prevent the record from saving? – Tanveer Shaikh Jul 26 '16 at 10:12
  • There is no calculated field used, its just an off layout field that will be made required in a DDE event only if the two RP fields have same value – kishore Nov 06 '16 at 01:15
  • Ok, and how do you check if the two RPs have the same value? – Tanveer Shaikh Dec 19 '16 at 23:32