• IT Administrator 54
  • 0 Points
  • Member since 2018

  • Chatter
  • 0
    Best Answers
  • 0
    Likes Received
  • 0
    Likes Given
  • 0
  • 2

I have a lightning component, with a design file that includes a two picklists. These picklists are currently being populated by referencing a class that extends "VisualEditor.DynamicPickList", using the datasource attribute on the design:attribute control. Like this : datasource="apex://ClassName.

This works fine, but i am getting all the fields specifically from the Account object right now, like this:
"Map<String, Schema.SObjectField> fldObjMap = schema.SObjectType.Account.fields.getMap();" and using that to populate the picklist.

What i would like to do, is to populate the picklist with all fields, based on what object the user is inserting the lightning component on. If the user inserts the lightning component on a Contact, it should list all Contact fields. If it is inserted on a Campaign object, it should list all the Campaign fields etc.

I am kinda stuck at how to to this.

I am supposed to be able to get the recordId, from the URL i guess. When i go into "Edit page" (where this should be used), i have a querystring in the URL called "pageId". And i should be able to get that through apex code. Something like this "ApexPages.CurrentPage().getparameters().get('id');".

But i can't get this to work. And i guess this has something to do with, that i am trying to do this in the "VisualEditor.DynamicPickList" extending class. But if someone could point me in the right direction, it would be awesome.

I just want to get the current object type in this extending class, that populates the picklists with field values. Simple as that. 

Error when authenticating to community site using SAML/Azure AD:  The reply address 'https://company2.force.com/login?so=00D41000001i0oF' does not match the reply addresses configured for the application: 'https://company1.my.salesforce.com'.

We have recently implemented Azure AD single sign on for Salesforce in both our production and test environments.  This seems to work great.  However, there does not seem to be a way to add additional reply URL's so that we can authenticate to our "Salesforce Communities".  Our Salesforce URL for our main site is "https://companyname.my.salesforce.com/".  Our "Community" domain sign in URL is "https://companyname2.force.com/login".  

In the Azure, we've added the salesforce "application from the gallery".  When we go to configure the application, we see a section for adding a reply URL but are forced to use a convention that meets the "https://example.my.salesforce.com" standard.  
Has anyone else implemented salesforce SSO with more than one domain?  How do you add additional URLs?
We've looked at the following guides but some seem to be outdated or don't include instructions to add additional reply URLs for SAML to include additional URLs for Salesforce Community domains.
Guide from Microsoft Documentation for SAML, Azure AD, and Salesforce (note: no information about adding additional "Reply URLs for "Communities"):
Guide on Salesforce developer site using Open ID Connect and Azure AD (note: this includes information about implementing communities but hasn't been updated since Oct 2015 and seems to be missing steps or has out of date information.  Also, no user provisioning steps):
TechNet article for integrating SAML/Azure AD with Salesforce Sandbox (note: nothing about adding additonal reply URLs for communities.):

Also, we've tried to use OAuth and OpenID Connect with Azure using this guide:


The OAuth and OpenID connect does not work following those instructions and I believe it has something to do with the Reg handler or possibly Azure AD endpoints changing.  Specifically, the Authorize, Token, and Profile Endpoint URLs don't seem to be the same anymore as seen when you click the "endpoints" in Azure AD for the application.  There isn't even a "profile endpoint" available but instead a "graph API endpoint".. So, instead of using https://login.windows.net/common/openid/userinfo, I'm guessing more code has to be written on Salesforce's end to work with https://graph.windows.net.


Any insight into these things would be greatly appreciated.