PUBLIC - Liferay Portal Community Edition
  1. PUBLIC - Liferay Portal Community Edition
  2. LPS-13228

VerifyJournal fails when upgrading from 5.2.3 to 6.0.5 with Permission Algorithm 6 used in 5.2.3

    Details

    • Branch Version/s:
      6.0.x, 5.2.x, 5.1.x
    • Backported to Branch:
      Committed
    • Liferay Contributor's Agreement:
      Accept
    • Similar Issues:
      Show 4 results 

      Description

      The portal (version 5.2.3) had the permission algorithm 2 (it is a very very long running portal).
      We used the migration tool from the control panel. This tool switched the permission algorithm to version 6.
      This algorithm WAS available in 5.2.3 and if you used the migration tool from the control panel, permissions were converted to the algorithm 6 (not 5).

      So if you now try to upgrade to 6.0.5 with permission algorithm 6 you get result as in the attached file "UpgradeTo6.0.5WithPermAlgo6.log" (VerifyJournal throws an exception).

      If you switch to permission algorithm 5 in portal-ext.properties (and do not do anything else) the upgrade works "perfectly", but you cannot switch back to permission algorithm 6, see reults in attached file "UpgradeTo6.0.5WithPermAlgo5.log". The migration with the tool in the control panel fails with a "primary key constraint" violation.

      So where is the bug? in VerifyJournal? I think so....

      1. CheckForMissingResourceActions.java
        1.0 kB
        Tobias Kaefer
      2. UpgradeTo6.0.5WithPermAlgo5.log
        186 kB
        Tobias Kaefer
      3. UpgradeTo6.0.5WithPermAlgo6.log
        42 kB
        Tobias Kaefer

        Issue Links

          Activity

          Hide
          Tobias Kaefer added a comment -

          I am absolutely sure that we use permission algorithm 6. AND there are no entries in the tables you mentioned.

          I don't know what went wrong during the migration to algorithm 6, but the result is now, that the VerifyJournal is failing, because of missing entries in ResourceAction.

          Maybe this issue is realted to this one: http://issues.liferay.com/browse/LPS-8435

          Show
          Tobias Kaefer added a comment - I am absolutely sure that we use permission algorithm 6. AND there are no entries in the tables you mentioned. I don't know what went wrong during the migration to algorithm 6, but the result is now, that the VerifyJournal is failing, because of missing entries in ResourceAction. Maybe this issue is realted to this one: http://issues.liferay.com/browse/LPS-8435
          Hide
          Alexander Chow added a comment -

          So, I just took a vanilla 5.2.3 installation configured to algorithm 2 and upgraded it to algorithm 6. The result:

          ResourceAction - contains hundreds of entries
          ResourceCode - empty
          Permission_ - empty
          Resource_ - empty
          Roles_Permissions - empty

          Next, I upgraded it to Liferay 6 and it worked successfully.

          From what I gather, you are suggesting that somehow your 5.2.3/alg6 ResourceAction is incomplete (possibly due to LPS-8435)? All other mentioned tables are empty prior to Liferay 6 upgrade?

          Firstly, I would say that this is a very strange phenomenon. If you would not mind, in ResourceLocalServiceImpl.checkResourceActions(String name, List<String> actionIds, List<ResourceAction> resourceActions), where it creates the new ResourceAction entry, can you output the name of the model that is missing? Because, if I am reading your log files correctly, it is com.liferay.portlet.journal.model.JournalArticle. This is of course worrisome (and weird how you haven't come across this problem until now... unless you don't use the Journal portlet at all).

          Secondly, I think the solution is to add basically your code into our codebase in a VerifyPermission that gets called before VerifyJournal. I'll go ahead and commit that into trunk because I don't think it will cause any harm.

          Show
          Alexander Chow added a comment - So, I just took a vanilla 5.2.3 installation configured to algorithm 2 and upgraded it to algorithm 6. The result: ResourceAction - contains hundreds of entries ResourceCode - empty Permission_ - empty Resource_ - empty Roles_Permissions - empty Next, I upgraded it to Liferay 6 and it worked successfully. From what I gather, you are suggesting that somehow your 5.2.3/alg6 ResourceAction is incomplete (possibly due to LPS-8435 )? All other mentioned tables are empty prior to Liferay 6 upgrade? Firstly, I would say that this is a very strange phenomenon. If you would not mind, in ResourceLocalServiceImpl.checkResourceActions(String name, List<String> actionIds, List<ResourceAction> resourceActions), where it creates the new ResourceAction entry, can you output the name of the model that is missing? Because, if I am reading your log files correctly, it is com.liferay.portlet.journal.model.JournalArticle. This is of course worrisome (and weird how you haven't come across this problem until now... unless you don't use the Journal portlet at all). Secondly, I think the solution is to add basically your code into our codebase in a VerifyPermission that gets called before VerifyJournal. I'll go ahead and commit that into trunk because I don't think it will cause any harm.
          Hide
          Tobias Kaefer added a comment -

          I did some a sql select queries on the not upgraded database:

          select count from ResourceAction; -> 566
          select count from ResourceCode; -> 0
          select count from Permission_; -> 0
          select count from Resource_; -> 0
          select count from Roles_Permissions; -> 0

          Not everything is missing for com.liferay.portlet.journal.model.JournalArticle just some are.
          select * from ResourceAction where name='com.liferay.portlet.journal.model.JournalArticle';

          I get:
          536 com.liferay.portlet.journal.model.JournalArticle ADD_DISCUSSION 2
          537 com.liferay.portlet.journal.model.JournalArticle DELETE 4
          538 com.liferay.portlet.journal.model.JournalArticle EXPIRE 8
          539 com.liferay.portlet.journal.model.JournalArticle PERMISSIONS 16
          540 com.liferay.portlet.journal.model.JournalArticle UPDATE 32
          541 com.liferay.portlet.journal.model.JournalArticle VIEW 1

          So there are some entries missing, at least "DELETE_DISCUSSION".

          Show
          Tobias Kaefer added a comment - I did some a sql select queries on the not upgraded database: select count from ResourceAction; -> 566 select count from ResourceCode; -> 0 select count from Permission_; -> 0 select count from Resource_; -> 0 select count from Roles_Permissions; -> 0 Not everything is missing for com.liferay.portlet.journal.model.JournalArticle just some are. select * from ResourceAction where name='com.liferay.portlet.journal.model.JournalArticle'; I get: 536 com.liferay.portlet.journal.model.JournalArticle ADD_DISCUSSION 2 537 com.liferay.portlet.journal.model.JournalArticle DELETE 4 538 com.liferay.portlet.journal.model.JournalArticle EXPIRE 8 539 com.liferay.portlet.journal.model.JournalArticle PERMISSIONS 16 540 com.liferay.portlet.journal.model.JournalArticle UPDATE 32 541 com.liferay.portlet.journal.model.JournalArticle VIEW 1 So there are some entries missing, at least "DELETE_DISCUSSION".
          Hide
          Alexander Chow added a comment -

          And you are also missing UPDATE_DISCUSSION. Looks like Ray added those two resource actions as part of LPS-3734, but they were never picked up (probably because you don't really use Journal?).

          In any case, we should not be throwing the exceptions. Your code has been committed to trunk. Thanks!

          Show
          Alexander Chow added a comment - And you are also missing UPDATE_DISCUSSION. Looks like Ray added those two resource actions as part of LPS-3734 , but they were never picked up (probably because you don't really use Journal?). In any case, we should not be throwing the exceptions. Your code has been committed to trunk. Thanks!
          Hide
          Julio Camarero added a comment -

          Thanks a lot Tobias. This has already been fixed in trunk and backported to previous versions. Next versions of liferay will have this fixed.

          Show
          Julio Camarero added a comment - Thanks a lot Tobias. This has already been fixed in trunk and backported to previous versions. Next versions of liferay will have this fixed.

            People

            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:
                Days since last comment:
                4 years, 27 weeks, 4 days ago

                Development

                  Structure Helper Panel