Affects Version/s: 7.2.1 CE GA2
Fix Version/s: None
Component/s: Portal Services
If I call GroupLocalService.updateGroup(long, long, Map<Locale,String>, Map<Locale,String>, int, boolean, int, String, boolean, boolean, ServiceContext) to update the Group data of the system group "Guest" and the groupName is different in the current default language, the call fails with RequiredGroupException.MustNotDeleteSystemGroup.
While looking into this bug, I also realized that updateGroup() would alter the groupKey on any Group after the default language of the Portal has been altered (if I read the code right, I did not test it).
- Start a fresh Liferay instance with Portal Setup Wizard, set default language to any language where the translation for "Guest" is not spelled "Guest" (e.g. German).
- Run the following method:
The Group gets updated successfully (even if the example code above would not actually change anything).
A RequiredGroupException.MustNotDeleteSystemGroup is thrown from GroupLocalServiceImpl.updateGroup (line 3689 in current master branch)
updateGroup() always derives the groupKey from the nameMap argument (if the latter exists), picking the current default language (l. 3654..3661).
- A "key", which I understand to be a constant identifier that could be used to find a resource without any other prior knowledge, must not depend on localization settings and should only be altered explicitely. (Having said that: If the concept of "key" is used differently in Liferay, please point me to the relevant documentation - I certainly did not find it).
- updateGroup() would alter the groupKey on any Group after the default language has been altered (if I read the code right, I did not test it).
- Following the principle of least surprise, any update operation must not alter data (except tracking data like modifiedDate etc) that is not part of the update data set (groupKey certainly is not part of the argument list of updateGroup()).
- I try to update a Group, I do not try to delete it; therefore RequiredGroupException.MustNotDeleteSystemGroup is the wrong Exception to throw here.
- At the very least, this is a documentation issue (there is no JavaDoc on updateGroup() describing this caveat).