A Closer look at Entity Forms and Entity Lists created by the Create Portal Content Wizard

In my post about the Create Portal Content Wizard, I talked about how easy it is to add content to the portal using point-and-click configuration, and demonstrated that the Wizard creates a whole lot of records in the background for you so that you don’t have to. It’s like magic! It certainly does beat having to spend the time configuring Entity Forms, Lists, Permissions, and web pages all from scratch. It also has its limitations. There are several scenarios that simply aren’t represented by the Wizard, including some fairly basic ones. But there’s also a fair bit of manual work/cleanup you’ll need to do depending on what exactly you are going for.

In order to better understand the Wizard, I figure now’s the time to spell out exactly what records actually get created by the wizard. To do this, we’ll go through the different options for configuring a list (we care mostly about displaying organization entities so that’s the focus of this article) and see exactly what configurations are created with the different options and focus on what changes with the different settings. If you aren’t familiar with the Wizard, I explain the steps for using it here. Read that first, then come back – this article is more of a deep dive.

Let’s start with the basic case where we are not adding the ability to create or edit, and we do not require portal visitors to sign in to see the list. Note the field selections below. The website, Page name, Title, Layout, Partial URL, Parent Page and publishing status are whatever you want them to be – these don’t affect the outcome (well they do but not in a way that we are interested in – we can about the forms and lists and these don’t affect those). We’ll set to display entity on the portal select our custom Foo Entity. In the past we’ve used Leads and Contacts but let’s stick with the most basic case which is actually a custom entity. Choose whichever form and views you wish. The only fields that we are going to change across our different scenarios are those beginning with “allow record creation”. Notably, we are allowing anonymous access and not allowing record creation for this first case.

This creates a Foo List on the Portal.

So what records exactly have been created by this process?

  1. An Entity List, named “<name of your page> Entity List” and with the following attributes / settings:
    1. Entity Set to the one you chose in the wizard
    2. View(s) again equal to what was selected
    3. No Grid Configuration, surprisingly. Edit and whatnot are not configured the ‘most correct’ way
    4. Page size set to 10
    5. “Web Page for Details View” set to a web page created by the Wizard that we will cover later. It has the ReadOnly Entity Form. This means that clicking on any of the row in the list will open a new page with the read-only details, rather than a modal popup.
    6. Entity Permissions are NOT enabled! This is despite the fact that best practice is to always enable them, even if you aren’t using any features that require them (which this doesn’t). And despite the fact that they are enabled for the ReadOnly view and are hence created by the Wizard anyway!
  2. An Entity Form, used for viewing read-only details, named “<name of your page> Details” and with the following attributes / settings:
    1. Entity Set to the one you chose in the wizard
    2. Form once again equal to the one you set in the wizard
    3. Mode set to ReadOnly
    4. Source Type Set to Query String (it’s always set to this when used in conjunction with an Entity List – we’ll talk about this more in a future post)
    5. Entity Permissions Enabled – Despite the fact that since we are allowing anonymous access and are using no features that require entity permissions to work, permissions are still enabled, which is the best practice. This means that Entity Permissions clearly also need to have been created
  3. Two Web Pages. The first has the name that you set in the wizard, and has a lookup to the Entity list that was created.
    1. Website, Parent Page, Partial URL, Page Template, Publishing Status area all set as specified in the Wizard, while all other values are set to default
    2. No access control rules are created
  4. The Second Web Page has the name “<name of your page> Details” and has a lookup to the Entity Form for the Details view (ReadOnly)
    1. Parent Page is set to the first Web Page (that has the list)
    2. Partial URL is “<URL of parent>-details”
    3. Page Template is as per parent (you’ll often want to change this!)
    4. Publishing State as per parent
    5. It’s Hidden from Sitemap and excluded from search
    6. No Access Control Rules
  5. Finally, an Entity Permissions Record named “<name of your page>_EntityPermission_<entity logical name>” (an oddly formatted name…) and with the following attributes / settings:
    1. Entity Set to the one you chose in the wizard
    2. Website, same deal
    3. Scope: Global
    4. Privileges: Read
    5. Assigned to the Anonymous Users role

Why wouldn’t Entity Permissions be enabled for the List if they are enabled for the form? Why use the Web Page for Details View and not Grid Configuration? Weird choices, but in any event in future blog posts I’ll talk more about how to play with Entity Lists and Forms, and what the settings really change.

Ok, how about the case where we do allow both record creation and anonymous access? You’ll want to either choose a new entity to use for each scenario or else delete the records (in particular the entity permissions) created by previous scenarios if you are following along and trying this for yourself. I’m doing the later.

Ok, so now we have a list which is otherwise identical to the first one except you can also create. Again, you cannot edit existing records on the portal – only create new ones. To even enable editing you’d need to make a bunch of additions.

For now let’s just see what changing this one option did.

  1. An Entity List, exactly as before, but with a couple of important differences:
    1. There is now Grid Configuration for the Create Button. This grid configuration adds a create button which will allow a new record to be created via a redirect to a web page that has also been created for create which we will discuss in a moment.
    2. Entity Permissions still not enabled, oddly. If the Create Button used a modal popup rather than a redirect to web page, the configuration would be broken. Very choice choice by the development team here.
  2. Two Entity Forms, the first as before used for viewing read-only details, configured the same as with the first scenario, and a second Entity Form for create named “<name of your page> Create” and with the following attributes / settings:
    1. Entity Set to the one you chose in the wizard
    2. Form once again equal to the one you set in the wizard, meaning that if you wanted a separate form to be used for edit and create you would need to come in and make these changes manually
    3. Mode set to Insert
    4. Entity Permissions Enabled
    5. Redirect to the Entity List upon submit
    6. Note that the Entity Form is NOT configured to associate the current Portal User Contact on Insert. This means that when a portal user submits the record, there will be no record of who did the submitting. This makes a certain amount of sense since anonymous users don’t have a contact record. Most scenarios will call for this if possible, so you’ll need to add this manually.
  3. Three Web Pages. The first has the name that you set in the wizard, and has a lookup to the Entity list that was created. The Second Web Page has the name “<name of your page> Details” and has a lookup to the Entity Form for the Details view (ReadOnly) just as before.  The new Page is named “<name of your page> Create” and has the basically the same settings as the Details page but has a lookup to the Create form.
  4. Finally, an Entity Permissions Record named “<name of your page>_EntityPermission_<entity logical name>” (an oddly formatted name…) and with the following attributes / settings:
    1. Entity Set to the one you chose in the wizard
    2. Website, same deal
    3. Scope: Global
    4. Privileges: Read and Create
    5. Assigned to the Anonymous Users role

I think the most important things to note so far is the use of Entity permissions, which are turned off on the lists, meaning that you’ll need to turn them on in order to add most grid configurations; yet on in the case of the forms. Entity Permissions are set up for you as well. One thing I’d like to point out is that if you are creating lists for OOTB entities like Contacts, most portals have certain permissions set up for these entities already and the new ones created by the wizard will frequently overlap with these which leads to unpredictable results.

Ok, let’s try turning off “allow anonymous access”.  This will have the effect of turning on entity permissions for the list, which will open up a range of other options which will appear in the Wizard. We’ll leave those options alone (set to “no”) for now.

Now we need to be logged in in order to use the list – that’s much is for sure. Indeed if you navigate to the Web Page on the Portal you’ll get a permissions error:

Oddly, this error is on the list – you can’t view the records. Yet the page itself isn’t locked down. It’s a bit amateurish, but there you have it. I’d recommend locking the page down if it’s not valid for anonymous users to access the list. Ok, well, let’s login – we just specified that anonymous users cannot access the list. Therefore if you are logged in, you will be able to see it right?

…hmmm. Well, that didn’t work.  What’s going on here? Clearly there is more configuration that needs to be done. In other words, the configuration that comes out of using the wizard is broken by default in this case. In other to understand why, let’s talk about the records that were created.

  1. An Entity List, exactly as before, with just one important difference: Entity Permissions are now enabled. This is very odd, since again there’s no reason they weren’t enabled in the earlier scenarios. You can allow anonymous access to a secured list: just grant permissions to anonymous users. In fact this was done anyway – Entity permissions ended up being created for you exactly as you’d need them. So it’s odd that the developer(s) of this wizard made the decision as to map this “allow anonymous access” setting to the turning entity permissions on and off on the list. All other options are the same as in the first scenario.
  2. A ReadOnly Entity form just as in the prior scenarios with no differences.
  3. Two Web Pages just as in the first scenario. No differences here.
  4. And Entity Permissions. This is where the difference – and problems – arise. One Entity permission record has been created:
    1. Entity and Website Set to the one you chose in the wizard
    2. Privileges: Read, since we didn’t enable Create in the wizard
    3. And here’s the weird one. The Scope has been set to Contact. This means that contacts logged in must have a record-level relationship to the records you are exposing on the list or they won’t appear. This isn’t at all implied by the settings on the Wizard – we didn’t choose “Restrict records owned by the User” – therefore the implication is that if you are logged in you should be able to see all records. Therefore the scope should be Global. This isn’t why you are seeing the error message, but even if we got past that, you still wouldn’t see any records since…
    4. Contact Relationship: Not set, despite being a required field. So yeah, it’s broken. Pretty disappointing. You can fix it, but it’s odd that they are setting the scope to contact at all since record-level security isn’t implied by the settings we set on the wizard. We explicitly chose NOT to “Restrict records owned by the user”!!! So this is a defect with the Wizard. Now in terms of it being blank despite being a required field – turns out this is actually a bug because it doesn’t let you proceed without specifying a contact scope the second time you go through the wizard:
    5. Finally, to pour more salt in the wound, the Entity permission isn’t assigned to any Web Role! This is why we are getting our error message despite being logged in. The settings we chose in the wizard clearly implied that the Entity permissions should be assigned to the “Authenticated Users” web role.

So if you choose to not allow anonymous access, but still want a read-Only list, you’ve got a lot of manual work to do. Also, despite choosing to not restrict the results by user, the configuration implies you want to do just that (yet is incomplete).  Ok, let’s see if changing some of the settings on the wizard has a different result. Remember to set the contact relationship since that’s required if anonymous access is disallowed… that is assuming the option is presented to you. You’ll find that if you allow record creation but leave all other options the same…

…you’ll find that the only difference is that grid configuration is used to add a create button (via redirecting to a new web page with a create entity form) and that the Entity Permission that is created (but still not assigned to any web role) now has create permissions added. Ok, let’s try enabling record editing:

Now the list records can be edited.  YOu can only see any records if you are logged in, in a web role that has the entity permission that’s been created (this doesn’t work by default in this scenario as before) AND your contact record that your are signed in with is related to the records on the grid. Assuming we can see the list, the individual rows will be editable. There are some oddities however. We’ll get to those.

Let’s look at the records creating in this scenario:

  1. The Entity list is create with most of the same options as in the base case. Entity permissions are enabled. Note however:
    1. The Web Page for Details view is still set as before. Note that it is certainly an option to made the details page not-read-only, and rather an edit page. But this option isn’t set by the wizard. The Details page is still Read-Only.
    2. There is now Grid Configuration for the Edit Button. The edit button is separate from the details view. The details view is, in theory, what you get if you click the name of the record in the link (a hyperlink) while the edit button on each row is a record action.  You could configure a read-only action as well. But again, that option isn’t being used. The edit button is set to redirect to webpage – no modals are being used in any of these configurations.
    3. Entity Permissions are enabled.
  2. Two Entity Forms, the first as before used for viewing read-only details, and a second Entity Form for editing named “<name of your page> Edit” and with the following attributes / settings:
    1. Entity Set to the one you chose in the wizard
    2. Form once again equal to the one you set in the wizard, meaning that if you wanted a separate form to be used for edit and create you would need to come in and make these changes manually
    3. Mode set to Edit
    4. Source Type Set to Query String
    5. Entity Permissions Enabled
    6. Redirect to the Entity List upon submit
    7. Note that the Entity Form is still not configured to associate the current Portal User Contact on Insert. So you won’t have access to the very records you create as a portal user. A bit of an oversight to say the least.
    8. Three Web Pages. The first has the name that you set in the wizard, and has a lookup to the Entity list that was created. The Second Web Page has the name “<name of your page> Details” and has a lookup to the Entity Form for the Details view (ReadOnly) just as before.  The new Page is named “<name of your page> Edit” and has the basically the same settings as the Details page but has a lookup to the Edit form.
  3. Lastly we get to the Entity Permissions Record. It’s exactly the same (still the same issues) but with the additional of Edit permission. So you can edit records, but only if they are related to your contact record.

Note that enabling both create and Edit in the Wizard just adds the create button back in just as before – layer on top what happened there to what just happened above. Let’s try one last thing. Recall that as soon as you turn off anonymous access, it changes the scope of the created permissions to “Contact” (for no real reason). This is despite not selecting “Restrict records owned by the user”. Well what if we actually want to restrict the records shown by the logged in user’s contact record? Since we are already doing that, what in the dickens does actually setting the value in the Wizard to “yes” do for us?

The answer, surprisingly… is nothing. Nothing at all. Again, a bug with the tool.

Ahem. Bottom line here is you can’t use the Wizard to create a secured list and expect it to work out of the gate – you will need to do some cleanup first!

I hope this article was useful for you in terms of demystifying the Create Portal Content Wizard.  It’s a super useful and convenient tool but it does have limitations and 90% of the time you are still going to need to tweak the records created to get the behaviour that you really want. Nonetheless, it’s a huge time saver because needing to create all those records manually is much more work, trust me.

Stay tuned! More great articles on the way. Next in this series I’ll be talking about modifications you can make to Entity Forms and Web forms with point-and-click configuration. I’ve also got a new series i’m going to start up about the business value of the OOTB Portals such as Community and Partner Portal and ways to enhance those Portals. Please follow me on twitter and linkedIn and as always subscribe to my blog.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s