Hi Coleman - this might be an after effect of some summer time off.

Wanting to use a checksum to a form so that cid1 will see their cid2

if i do not disable permissions on cid2 webform component then cid1 sees nothing

if i do disable permissions then they do see their cid2 (who is a static component running off a relationship)

but if i do so then MYSITE/node/6?cid1=21645&cs=b69c3e3de2c0c216de08c976bf3acd92_1421186203_168

can be changed by the user to cid2= any number and hence see details of contacts in the db.

Hopefully I am missing something obvious

otherwise do i need to try and work up a token in civi for the cid of their spouse and include that in the link with the Permissions turned back on?

Comments

colemanw’s picture

Typically the way you do this (assuming it's non-"access CiviCRM" users we're talking about) is to

1) Ensure contact A has a permissioned relationship with contact B
2) Enable eileen's Relationship-as-ACL extension

petednz’s picture

Coming back to this. My testing back then and now suggests that despite eileen's acl awesomeness, the permissioned, checksummed anonymous user on the webform cannot load up contacts that they are permissioned to see.

Does that go against any logic you think should be happening? Eileen suggested it might be ajax, but seeing an existing contact field to select makes no difference.

As soon as I 'override' permissions on the webform component, i see the data i expect, but otherwise. nothing

would be a nice solution to have for situations where drupal users accounts are not ideal.

Any thoughts beyond 'just get out the spade and start digging'?

colemanw’s picture

Hmm, it's certainly supposed to work. But the ajax theory is a good one, since the user's checksum wouldn't be getting passed into the ajax call... maybe it should. To confirm the theory, try switching the widget to a dropdown select and see if that changes things.

petednz’s picture

sorry if my typing above wasn't clear, but yes we did test by setting existing contact to dropdown select and the field remains blank even though the contact has a permissioned relationship and Eileen's extension is on. It does fill only when i override permissions.
Happy to donate for an hour to core if that helps you jump in briefly and take a look

petednz’s picture

i presume the problem i am hitting has nothing to do with
http://drupal.stackexchange.com/questions/140841/how-to-ensure-civicrm-c...
as your module would already deal with all that

sonicthoughts’s picture

I just hit the same issue.
Goal:Create a webform for verification / update of contact info, spouse contact info and home info.

It seems to work when the user is logged in. When i generate a contact checksum, only the checksum contact permission is available. I verified that household, checksum contact and spouse all have update permission for each other. I'm not sure how to troubleshoot but happy to oblige.

I would guess that this is a common scenario to allow people to update their directory info for self and related members.

petednz’s picture

Just coming back to this. What would it take (hours estimate if you can without much digging) to allow us to have Relationships and/or Permissioned Relationships as an option under Filters?

FILTERS
Only contacts meeting filter criteria will be available as select options or default value.
Note: Filters only apply to how a contact is chosen on the form, they do not affect how a contact is saved.

colemanw’s picture

Pete - to clarify, are you looking to do this as a way to enforce permissions? And would getting the checksum contact to handle permissions correctly (e.g. in the same way as a logged-in user) also be an acceptable fix?

petednz’s picture

Yes getting a person using a checksum to end up with the same permission as if they were logged in would totally suffice.

Currently, iirc, going to a webform with a checksum requires the form to be available to Anonymous AND the permissions on other contacts on the form doesn't work as it would for logged in.

petednz’s picture

wondering aloud if this relates to this https://www.drupal.org/node/2802037 for when i have time to dig back

mpaulson’s picture

Status: Active » Closed (outdated)

This issue was filed against a branch (7.x-4.x) that is no longer supported. We're sorry we did not get to work through it, but once you upgrade to 7.x-5.x and if the issue persists, please feel free to re-open.