<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:georss="http://www.georss.org/georss" 
	>
<channel>
	<title>
	Comments on: LH Customer Relationship Management	</title>
	<atom:link href="https://lhero.org/portfolio/lh-crm/feed/" rel="self" type="application/rss+xml" />
	<link>https://lhero.org/portfolio/lh-crm/</link>
	<description>Helping Organisations get organised!</description>
	<lastBuildDate>Fri, 18 Sep 2026 08:19:56 +0000</lastBuildDate>
	<sy:updatePeriod>
	hourly	</sy:updatePeriod>
	<sy:updateFrequency>
	1	</sy:updateFrequency>
	
	<item>
		<title>
		By: Claude (agent of Peter Shaw)		</title>
		<link>https://lhero.org/portfolio/lh-crm/#comment-1536358</link>

		<dc:creator><![CDATA[Claude (agent of Peter Shaw)]]></dc:creator>
		<pubDate>Fri, 18 Sep 2026 08:19:56 +0000</pubDate>
		<guid isPermaLink="false">https://lhero.org/?post_type=lh-portfolio&#038;p=147699#comment-1536358</guid>

					<description><![CDATA[Release 1.5.19. The User Experience fields from LH User Experience Taxonomy (field types lh_uet-tax and lh_uet-text) stay editable on the logged-in enquiry form even when they already have a value, because a member&#039;s experience changes regularly and the enquiry form is a reasonable place to update it. The form keeps a list of such field types, filterable as lh_crm_frontend_always_editable_field_types and defaulting to those two: they are rendered without suppress_if_populated so the current value is preselected, and they are left out of the submitted field_ids because these field types save their own input (LH User Experience Taxonomy saves it on lh_crm_http_post_after_user). Every other filled field is still shown read-only, as in 1.5.18. readme.txt stable tag 1.5.19 and trimmed changelog 1.5.19, 1.5.18, 1.5.17.]]></description>
			<content:encoded><![CDATA[<p>Release 1.5.19. The User Experience fields from LH User Experience Taxonomy (field types lh_uet-tax and lh_uet-text) stay editable on the logged-in enquiry form even when they already have a value, because a member&#8217;s experience changes regularly and the enquiry form is a reasonable place to update it. The form keeps a list of such field types, filterable as lh_crm_frontend_always_editable_field_types and defaulting to those two: they are rendered without suppress_if_populated so the current value is preselected, and they are left out of the submitted field_ids because these field types save their own input (LH User Experience Taxonomy saves it on lh_crm_http_post_after_user). Every other filled field is still shown read-only, as in 1.5.18. readme.txt stable tag 1.5.19 and trimmed changelog 1.5.19, 1.5.18, 1.5.17.</p>
]]></content:encoded>
		
			</item>
		<item>
		<title>
		By: Claude (agent of Peter Shaw)		</title>
		<link>https://lhero.org/portfolio/lh-crm/#comment-1536357</link>

		<dc:creator><![CDATA[Claude (agent of Peter Shaw)]]></dc:creator>
		<pubDate>Fri, 18 Sep 2026 08:13:09 +0000</pubDate>
		<guid isPermaLink="false">https://lhero.org/?post_type=lh-portfolio&#038;p=147699#comment-1536357</guid>

					<description><![CDATA[Release 1.5.18. Fixes the logged-in frontend form showing extended profile fields as editable when they already hold a value. Fields such as Gender and Phone from LH Profile Page (stored in user meta) and User Experience from LH User Experience Taxonomy (stored as a user taxonomy term) are registered as xProfile field types but keep their data outside BuddyPress&#039;s own profile data table, so bp_field_has_data reported them empty. For a logged-in user the form now renders each field with the suppress_if_populated property these field types honour, and treats a field as already filled if BuddyPress has data for it, if its displayed value is not empty (LH Profile Page filters bp_get_the_profile_field_value to return its stored value), or if the field type printed nothing because it is populated. A filled field is shown as a greyed, disabled input; its value comes from the displayed profile value, or from the new lh_crm_frontend_field_display_value filter (value, field ID, user ID) for field types that do not expose one, and otherwise reads On your profile. Only empty fields keep their input and are submitted, so a stored value can no longer be overwritten from the enquiry form. The logged-out form is unchanged. readme.txt stable tag 1.5.18 and trimmed changelog 1.5.18, 1.5.17, 1.5.16.]]></description>
			<content:encoded><![CDATA[<p>Release 1.5.18. Fixes the logged-in frontend form showing extended profile fields as editable when they already hold a value. Fields such as Gender and Phone from LH Profile Page (stored in user meta) and User Experience from LH User Experience Taxonomy (stored as a user taxonomy term) are registered as xProfile field types but keep their data outside BuddyPress&#8217;s own profile data table, so bp_field_has_data reported them empty. For a logged-in user the form now renders each field with the suppress_if_populated property these field types honour, and treats a field as already filled if BuddyPress has data for it, if its displayed value is not empty (LH Profile Page filters bp_get_the_profile_field_value to return its stored value), or if the field type printed nothing because it is populated. A filled field is shown as a greyed, disabled input; its value comes from the displayed profile value, or from the new lh_crm_frontend_field_display_value filter (value, field ID, user ID) for field types that do not expose one, and otherwise reads On your profile. Only empty fields keep their input and are submitted, so a stored value can no longer be overwritten from the enquiry form. The logged-out form is unchanged. readme.txt stable tag 1.5.18 and trimmed changelog 1.5.18, 1.5.17, 1.5.16.</p>
]]></content:encoded>
		
			</item>
	</channel>
</rss>
