Author Topic: Clarification re Profiles for changing Household or Organisational Custom Data (Read 3536 times)

petednz · October 14, 2008, 08:19:13 pm

Scenario - 2.1 Drupal.

An Individual is linked to a Household/Organisation and needs to be able to update the Custom Data of the Hh/Org - presumably via a Profile.

The profile could either be visible in their 'My Account' or via some other route.

The Profile would include Hh/Org fields (eg Organisation Name) - therefore it seems it cannot be visible to someone who is logged in as an Individual - even if that person has 'edit' rights over the Organisation as this only seems to give access to the 'core' data, not the custom data.

But I also understand that it does not allow Hh/Orgs to be able to 'login'

I understand that an Individual can go to the Dashboard and have access to their 'Organisation' if they have been given permission to do this via the Employee Relationship and then
- Edit Contact Information or
- view the Organisation's Dashboard

but neither seem to get the User the access they need to the Custom Data.

Am I missing something obvious (hope so).

Kurund Jalmi · October 15, 2008, 11:00:45 am

Can you try creating a profile with Organization field that you want to edit and then use it in edit mode.
eg: http://...../civicrm/profile/edit?reset=1&id=84&gid=1

HTH

Kurund

Dave Greenberg · October 15, 2008, 03:51:20 pm

Peter - This is really "not yet implemented" functionality. The permissioning in relationships gives a foundation for it - and it is possible to point a logged in Individual user to an organization profile in edit mode (as Kurund has stated). However there are some missing pieces:

* You can include via Drupal a navigation item / link to an organization profile - but you'll need some code (PHP code in a block??) to retrieve the list of permissioned orgs and hh with their ID's and format the links for them.

* Pretty sure that there is no "restrict access" permissioning yet on profile editing. So if they switch the contact ID in the URL they will be able to edit other organizations which they aren't permissioned for.

One decent solution (IMHO) is to replace the hard-coded edit form we currently provide access to from the Contact Dashboard with a configurable Profile. (Maybe a good project for Chris??) :-)

petednz · August 30, 2009, 08:34:51 pm

ok - looks like we are about to do some work on this - and wondering how closely this ties in to 'stoob's solution http://wiki.civicrm.org/confluence/display/CRMDOC/Enhance+Organizational+Membership+Functionality (EDIT: seems this document is now at http://wiki.civicrm.org/confluence/display/CRMDOC22/Enhance+Organizational+Membership+Functionality)

ALso, still trying to think around the long-term solutions - would having another 'type' of profile be the way to go - eg a 'permissioned' profile type that would be able to be used where 'onbehaflof.tpl' kicks in?

But on to the job in hand.

So ..../civicrm/contact/relatedcontact?action=update&reset=1&cid=XXX is the form you get to via Contact Dashboard, and clicking 'edit' against a contact for whom 'permissioned relationships' have been granted.

That .tpl states

Quote

{* This file provides the HTML for the edit Related contact form *}

{include file=CRM/Contact/Form/OnBehalfOf.tpl}

<div class="crm-submit-buttons">
{$form.buttons.html}
</div>

which sounds to me like it is just handing over the work to OnBehalfOf.tpl (which I note says "{* This file provides the HTML for the on-behalf-of form. Can also be used for related contact edit form. *}")

So, editing OnBehalfOf.tpl is part of 'stoob's recipe' - and in my test case, I have already configured that file for a Contribution Page ID#1 in CRM/Contact/Form/1 to include the following as per the recipe (in our ccase fields 41 and 42 are what I am testing)

Quote

{* Start Custom Data fields to be included in Organizational Details section of form *}
    <tr>{assign var=custom41 value=custom_41_-1}
    <td>{$form.$custom41.label}</td>
    <td>{$form.$custom41.html}</td>
   </tr>
   <tr>{assign var=custom42 value=custom_42_-1}
    <td>{$form.$custom42.label}</td>
    <td>{$form.$custom42.html}
    <br class="spacer"/>
<span class="description font-italic">This is a help-text detail here.</span>
    </td>
   </tr>
{* end Custom Data fields *}

So, hey, I thought maybe all i need to do is copy this file back up to CRM/Contact/Form which is where RelatedContact.tpl is expecting it - and maybe the fields that I am collecting on the Member inc Org sign up form will be present in the 'edit (related) contact details' (which kind of makes sense since the fields we are asking them to fill in during sign up are probably also the ones we want them to edit later on).

But no. Don't seem to have rendered any change at all. Wasn't really expecting it to be quite that simple. Can anyone help point out the steps 2-15 that I missed. Or was I on the right track?

petednz · August 30, 2009, 09:08:49 pm

so just confirming that CRM/Contact/Form/OnBehalfOf.tpl is where the tpl needs to be - as I am seeing the "This is a help-text detail here" snippet from the edits I made to that file - but obviously there is more to do to get the fields showing. (Pete notes to self, don't do this on a Monday in NZ when most of rest of world is enjoying their Sunday ;-) )

Dave Greenberg · September 01, 2009, 02:45:10 pm

Pete - the tpl file only renders form fields which are defined in the PHP class (file). It sounds like you skipped the part in Stoob's recipe that does that piece, beginning with "Now we are going to edit the PHP file" ...

petednz · September 01, 2009, 02:56:51 pm

Errm - I certainly didn't skip that bit (but worth checking with me) - but it is possible that we all missed some clue

however from an IRC with Kurund

kurund:we modified processOnBehalfOrganization() in Confirm.php
kurund:i think stoob had not included that code
kurund:may be check with Stoob for changes that we had made in Confirm.php

am waiting on a response from Stoob

if you have any further info you can add to this would much appreciate it

petednz · September 02, 2009, 03:43:45 am

so just to keep this logged

we received and implemented the changes to the file CRM/Contribute/Form/Contribution/Confirm.php - modifying it with our field ids.

Still no joy for either of us.

Have since received from Stoob his full set of customised files - wondering if Kurund can point out which others of these have changes that are required to ensure the data is recorded. Or if there are any other settings that might be overlooked?

We have checked that at least one of our test sites is using only Organization Fields that are Inline in case that was a factor (would it be?)

So here is the list of files per Stoob (in general he indicated we could spot Kurund's work as it was commented with webaccess but no such changes identified in the Utils.php so unclear if this is required or not) some of these are not marked by stoob as files Kurund changed so may be related to other customisations for stoobs client.

The below with an asterisk indicate we have implemented changes as per the (updated) recipe here http://wiki.civicrm.org/confluence/display/CRMDOC/Enhance+Organizational+Membership+Functionality. The lower list indicate other files in Stoob's system that have been customised but are not referenced in the recipe. (in the lower list those with K in brackets indicate they are referenced as being part of Kurund's work)

CRM/Contribute/Form/Contribution/Confirm.php*
CRM/Contribute/Form/Contribution/Main.php*
CRM/Core/Page/AJAX/Location.php*
CRM/Contact/Form/x/OnBehalfOf.tpl*
CRM/Contribute/Form/Contribution/x/Main.tpl*

CRM/Contact/Utils.php (K)
CRM/Contact/Form/Address.php (K)
CRM/Contact/Page/View/UserDashboard/GroupContact.tpl
CRM/Contact/Page/View/UserDashboard.tpl
CRM/Contribute/Form/Contribution/x/MembershipBlock.tpl
CRM/Profile/Page/x/Listings.tpl
CRM/Profile/Page/y/Listings.tpl

Rereading the recipe I realise that we took the phrase OPTIONAL at face value in the below but now I wonder if there might be something in here that is controlling the information in some subtle way we are overlooking.

Our Goal: we are wanting Individuals to register 'on behalf of' an Organisation but have 'organisation custom data fields' in the membership sign up form, that are filled out by the individual but which are then added to the Org's record.

Quote

OPTIONAL: If you want display any of this custom data on the confirmation page (I didn't), or to change how the data is processed, or how the relationship between the individual and the 'behalf of' organization is created do so in this file. I didn't have to do this myself, but you might want to. Here's a general idea of how:

From CRM/Contribute/Form/Contribution/Confirm.php at around line 1000

// i didn't need any edits to this page, but should you require them, it would be in the line 1000 range
// you could potentially:
// a. change the way the employee > employer relationship is built, with 'is_permission_a_b' or 'is_permission_b_a'
// b. change the type of relationship that is built altogether
// c. create a second, additional type of relationship creation possibly?

Kurund Jalmi · September 02, 2009, 04:12:13 am

Can you make following changes and check. Also use custom_php feature and replace custom field id's by your custom field ids.

Quote

--- Confirm.php.orig
+++ Confirm.php

@@ +426 @@
unset($params[$fld]);
}

+ foreach ( $params as $field => $value ) {
+ if ( $field == 'org_home_URL' ) {
+ $behalfOrganization['home_URL'] = $params[$field];
+ }
+ if ( $field == 'custom_4_-1' || $field == 'custom_5_-1' || $field == 'custom_6_-1') {
+ $behalfOrganization[$field] = $params[$field];
+ }
+ }

}

@@ +1029 @@
unset($behalfOrganization['organization_name']);
}

+ require_once 'CRM/Core/BAO/CustomField.php';
+ $customFields = CRM_Core_BAO_CustomField::getFields( 'Organization', false, true );
+ $behalfOrganization['custom'] = CRM_Core_BAO_CustomField::postProcess( $behalfOrganization,
+ $customFields,
+ CRM_Utils_Array::value('organization_id', $behalfOrganization),
+ 'Organization', true );

// create organization, add location
$org = CRM_Contact_BAO_Contact::create( $behalfOrganization );

HTh

Kurund

petednz · September 02, 2009, 01:51:12 pm

so for the record - implement above on the w.f site (abbrev. for eileen's benefit) but no change observed - data still failing to be added to record - despite finally being able to flush templates (though not yet cleared template_c folder) so at least am seeing latest round of changes in tpl

Still unsure if i am necessarily seeing latest changes to php files - is there any other caching going on?

meanwhile as i try and find a way around the (probably self constructed

] obstacle - and given my preference for using Profiles than hard coding fields in to place, can anyone comment on the following approach

Do the Memberhship form without any Org details, and once the civicontribute process is completed push people through to the 'permissioned profile' as per Lobo's presciption here http://forum.civicrm.org/index.php/topic,5699.msg25082.html#msg25082

Quote

I was just looking at the code when i realized we added code that allows the editing of profiles using permissioned relationships.

Thus if user A has permissioned relationship on contact id B then for any profile PPP, the url:

q=civicrm/profile/view?reset=1&gid=PPP&id=B
q=civicrm/profile/edit?reset=1&gid=PPP&id=B

Given that the drupal account won't have been verified at this point, might the above work - or only if we also 'create a session' and if the latter, what are the risks beyond other users taking over a machine that is logged in via the session?

petednz · September 03, 2009, 10:22:37 pm

So updating this saga - stoob provided his set of files, and that means i have a working version - I need to track through and verify if there is something missing from the wiki or if i just muffed something.

Anyhow I now have 6 Org Custom Data fields showing in a MemberSign Up page - one of the fields is a checkbox, the rest are just text.

when I use the form for an existing org, the form shows any pre-existing data in the text fields - but not for the checkbox.

Any suggestions where I need to check to see if the code is preventing the I expect it to show existing data in the Org custom fields) but while it does so for the text fields, the checkbox that should be CHECKED due to existing data, is not showing anything - any clues?

For comparison
CHECKBOX for Organisation Custom data that is NOT showing
<input type="hidden" name="custom_54_-1[eeny]" value="" />
<input id="custom_54_-1[eeny]" name="custom_54_-1[eeny]" type="checkbox" value="1" class="form-checkbox" />
<label for="custom_54_-1[eeny]">eeny</label> 

CHECKBOX for Individual Custom data that IS showing
<tr><td class="label"><label>Charactistics: another</label></td>
<td class="view-value">
<input type="hidden" name="custom_55[this]" value="" />
<input id="custom_55[this]" name="custom_55[this]" type="checkbox" value="1" checked="checked" class="form-checkbox" />

CiviCRM Community Forums (archive)

News:

Author Topic: Clarification re Profiles for changing Household or Organisational Custom Data (Read 3536 times)

petednz

Clarification re Profiles for changing Household or Organisational Custom Data

Kurund Jalmi

Re: Clarification re Profiles for changing Household or Organisational Custom Data

Dave Greenberg

Re: Clarification re Profiles for changing Household or Organisational Custom Data

petednz

Re: Clarification re Profiles for changing Household or Organisational Custom Data

petednz

Re: Clarification re Profiles for changing Household or Organisational Custom Data

Dave Greenberg

Re: Clarification re Profiles for changing Household or Organisational Custom Data

petednz

Re: Clarification re Profiles for changing Household or Organisational Custom Data

petednz

Re: Clarification re Profiles for changing Household or Organisational Custom Data

Kurund Jalmi

Re: Clarification re Profiles for changing Household or Organisational Custom Data

petednz

Re: Clarification re Profiles for changing Household or Organisational Custom Data

petednz

Re: Clarification re Profiles for changing Household or Organisational Custom Data