Uploaded image for project: 'PUBLIC - Liferay Portal Community Edition'
  1. PUBLIC - Liferay Portal Community Edition
  2. LPS-42543

Changes in behavior because of refactoring in GroupLocalServiceImpl



      JournalContentSearchLocalServiceImpl has a function for synchronizing JournalContentSearch table on startup (checkJournalContentSearches(long companyId)). This is called if "journal.sync.content.search.on.startup=true" is set in portal-ext.

      This function is supposed to iterate through all groups in a company and regenerate JCS records for them.

      The method uses GroupLocalService to get the groups of a company:

      List<Group> groups = groupLocalService.search(
      	companyId, null, null, null, QueryUtil.ALL_POS, QueryUtil.ALL_POS);

      This originally mapped to call:

      public List<Group> search(
      		long companyId, String name, String description,
      		LinkedHashMap<String, Object> params, int start, int end)
      	throws SystemException {

      But in 6.2.x after LPS-27163 it is mapped to:

      public List<Group> search(
      		long companyId, long[] classNameIds, String keywords,
      		LinkedHashMap<String, Object> params, int start, int end)
      	throws SystemException {

      Since in the fist commit of LPS-27163 the first method got a new parameter and the second method lost one so the meaning of "search(long, null, null, null, int, int)" has changed. I think it's obvious how dangerous this is.

      This means a considerable change in behavior which a think was overlooked in LPS-27163.
      The first method returns all group record of the company with Group classNameId on 6.0.x but it later 6.1.x it's changed to return ones with Organization classNameId too.

      The new one returns all group records of the company.

      This means:

      • in 6.0.x the synchronization is done only for communities
      • in 6.1.x the synchronization is done only for sites and organization sites (for example it isn't done for user's peronal sites)
      • in 6.2.x the synchronization is done for everything

      It's a great progress.

      For sake of consistency and simplicity we should call getCompanyGroups(long companyId, int start, int end) to get the groups because that returns all group records in every version and it would make it easy to get a consistent (and good) behavior on all versions.


          Issue Links



              support-lep@liferay.com SE Support
              norbert.kocsis Norbert Kocsis (Inactive)
              Participants of an Issue:
              Recent user:
              Esther Sanz
              0 Vote for this issue
              3 Start watching this issue


                Days since last comment:
                7 years, 2 weeks ago


                  Version Package