10

We have a customized Force.com Site + Customer Portal for the authenticated portion of the Force.com Site. We have self registration enabled. Currently the nickname and alias fields are required on the User. They really don't make any sense for our application and, I'd imagine, not for everyone else's applications, since community nickname and alias aren't industry standard fields required on any other website I've registered for.

Since the alias is not required to be unique, I can simply hack off the first 8 characters or less of the last name and use that which enables me to be able to not present the user with an unnecessary alias field.

However, the community nickname is required to be unique, so it is a bit more tricky. Right now, I just let the user enter something for it, but it doesn't really make any sense, so I'd like to remove it.

  1. Is there a way to make the community nickname field not required and/or not required to be unique for customer portal users?

  2. If not, what is a good strategy for automatically generating them without having the user ever having to know about them?

For #2, I've thought of two possible solutions:

  1. Have a custom setting that contains a number, say nicknameCounter, and use that as the nickname, incrementing it each time that it is used. The problem that I see with this is that it would be possible for a user to get the same number as another user if they both get their numbers before they increment. I could mitigate that by say, prefixing the increment to the first 10 characters of the last name + first 10 characters of the email, etc.

  2. I've also thought about adding an autonumber field to the User called nicknameCounter and use that to populate the nickname, but I'm not sure how that will work timing wise.

Surely, other people have this issue. I'd appreciate learning how others handle it.

Thanks!

6 Answers 6

4

What other information are your users entering?

Could you do combinations? FirstNameLastName_Zipcode or something like that?

Or include the email domain?

10
  • That's what I was thinking with my #1 solution. In theory, the combination of those fields isn't necessarily unique. Maybe I could use the username + an increment? I think with just using the username I will still hit the uniqueness problem by having clashes with disabled portal users. I'm curious how others handle this. Based on this issue and other issues I've had with portal, I kind of think that nobody actually uses portal + sites like this, despite what the SF marketers lead you to believe. Commented Aug 10, 2012 at 13:33
  • 1
    How about doing this instead since you're doing this in code anyways. String NickName = LastNameFirstName Query all users where CommunityNickname Starts With NickName If Query results > 0 then NickName = NickName + QuerySize+ 1 Commented Aug 10, 2012 at 14:07
  • That's probably the best I'll be able to do. I think that it still isn't totally bulletproof, though. Consider this: User 1 and User 2 match. User 1 queries. User 2 queries. They both have the same QuerySize at this point. User 1 inserts. OK. User 2 inserts and fails. Commented Aug 10, 2012 at 14:28
  • This is only at the time of insert - correct? What about adding a global variable. At the start of the trigger it checks to see if the global Variable is True (True meaning another trigger has called on the variable) If true you have a second global variable be a count. Then you can use Global Variable +1 to get your uniqueness whenever multiple triggers are firing for different user inserts. Commented Aug 10, 2012 at 15:39
  • I should add that I'm completely guessing now:) Commented Aug 10, 2012 at 15:40
4

As you say the field is unique but does not apply to Portal customer. Given this we are using the SFID for the contact. We know it is unique by design and saves retrying for erros

2

I've been through this one. What I used was firstname+lastname. Then before creating the user, the controller checks the database to see if that already exists. If so, then it sticks a 2 on the end. Then check again. Keep incrementing until you're in the clear.

Unless there are hundreds of identically named people, you should not hit the query limit. :)

1
  • I ended up doing something very similar for the initial batch user creation and it worked. After asking this question, I ended up not having to implement it, but if I do I'll probably do something like this. It worked well for the batch creation. Commented Aug 21, 2012 at 0:21
2

i think you must be overthinking this. Given that the username is already unique, just copy that to the community nickname via a trigger. that is what has been configured for our customer portal + force.com site. Our users too do not need to know about the community nickname.

1

Hmm, the docs seem to say that:

All requests are delimited by the trigger, class method, Web Service, Visualforce page or anonymous block that executes the Apex code. If the entire request completes successfully, all changes are committed to the database.

So for certain definitions of delimited by...class method a single method that inserts against a utility table containing just an autonumber name that is then deleted at the end of the method before returning its name value should provide you with a valid numeric nickname with zero rows used at the cost of 3 DML operations: one insert, one query and one delete.

Alternatively you could schedule apex job at crazy o'clock that deletes all save one max(name) row, saving you one Delete DML statement.

If you wanted to get crazy about it.

1
  • That makes sense. Just add an extra dummy autonumber field on some other Object to simulate a DB sequence. Would just have to remember to handle the situation where a batch of Users was being created, which this could do if insert, query, and delete are all done on a collection of those dummy object records. It would be nice if there was some sort of first class sequence feature in Salesforce outside of this round about way of getting at it. Commented Aug 21, 2012 at 2:03
1

Just use the username provided by the user and time in milisecond. Something like this

DateTime currentTime = System.now(); Long timeInMili = currentTime.getTime()/1000; CommunityNickname = username+timeInMili;

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .