Just want to jump in at this point to highlight something from my past with this. I went down this path once (in 6.2 EE) with a customer of mine and even went as far as to open a ticket because I thought I had found a bug. I set the LiberalScreenNameValidator as well and found the same thing... there aren't supposed to be any restrictions but I couldn't get past with certain characters. I don't recall the exact line number, but if yo ulook inside the UserLocalServiceImpl, you'll find a point where a validate screenname or some such thing is called. That validation is performed regardless of the screen name validator logic and actually enforces the same rules as the default validator (if memory serves).
The LESA was closed as "not a bug" and the reason I was given was that it has to do with characters that are also valid for urls. It was pointed out that you could have user/{screenname} as the url pattern for a users private site -- so things like an @ sign wouldn't fly. I tried to argue that if you had user sites disabled then it shouldn't matter but at that stage both I and LESA had taken our stance
. In the end, we were forced to find another solution.
I doubt this helps -- but you would probably have to override several core services to do what you are trying to do.
The LESA was closed as "not a bug" and the reason I was given was that it has to do with characters that are also valid for urls. It was pointed out that you could have user/{screenname} as the url pattern for a users private site -- so things like an @ sign wouldn't fly. I tried to argue that if you had user sites disabled then it shouldn't matter but at that stage both I and LESA had taken our stance
. In the end, we were forced to find another solution.I doubt this helps -- but you would probably have to override several core services to do what you are trying to do.
Ah, yeah, so with Liferay 7 CE/Liferay DXP, many of the old portal-ext.properties values don't work anymore. Many have been moved to OSGi properties or simply don't apply anymore since OSGi service trackers can pick the right implementation to use.
In fact, if you check the portal source for that property, you see:
The important part there is the note about overriding in portal properties in a hook. So basically they're saying the property only works if you're trying to deploy a legacy hook war into Liferay, otherwise the property does not apply.
It may be supported in the system settings control panel, but a quick search didn't seem to find one that jumped out, although I did not spend more than 20 seconds looking
Come meet me at the 2017 LSNA!
In fact, if you check the portal source for that property, you see:
# Input a class name that implements
# com.liferay.portal.security.auth.ScreenNameValidator. This class will be
# called to validate user screen names.
#
# This property is not read by the portal except for portal properties
# overridden by liferay-hook.xml. It remains here only as a reference.
#
#users.screen.name.validator=com.liferay.portal.security.auth.DefaultScreenNameValidator
#users.screen.name.validator=com.liferay.portal.security.auth.LiberalScreenNameValidator
The important part there is the note about overriding in portal properties in a hook. So basically they're saying the property only works if you're trying to deploy a legacy hook war into Liferay, otherwise the property does not apply.
It may be supported in the system settings control panel, but a quick search didn't seem to find one that jumped out, although I did not spend more than 20 seconds looking
Come meet me at the 2017 LSNA!
David Weitzel:
All we want to do in DXP is do what we could do in the 6.2 EXT as we upgrade to DXP before delivering some advanced functionality
In DXP, the EXT plugin support has been restored (or at least that's my understanding
) so you should be able to provide a modified version of the UserLocalServiceImpl class.Come meet me at the 2017 LSNA!
