Hi,

I'd like an employee with a (in CiviCRM) *permissioned relationship to employer - to be able to update Contact data for that particular employer (Organization) via the Webform CiviCRM Integration.

If I disable "Enforce Permissions" ->my test user (employee) can see all Organization Contacts (and their data) - as expected - and it's showing the correct one by default.

If I "Enforce Permissions" -> my test user (employee) can see none of the Organization Contacts (also not the one Employer record I'm looking for). My setup is just as you described it in the Using Webform CiviCRM Integration wiki (#Current employer).

If "Enforce Permissions" Admin can see all Organization Contacts -> because of the Admin permissions (Admin of course is not an employee of all Contacts I'm seeing). So this must be because of Drupal - CiviCRM module permissions.

Does the Drupal role that an employee's user account belongs to also require additional Drupal - CiviCRM module permissions (in addition to the "*permissioned relationship to employer" that already exists in CiviCRM)? Or am I missing something else?

-- KarinG

CommentFileSizeAuthor
#8 frog.png49.06 KBkaring

Comments

colemanw’s picture

colemanw commented

What version of CiviCRM are you using? Eileen recently fixed some CiviCRM api permission issues that would affect this scenario.

karing’s picture

karing
Location 🇨🇦
commented

Ah... downgraded this particular site to 4.1.6 as lots of functionality I needed was broken in 4.2.6 - I'll try reproduce this on 4.2 svn.

karing’s picture

karing
Location 🇨🇦
commented

I see exactly the same thing on 4.2 svn - 43935. My test user either sees all of the Organizations (if I disable "Enforce Permissions") or my test user sees none of the Organizations (if I enable "Enforce Permissions". In case it sees all - the correct employer (default) is selected properly - so at least some relationship info is getting through. Will dig in to see if I can figure out what may be happening.

colemanw’s picture

colemanw commented

See http://issues.civicrm.org/jira/browse/CRM-11250

karing’s picture

karing
Location 🇨🇦
commented

Ok got it. Fixed in 4.3 - ah... that will take some time - I had the pleasure of attending the Toronto CiviCRM Code Sprint last week and fixed a couple of bugs in 4.3 - but it will take some time before that will be ready for release. It's an extensive overhaul of CiviContribute.

Do you have any clever ideas for possible workarounds for 4.1/4.2s?

karing’s picture

karing
Location 🇨🇦
commented

So the obvious thing to do would be:

- to change the Form Widget to static
- to check Yes "Display Contact Name" (of Organization)
- to set default contact from: Relationship to Contact 1 - Employer of Contact1
- to uncheck "Enforce Permissions"

This populates all webform fields with profile data for both personal as well as organizational record perfectly. Only downside would be if someone has two employers. It would pick the first match. That would be rare in this particular project. Ok, need to sleep on it.

colemanw’s picture

colemanw commented

You could download the commits from that issue as a patch and see if it will apply to 4.2. Probably would work with minimal complaining.
Unfortunately if you disable "check permissions" that leaves your form open to url manipulation - i.e. the user could view/update a different contact by putting ?cid2=123 in the url.
I'm not sure of your use-case - are you wanting the user to update sensitive information about an org that others shouldn't see?

karing’s picture

karing
Location 🇨🇦
commented
StatusFileSize
new frog.png49.06 KB

4.2 is not an option (still getting dozens of notices trying to create a FREE Membership by employee on behalf of organization and signing up for Drupal account in the process). I've started reporting and some things have been fixed - but yeah still dozens. I like fixing bugs - but don't know where to start there.

In 4.1.6 the above is all working. Perhaps we could try and patch 4.1.6 w/ the updated APIs and keep our fingers crossed.

These are not critical data by the way- and I'm only exposing a few custom project data fields. Attached is a screenshot. If a school has 100+ they get a letter and a banner congratulating them. That's the nature of this program that schools can enroll in for free.

Nevertheless, perhaps we can try and prevent URL manipulation by rewriting the URL to strip any ?cid= statements? Right now - viewing the webform as a teacher/employee: everything (default) is prefilled correctly and: the URL is /update-your-green-schools-program-data (name of the webform).

colemanw’s picture

colemanw commented

Yes it seem security isn't a big concern with that data. Although if I were you I would remove the first/last name fields and use the "existing contact" field for contact 1 to show the name in a non-editable way. That's just my personal pet peeve about people trying to enter a different person on a form and inadvertantly changing their own name.

karing’s picture

karing
Location 🇨🇦
commented

Ah... yes, of course. Done. Yep - I've seen that happen on more than one occasion. Thanks - I think I have a solution that will work. Merci.

colemanw’s picture

colemanw commented
Status: Active » Fixed

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

eileenmcnaughton’s picture

eileenmcnaughton commented

In general the permissioned employer relationship is not a 'true' ACL & only works in a limited range of places (not the api / webform it seems). I have recently worked on an extension to make it a true ACL

http://civicrm.org/extensions/relationship-permissions-acls

nzcodarnoc’s picture

nzcodarnoc commented

Hey there,

Confirming that the extension mentioned in #13 is working for me.

Thanks @eileenmcnaughton!