• Joanna Knott 44
  • NEWBIE
  • 0 Points
  • Member since 2019

  • Chatter
    Feed
  • 0
    Best Answers
  • 0
    Likes Received
  • 1
    Likes Given
  • 0
    Questions
  • 5
    Replies

Challenge number 4 is described as:
As described in the requirements, customize Accounts so sales reps see a highlight of the details they care about most, while Paloma sees a highlight of the details she cares about.

important account details for sales reps are:
• The account’s name
• How many employees work at the account
• What phone number to use for calling the account
• Rating of how easy it is to do business with this account

Paloma’s priorities when working with accounts are:
• The account’s name
• The type of account
• What phone number to use for calling the account
• Parent account name, if any

Customize Accounts so sales reps see a highlight of the details they care about most, while Paloma sees a highlight of the details she cares about.

Attempted solution: I would achieve this by modifying the compact layout which in turn updates the highlight panel component on account record detail pages

User-added image

Attempted solution 2: The two profiles that are created by setting up the org for this challenge are Custom: Sales Profile (for sales reps) and the user Paloma uses just Standard Platform User. I tried modifying their respective page layouts to isolate the fields they required into a new section as well as dragging them into the highlights section of page layout but it still yields an error.

Error on both solution attempts:
User-added image
Hello,

I'm trying to complete the Simulate a Cross-Site Scripting Attack but I get the error:

Challenge Not yet complete... here's what's wrong: 
It doesn't appear that you've successfully simulated a cross-site scripting attack using the Visualforce page. Please try again.

My input is: <a onmouseover = "alert(\'This is an xss attack.\')">xss attack</a>
The org is connected to Trailhead, however, it seems that the Trailhead Tracker isn't installed. Isn't this package usually required to track access the orgs used in Trailhead?
Has anyone completed this trail? I am stomped on challenge number 3, regarding created the process for fulfillment. Any pointers or guidance would be appreciated.
 

Not really a question, but  solution I thought might be helpful to others:

 

Due to the nature of most backoffice (and frontoffice, for that matter) systems, the standard Address object in salesforce does not work well with integrations, especially if you are using Salesforce.com as the system of record for some addresses.  Most of these systems use a dedicated field for each address line.   We need our street address field to fit into our accounting system limitations, which are:

1. Maxium of 30 characters per line

2. No more than two lines

 

Anyway, the answer for me was some fairly basic Regex for the BillingStreet Field:

NOT(
OR(
REGEX(
BillingStreet,
".{0,30}"
),
REGEX(
BillingStreet,
".{0,30}\r\n.{0,30}"
)
)
)

My regex logic:

Must be:
Empty or Single line less than 31 characters:
.{0,30}
Two lines with less than 31 characters each line:
.{0,30}\r\n.{0,30}

You can also do this with negative enforcement, but the positive model is much cleaner (example shown with 60 character limit instead of 30):

NOT:
2 or more CRLFs
(.*\r\n){2,}.*
More than 60 characters on single line
.{61,}
More than 60 characters on first line of two
.{61,}\r\n.*
More than 60 characters on second line of two
.*\r\n.{61,}

I learned the following about SF regex while doing this:

1. It does not appear to operate in multi-line mode (IE the $ zero-width match does not match the end of each line, just the end of the field)

2. The dot (.) does not match EOL characters (\r and \n)

3. Your regex has to match the entire field - all lines to be true.   In other workds, .* will not match a multi-line field.

4. To match the entire field regardless of the number of lines you would use (.*\r\n){*}

5. SF Address field uses \r\n as their EOL for the purposes of regex (I think this is different than the export, which is supposed to use just \n).

 

Enjoy,

 

Brandy Peterson

Not really a question, but  solution I thought might be helpful to others:

 

Due to the nature of most backoffice (and frontoffice, for that matter) systems, the standard Address object in salesforce does not work well with integrations, especially if you are using Salesforce.com as the system of record for some addresses.  Most of these systems use a dedicated field for each address line.   We need our street address field to fit into our accounting system limitations, which are:

1. Maxium of 30 characters per line

2. No more than two lines

 

Anyway, the answer for me was some fairly basic Regex for the BillingStreet Field:

NOT(
OR(
REGEX(
BillingStreet,
".{0,30}"
),
REGEX(
BillingStreet,
".{0,30}\r\n.{0,30}"
)
)
)

My regex logic:

Must be:
Empty or Single line less than 31 characters:
.{0,30}
Two lines with less than 31 characters each line:
.{0,30}\r\n.{0,30}

You can also do this with negative enforcement, but the positive model is much cleaner (example shown with 60 character limit instead of 30):

NOT:
2 or more CRLFs
(.*\r\n){2,}.*
More than 60 characters on single line
.{61,}
More than 60 characters on first line of two
.{61,}\r\n.*
More than 60 characters on second line of two
.*\r\n.{61,}

I learned the following about SF regex while doing this:

1. It does not appear to operate in multi-line mode (IE the $ zero-width match does not match the end of each line, just the end of the field)

2. The dot (.) does not match EOL characters (\r and \n)

3. Your regex has to match the entire field - all lines to be true.   In other workds, .* will not match a multi-line field.

4. To match the entire field regardless of the number of lines you would use (.*\r\n){*}

5. SF Address field uses \r\n as their EOL for the purposes of regex (I think this is different than the export, which is supposed to use just \n).

 

Enjoy,

 

Brandy Peterson