by ·0 Comments

Login History without Manage Users permissions

Recently someone asked me how to expose the login history without giving the individual users the manage users permission. The goal was to allow the internal support team to view the login history of portal users. Off the top of my head, I thought this would be the perfect use case for illustrating the power of the ‘without sharing’ Apex keywords. So after a few minutes we had built an Apex controller and Visualforce page we thought would work. Initial testing, as System Administrator users was promising. Loading the Visualforce page showed us the last 25 login history records for the User we specified. Unfortunately, loading that same page as a support user yielded 25 blank lines!

All was not lost, however, as we refactored the controller more in line with best practices. Moving our login history data to a wrapper class allowed the data to be visible to users who had permission to access the controller and page! Here’s the final product:

2015-09-30 at 10.06 PM

 

 

And here’s the code:

public without sharing class UserLoginHistory{
public class loginHistoryWrapper {
public DateTime LoginTime {get;set;}
public String Status {get;set;}
public String LoginURL {get;set;}
public String LoginType {get;set;}
public String Application {get;set;}
public String Browser {get;set;}
public ID UserId {get;set;}
public loginHistoryWrapper(DateTime lt, String statuss, String LR, String ltype, String app, String brow, ID uid){
LoginTime = lt;
Status = statuss;
LoginURL = LR;
LoginType = ltype;
Application = app;
Browser = brow;
UserId = uid;
}
}
private Map<String, String> UrlParameterMap;
private User pU {get; set;}
public User u {
get{
if(pU == null){
pU = [SELECT name FROM User WHERE ID = :UrlParameterMap.get('userId')];
}
return pU;
}
}
public List<LoginHistoryWrapper> Records {get; set;}
public UserLoginHistory(){
UrlParameterMap = ApexPages.currentPage().getParameters();
List<LoginHistory> lRecords = [
SELECT LoginTime, Status, LoginURL, LoginType, Application, Browser, UserId
FROM LoginHistory
WHERE UserId= :UrlParameterMap.get('userId')
ORDER BY LoginTime DESC LIMIT 25];
Records = new List<LoginHistoryWrapper>();
For(LoginHistory lh : lRecords){
Records.add(new LoginHistoryWrapper(lh.loginTime, lh.status, lh.loginURL, lh.LoginType, lh.Application, lh.Browser, lh.UserId));
}
}
}

view raw
LoginHistoryCtrl.cls
hosted with ❤ by GitHub

The secret sauce here is our wrapper object. Converting the loginHistory objects to our wrapper object allows the data to be seen by users without the Manage Users Permission.

<apex:page controller="UserLoginHistory">
<apex:pageBlock title="Login History for {!u.Name}">
<apex:pageBlockTable value="{!Records}" var="Record">
<apex:column >
<apex:facet name="header">User's Name</apex:facet>
<apex:outputText value=" {!u.name}"/>
</apex:column>
<apex:column >
<apex:facet name="header">Login Time</apex:facet>
<apex:outputText value=" {!Record.LoginTime}"/>
</apex:column>
<apex:column >
<apex:facet name="header">Status</apex:facet>
<apex:outputText value="{!Record.Status}"/>
</apex:column>
<apex:column >
<apex:facet name="header">Login Type</apex:facet>
<apex:outputText value="{!Record.LoginType}"/>
</apex:column>
<apex:column >
<apex:facet name="header">Client Type</apex:facet>
<apex:outputText value="{!Record.Application}"/>
</apex:column>
<apex:column >
<apex:facet name="header">Browser</apex:facet>
<apex:outputText value="{!Record.Browser}"/>
</apex:column>
<apex:column >
<apex:facet name="header">Login URL</apex:facet>
<apex:outputText value="{!Record.LoginURL}"/>
</apex:column>
</apex:pageBlockTable>
</apex:pageBlock>
</apex:page>

view raw
LoginHistoryPage.vfp
hosted with ❤ by GitHub

Viola! a safe way to expose login history with internal users without giving them ManageUsers permission!

by ·Comments Off on The Good, The Bad and the Ugly of Summer ’14 for Developers.

It’s that time of year again. All the good developers and all the good admins eagerly awaiting the end of planned maintenance and the new gifts, er, features, that Salesforce is providing. At 340 pages, the Release notes are a great balance of detail-without-being-boring and I highly encourage everyone to read through them. If, however, you don’t happen to have an adorable screaming infant providing you with extra reading time between 2-4am have no fear; I written up a few highlights. I don’t want to let all the cats out of the bag, but suffice it to say, there’s The Good, The Bad and The Ugly. Without further ado:

The good.

  1. Our leader here, is innoculously described as “Speed Up Queries with the Query Plan Tool” (see Page 241-ff.) In essence, this is the Salesforce equivelent of MySql’s EXPLAIN, PostgreSQL’s EXPLAIN ANALYZE or Oracle’s EXPLAIN PLAN functionality. If you’ve never had the pleasure of arguing with a relational database query written by the intern… well, you may not know about explain. In general these tools all work the same way – prepend any given query with the keyword(s) EXPLAIN and the database will return information about how it will gather the information your looking for instead of the actual query results. Here’s why you need this: You and I both put our pants on one leg at a time, but I’ve writen queries against objects with more than 30 Million records, and I say all our SOQL queries should be reviewed with this explain tool. With this tool we can see which, if any indexes the query optimizer is able to utilize. Here’s how SOQL’s explain works:

[code lang=text]
{
"plans" : [ {
"cardinality" : 2843473,
"fields" : [ ],
"leadingOperationType" : "TableScan",
"relativeCost" : 1.7425881237364873,
"sobjectCardinality" : 25849751,
"sobjectType" : "Awesome_Sauce__c"
} ]
}
[/code]

As they say in the hood, “that there query sucks”. See that “LeadingOperationType” key in the JSON results? TableScan means it has to scan every record. ow. I should really refactor that query so that explain identifies fields it can index off of. With Sumemr’14 there’s a spiffy dev console button to access this information. Wicked.

Other good highlights include:

  1. The ability to override remote object methods
  2. Pricebook Entries in tests. Without “SeeAllData=true”, aka “DISASTERHERE=true”
  3. Un-restricted describes. If you build dyamic UI’s this is indespensible!

The Bad.

  1. There’s an aside on page 191 that bodes ill for many of us. If you’ve ever put Javascript in a home page component, start heeding their warning now. After Summer ’15 no more JS in homepage components. Convert to the new Visualforce component, or suffer the wrath of progress.

The Ugly.

Ok, I can’t really blame Salesforce for this, but the simple fact of the matter is that not all Salesforce devs are created equal. As a Salesforce consultant and developer I have inherited a number of orgs plagued with test classes that execute code, but make no assertions.

As a developer, I understand the importants of testing code, and believe that we should always write useful tests. Additionally, I know Salesforce runs the unit tests in our orgs before every release. Without assertions, however, these test runs tell us only that the code runs, not that it’s functioning properly. While there are rarely, if ever, technological solutions to social problems — like the lack of rigor and professionalism with regard to testing amongst Salesforce developer– I believe it is in the best interest of not only Salesforce Developers but also Salesforce itself, to build a feature allowing administrators to engage an org-wide flag requiring all test methods to call assert methods, with sane protections against such clear abuses as System.Asert(true);

This can only result in better testing, and therefore better code in production, as well as better feedback to Salesforce about the viablity of new API versions.

You should vote for this idea here:

https://success.salesforce.com/ideaView?id=08730000000l6zHAAQ