Author Topic: Simple solution for staff who keep using forms and over-writing their own data (Read 1311 times)

CiviTeacher.com · January 28, 2013, 09:10:34 am

I tried everything with a client:
1. training
2. blocks that 'warn' certain roles not to use public forms

But still staff people (while logged in as themselves) were going to civicrm/contribute/transact and filling out someone else's data and clicking submit. Of course we all know this over-writes their own data and causes a mess.

Finally I had to lock down the form.
1. Create a drupal block visible only to certain role (i.e. 'staff')
2. block visibility for this drupal block only to form pages like civicrm/contribution/transact or civicrm/event/register
3. Enter this jQuery code

Code: [Select]

<script>
cj("input#email-5").attr("readonly",true);
cj("input#first_name").attr("readonly",true);
cj("input#last_name").attr("readonly",true);
cj("input#email-5").css("border-width","0");
cj("input#first_name").css("border-width","0");
cj("input#last_name").css("border-width","0");
</script>

Note, if you are using D7 you will have to 'wrap' this like so, as described here:

Code: [Select]

(function (cj) {
  // All your code here
})(jQuery);

The result is a form that staff people cannot change the name and email. Combined with a link to the admin area, there is no way to f*** it up anymore.

Erik Hommel · January 29, 2013, 12:07:14 am

Thanks Stoob, appreciated!

CiviTeacher.com · May 05, 2013, 06:38:10 pm

I've done some refinement to this code, because in the unlikely event a contact has no first or last name recorded in CiviCRM, we do want to gather that data.

I've spoken to other consultants about pushing for this type of feature in Core, or at the very least as an extension. Maybe not with jQuery, but perhaps with a form rule or something, since that is a more robust solution. But this is working for me in a Drupal block or extra.tpl, for now. Note I've only been locking down names, not email, since people may want to change their emails.

Code: [Select]

<script>
cj(function() {
  if (cj("#first_name").val() != "") {
    cj("#first_name").attr("readonly", true).css("border", 0).css("background-color", "inherit");
  }

  if (cj("#last_name").val() != "") {
    cj("#last_name").attr("readonly", true).css("border", 0).css("background-color", "inherit");
  }
})(jQuery);
</script>

Eileen · May 06, 2013, 03:36:03 am

At the profile level there is the concept of read-only fields I think - but what is needed is a setting 'create only' which makes the field read only for logged in users

Hershel · May 06, 2013, 07:45:09 am

Readonly? Why not have the JS just redirect them to the right page?

CiviTeacher.com · May 06, 2013, 08:48:40 am

Hershel: They're already on the right page, but sometimes people are silly (including staff) and write in someone else's name when logged in and submit, thinking they are creating a new record. I want to prevent that.

Eileen: a jQuery solution will solve 90% of the problems, as that's about how many people enable browser Javascript. I'm cool will using jQuery if there is not a PHP based form solution out there. Maybe I can build an extension with ALL MY FREE TIME. Hehe.

xavier · May 06, 2013, 10:29:31 am

Hi,

Following stoob suggestion, I've wrapped it as an extension.

http://civicrm.org/extensions/noverwrite

PR more than welcome

https://github.com/TechToThePeople/noverwrite

totten · May 06, 2013, 11:58:07 am

Nice!

I think there may be some issues around form validation and "continue/back" buttons, e.g.

1. If you submit a form with a new first/last name and some invalid field (e.g. missing the credit card expiration date), then the form will rerender differently -- the first and last name fields won't be editable (even though they appeared as editable a few seconds prior).
2. If you fill in a new first/last name with a typo, continue to the confirmation page, and notice the typo on the confirmation page, then the "Go back" button won't work as expected -- going back will take you to a page where the first/last name are read-only.

You can probably fix this by changing the tested condition. Instead of using JS to check whether the HTML <INPUT> is empty, use PHP (inside hook_civicrm_buildForm) to check whether the contact is new (missing an ID) or whether it's genuinely missing the first/last name (by checking the database).

xavier · May 06, 2013, 12:42:25 pm

Hi,

So quickform has probably been designed by rube goldberg when he was doing a bad trip on acid.

I've freezed at the php level, not js one and tested if the contact (userid) was set and the field was set too.

I've added billing_xx_name too, seems present on another extension I'm working on (direct debit)

Can someone install the extension, test and confirm?

X+

CiviTeacher.com · May 06, 2013, 01:58:39 pm

I offer that #billing_first_name should not have a lock down. It is possible someone is paying with corporate card or a family member's card, and the billing_first_name should always be editable.

xavier · May 06, 2013, 02:51:44 pm

Good point, changed and only "normal" first and last names then

X+

CiviCRM Community Forums (archive)

News:

Author Topic: Simple solution for staff who keep using forms and over-writing their own data (Read 1311 times)

CiviTeacher.com

Simple solution for staff who keep using forms and over-writing their own data

Erik Hommel

Re: Simple solution for staff who keep using forms and over-writing their own data

CiviTeacher.com

Re: Simple solution for staff who keep using forms and over-writing their own data

Eileen

Re: Simple solution for staff who keep using forms and over-writing their own data

Hershel

Re: Simple solution for staff who keep using forms and over-writing their own data

CiviTeacher.com

Re: Simple solution for staff who keep using forms and over-writing their own data

xavier

Re: Simple solution for staff who keep using forms and over-writing their own data

totten

Re: Simple solution for staff who keep using forms and over-writing their own data

xavier

Re: Simple solution for staff who keep using forms and over-writing their own data

CiviTeacher.com

Re: Simple solution for staff who keep using forms and over-writing their own data

xavier

Re: Simple solution for staff who keep using forms and over-writing their own data