Unable to access Users App after 2.32 -> 2.37.2 upgrade

I recently upgraded our test instance of DHIS2 from 2.32 to 2.37. After the upgrade, any attempt to access the Users app spits out the error below. Has anyone else seen this? (I had to strip the links from the error message as it won’t let me post.)

Thanks!
Simon.

An error occurred in the DHIS2 application.
The following information may be requested by technical support.

TypeError: a.canCreate is not a function
at mn.userHasAuthorities
at routeConfig.ln.reduce.routes
at Array.reduce ()
at mn.setRouteConfig
at mn.componentWillReceiveProps
at pa
at Si
at Ci
at Fo
at Yo

in mn
in Connect(mn)
in t
in withRouter(Connect(mn))
in t
in div
in En
in t
in xn
in a
in Unknown
in Suspense
in div
in E
in div
in H
in Q
in Y
in DHIS2RuntimeProvider
in P
in N
in R
in m

I did some more digging. I used the developer mode console in Chrome and found the following

a.canCreate is not a function in
react-dom.production.min.js
line 198

Hi @swoodworth,
The issue might be caused by the browser cache, would you try to sign-in using a superuser account in an incognito/private mode? If it works using incognito mode then please try to clear your browser cache using the Browser Cache Cleaner app and maybe use the Empty Cache and Hard Reload:

@kpvandivier :

If the above doesn’t work please share your Catalina.out log (without including any sensitive info). Thank you!

Hi @Gassim, many thanks for the prompt response.

I have tried clearing the browser cache on Chrome, as well as a forced reload and using an incognito tab. I also tried a different firefox browser on Linux. All with the same error screen.

As a new user I am not yet permitted to upload files, sorry. So here is a DropBox link to the relevant logfiles Dropbox - DHIS2 Error Logs - Simplify your life

Hi yes, thanks for sharing the files, and welcome to the community!
Unfortunately, I can’t find any error or relevant warning that indicates users won’t have access to the Users app. Are you able to access the API endpoint → [yourInstance]/api/37/me?fields=authorities? If so please confirm you have in that list the authority: M_dhis-web-maintenance-user

I’ll also ask for support. I hope we’ll solve this soon. Will let you know if further info is required, thanks!

Hi @Gassim I did this and the full list of authorities is below. Interestingly, the M_dhis-web-maintenance-userauthority is missing.

{“authorities”:[“F_TRACKED_ENTITY_INSTANCE_SEARCH_IN_ALL_ORGUNITS”,“ALL”,“F_USERGROUP_MANAGING_RELATIONSHIPS_ADD”,“F_USER_VIEW”,“M_dhis-web-interpretation”,“F_GENERATE_MIN_MAX_VALUES”,“F_USER_GROUPS_READ_ONLY_ADD_MEMBERS”,“F_PREDICTOR_RUN”,“F_IGNORE_TRACKER_REQUIRED_VALUE_VALIDATION”,“M_dhis-web-user”,“M_Immunization_analysis”,“M_dhis-web-translations”,“F_REPLICATE_USER”,“F_SEND_EMAIL”,“F_INSERT_CUSTOM_JS_CSS”,“M_dhis-web-visualizer”,“F_ENROLLMENT_CASCADE_DELETE”,“F_VIEW_EVENT_ANALYTICS”,“M_dhis-web-event-reports”,“F_VIEW_UNAPPROVED_DATA”,“F_IMPORT_EVENTS”,“M_dhis-web-maintenance”,“F_USERGROUP_MANAGING_RELATIONSHIPS_VIEW”,“F_TEI_CASCADE_DELETE”,“F_EXPORT_DATA”,“M_dhis-web-cache-cleaner”,“F_EDIT_EXPIRED”,“M_dhis-web-event-visualizer”,“F_PROGRAM_DASHBOARD_CONFIG_ADMIN”,“F_APPROVE_DATA_LOWER_LEVELS”,“M_dhis-web-datastore”,“M_dhis-web-reports”,“M_dhis-web-data-quality”,“M_dhis-web-menu-management”,“F_ORGANISATIONUNIT_MOVE”,“M_dhis-web-dataentry”,“M_dhis-web-pivot”,“F_SKIP_DATA_IMPORT_AUDIT”,“M_dhis-web-usage-analytics”,“F_RUN_VALIDATION”,“M_dhis-web-importexport”,“M_dhis-web-settings”,“F_IMPORT_DATA”,“M_dhis-web-maintenance-mobile”,“M_dhis-web-tracker-capture”,“F_LOCALE_ADD”,“M_dhis-web-maps”,“F_METADATA_IMPORT”,“F_EXPORT_EVENTS”,“M_dhis-web-reporting”,“M_dhis-web-data-visualizer”,“F_PERFORM_MAINTENANCE”,“M_dhis-web-dashboard”,“F_METADATA_EXPORT”,“M_dhis-web-data-administration”,“F_APPROVE_DATA”,“F_ACCEPT_DATA_LOWER_LEVELS”,“M_dhis-web-scheduler”,“M_dhis-web-capture”,“F_TRACKED_ENTITY_UPDATE”,“M_dhis-web-app-management”,“M_dhis-web-messaging”,“M_dhis-web-mapping”,“F_UNCOMPLETE_EVENT”,“M_dhis-web-sms-configuration”]}

Interesting that you can’t find it but it explains why you aren’t able to access the app. :sweat_smile:

We’ll need further support to see how to solve this issue :+1:

@Gassim thanks. I wonder is it relevant to add that when I upgraded from 2.32 to 2.37.2, the flyway migration from 2.32 to 2.33 failed. I had to dig into the Flyway migration script and manually complete the migration. The scripts are written in Java and I am experienced in that language and I can find my way around a database, so I was reasonably confident that I completed it successfully. I have no idea if this is relevant but I include some details as follows:

The impacted table in PostGRES is jobconfiguration

The failing script and my fix are below:

/**

 * @author David Katuscak (katuscak.d@gmail.com)

 */

public class V2_33_1__Job_configuration_job_type_column_to_varchar extends BaseJavaMigration

{

    private static final Logger log = LoggerFactory

        .getLogger( V2_33_1__Job_configuration_job_type_column_to_varchar.class );

    @Override

    public void migrate( final Context context )

        throws Exception

    {

        // 1. Check whether migration is needed at all. Maybe it was already

        // applied. -> Achieves that script can be

        // run multiple times without worries

        boolean continueWithMigration = false;

        String sql = "SELECT data_type FROM information_schema.columns " +

            "WHERE table_name = 'jobconfiguration' AND column_name = 'jobtype';";

        try ( Statement stmt = context.getConnection().createStatement();

            ResultSet rs = stmt.executeQuery( sql ); )

        {

            if ( rs.next() && rs.getString( "data_type" ).equals( "bytea" ) )

            {

                continueWithMigration = true;

            }

        }

        if ( continueWithMigration )

        {

            // 2. Create a new JobType column of type VARCHAR in

            // jobconfiguration table

            try ( Statement stmt = context.getConnection().createStatement() )

            {

                stmt.executeUpdate(

                    "ALTER TABLE jobconfiguration ADD COLUMN IF NOT EXISTS jobtypevarchar VARCHAR(120)" );

            }

            // 3. Move existing jobtype from bytearray column into varchar

            // column

            Map jobTypeByteMap = new HashMap();

            sql = "SELECT jobconfigurationid, jobtype FROM jobconfiguration WHERE jobtype IS NOT NULL";

            try ( Statement stmt = context.getConnection().createStatement();

                ResultSet rs = stmt.executeQuery( sql ); )

            {

                while ( rs.next() )

                {

                    jobTypeByteMap.put( rs.getInt( "jobconfigurationid" ), rs.getBytes( "jobtype" ) );

                }

            }

            jobTypeByteMap.forEach( ( id, jobTypeByteArray ) -> {

                JobType jobType = (JobType) SerializationUtils.deserialize( jobTypeByteArray );

                if ( jobType == null )

                {

                    log.error( "Flyway java migration error: Parsing JobType byte array failed." );

                    throw new FlywayException( "Parsing JobType byte array failed." );

                }

                try ( PreparedStatement ps = context.getConnection().prepareStatement(

                    "UPDATE jobconfiguration SET jobtypevarchar = ? WHERE jobconfigurationid = ?" ) )

                {

                    ps.setObject( 1, jobType.name() );

                    ps.setInt( 2, id );

                    ps.execute();

                }

                catch ( SQLException e )

                {

                    log.error( "Flyway java migration error:", e );

                    throw new FlywayException( e );

                }

            } );

            // 4. Delete old byte array column for JobType in jobconfiguration

            // table

            try ( Statement stmt = context.getConnection().createStatement() )

            {

                stmt.executeUpdate( "ALTER TABLE jobconfiguration DROP COLUMN jobtype" );

            }

            // 5. Rename new jobtypevarchar column to the name of the now

            // deleted column

            try ( Statement stmt = context.getConnection().createStatement() )

            {

                stmt.executeUpdate( "ALTER TABLE jobconfiguration RENAME COLUMN jobtypevarchar TO jobtype" );

            }

        }

    }

}


dhis2=# select data_type from information_schema.columns where table_name = 'jobconfiguration' and column_name = 'jobtype';
 data_type
-----------
 bytea
(1 row)

dhis2=# select jobconfigurationid, jobtype, jobtypevarchar from jobconfiguration;

jobconfigurationid |                                                                                                                  jobtype                                                                                                                   |         jobtypevarchar
--------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------
                 54 | \xaced00057e7200206f72672e686973702e646869732e7363686564756c696e672e4a6f625479706500000000000000001200007872000e6a6176612e6c616e672e456e756d0000000000000000120000787074001f56414c49444154494f4e5f524553554c54535f4e4f54494649434154494f4e | VALIDATION_RESULTS_NOTIFICATION
                 57 | \xaced00057e7200206f72672e686973702e646869732e7363686564756c696e672e4a6f625479706500000000000000001200007872000e6a6176612e6c616e672e456e756d0000000000000000120000787074001e52454d4f56455f455850495245445f52455345525645445f56414c554553   |
                 53 | \xaced00057e7200206f72672e686973702e646869732e7363686564756c696e672e4a6f625479706500000000000000001200007872000e6a6176612e6c616e672e456e756d0000000000000000120000787074000f444154415f53544154495354494353                                 | DATA_STATISTICS
                 56 | \xaced00057e7200206f72672e686973702e646869732e7363686564756c696e672e4a6f625479706500000000000000001200007872000e6a6176612e6c616e672e456e756d00000000000000001200007870740015444154415f5345545f4e4f54494649434154494f4e                     | DATA_SET_NOTIFICATION
                 52 | \xaced00057e7200206f72672e686973702e646869732e7363686564756c696e672e4a6f625479706500000000000000001200007872000e6a6176612e6c616e672e456e756d0000000000000000120000787074001546494c455f5245534f555243455f434c45414e5550                     | FILE_RESOURCE_CLEANUP
                 55 | \xaced00057e7200206f72672e686973702e646869732e7363686564756c696e672e4a6f625479706500000000000000001200007872000e6a6176612e6c616e672e456e756d0000000000000000120000787074001843524544454e5449414c535f4558504952595f414c455254               | CREDENTIALS_EXPIRY_ALERT
(6 rows)

It looks like the migration started but fsailed for jobconfiguration id=57.

Inspection of the migration script and using a hex edit at Hex to ASCII | Hex to Text converter reveals the correct jobtypevarchar value to be
REMOVE_EXPIRED_RESERVED_VALUES.

So we will insert this and complete the rest of the script manually.

dhis2=# ALTER TABLE jobconfiguration DROP COLUMN jobtype;
ALTER TABLE
dhis2=# select * from jobconfiguration;
dhis2=# update jobconfiguration set jobtypevarchar = 'REMOVE_EXPIRED_RESERVED_VALUES' where jobconfigurationid=57;
UPDATE 1
dhis2=# select jobtypevarchar from jobconfiguration;
         jobtypevarchar
---------------------------------
 VALIDATION_RESULTS_NOTIFICATION
 REMOVE_EXPIRED_RESERVED_VALUES
 DATA_STATISTICS
 DATA_SET_NOTIFICATION
 FILE_RESOURCE_CLEANUP
 CREDENTIALS_EXPIRY_ALERT
(6 rows)
dhis2=# ALTER TABLE jobconfiguration RENAME COLUMN jobtypevarchar TO jobtype;
ALTER TABLE
dhis2=# select jobtypevarchar from jobconfiguration;
ERROR:  column "jobtypevarchar" does not exist
LINE 1: select jobtypevarchar from jobconfiguration;
               ^
dhis2=# select jobtype from jobconfiguration;
             jobtype
---------------------------------
 VALIDATION_RESULTS_NOTIFICATION
 REMOVE_EXPIRED_RESERVED_VALUES
 DATA_STATISTICS
 DATA_SET_NOTIFICATION
 FILE_RESOURCE_CLEANUP
 CREDENTIALS_EXPIRY_ALERT
(6 rows)

dhis2=# select data_type from information_schema.columns where table_name = 'jobconfiguration' and column_name = 'jobtype';
     data_type
-------------------
 character varying
(1 row)

This looks like it is fixed.

2 Likes

Thank you for the update @swoodworth! Very happy you were able to solve the issue. I wonder if you know why the migrations failed?

If it turns out that this is a bug then we could create a jira bug issue in jira.dhis2.org. – and bug hunters are tagged in the #copmonthly :laughing::+1::+1:

Thanks!

@Gassim sorry my copy and paste of my log is a little unclear. The final line “This looks like it is fixed.” refers only to solving the migration failure issue. Users app failure is tull an issue sadly.

I had a dig around in PostGRES and did the following.

insert into userroleauthorities(userroleid,authority) values (59, ‘M_dhis-web-maintenance-userauthority’);

That updated the authorities as follows:

{“authorities”:[“F_TRACKED_ENTITY_INSTANCE_SEARCH_IN_ALL_ORGUNITS”,“ALL”,“F_USERGROUP_MANAGING_RELATIONSHIPS_ADD”,“F_USER_VIEW”,“M_dhis-web-interpretation”,“F_GENERATE_MIN_MAX_VALUES”,“F_USER_GROUPS_READ_ONLY_ADD_MEMBERS”,“F_PREDICTOR_RUN”,“F_IGNORE_TRACKER_REQUIRED_VALUE_VALIDATION”,“M_dhis-web-maintenance-userauthority”,“M_dhis-web-user”,“M_Immunization_analysis”,“M_dhis-web-translations”,“F_REPLICATE_USER”,“F_SEND_EMAIL”,“F_INSERT_CUSTOM_JS_CSS”,“M_dhis-web-visualizer”,“F_ENROLLMENT_CASCADE_DELETE”,“F_VIEW_EVENT_ANALYTICS”,“M_dhis-web-event-reports”,“F_VIEW_UNAPPROVED_DATA”,“F_IMPORT_EVENTS”,“M_dhis-web-maintenance”,“F_USERGROUP_MANAGING_RELATIONSHIPS_VIEW”,“F_TEI_CASCADE_DELETE”,“F_EXPORT_DATA”,“M_dhis-web-cache-cleaner”,“F_EDIT_EXPIRED”,“M_dhis-web-event-visualizer”,“F_PROGRAM_DASHBOARD_CONFIG_ADMIN”,“F_APPROVE_DATA_LOWER_LEVELS”,“M_dhis-web-datastore”,“M_dhis-web-reports”,“M_dhis-web-data-quality”,“M_dhis-web-menu-management”,“F_ORGANISATIONUNIT_MOVE”,“M_dhis-web-dataentry”,“M_dhis-web-pivot”,“F_SKIP_DATA_IMPORT_AUDIT”,“M_dhis-web-usage-analytics”,“F_RUN_VALIDATION”,“M_dhis-web-importexport”,“M_dhis-web-settings”,“F_IMPORT_DATA”,“M_dhis-web-maintenance-mobile”,“M_dhis-web-tracker-capture”,“F_LOCALE_ADD”,“M_dhis-web-maps”,“F_METADATA_IMPORT”,“F_EXPORT_EVENTS”,“M_dhis-web-reporting”,“M_dhis-web-data-visualizer”,“F_PERFORM_MAINTENANCE”,“M_dhis-web-dashboard”,“F_METADATA_EXPORT”,“M_dhis-web-data-administration”,“F_APPROVE_DATA”,“F_ACCEPT_DATA_LOWER_LEVELS”,“M_dhis-web-scheduler”,“M_dhis-web-capture”,“F_TRACKED_ENTITY_UPDATE”,“M_dhis-web-app-management”,“M_dhis-web-messaging”,“M_dhis-web-mapping”,“F_UNCOMPLETE_EVENT”,“M_dhis-web-sms-configuration”]}

But sadly had no appreciable effect. So I’m still stuck.

@Gassim this is NOT solved, sorry! See my earlier messages.

1 Like

Sorry for that! I removed the solved from the notice and will continue to follow up.

It’s probably not only the authority that’s missing, if you no longer have access to the userGroups for example the same issue will also occur.

@Gassim Many thanks! But where do I go from here? I am reluctant to tinker with the database further without specific direction.

1 Like

Thank you @swoodworth for your patience! The best I can help you now is for other community members to join the conversation, and at the same time I’m requesting for support from the dhis2 core team experts. I’ve triaged for info/support so if there’s any additional info/log that you think could be helpful in diagnosing the issue please add it. I know you’ve posted all necessary info above, thanks!

BTW, I am curious to know if this is a production environment (I hope not!)? And if you used the dhis2 docs when upgrading? Upgrading - DHIS2 Documentation … if not then what reference did you use?

I also have a tip, try to search in the community of practice topics as well as in the jira.dhis2.org incase you find any similar issue that has been solved. :grin:

Thanks!

Hi @Gassim it’s no problem and thanks for your support. No, this is not a production instance, thank goodness. We are still in the testing phase and will be for some time yet.

For the upgrade from 2.32 to to.2.37.2, I did indeed follow the instructuons at that link. I read all the upgrade notes for each intermediate step and performed all the required steps in sequence. I also upgraded to JDK11, Tomcat9 and PostGRES 12. I logged everything I did with Cherrytree.

1 Like

:+1::+1::+1:

@swoodworth since this is not a production environment, please try again by upgrading to 2.36.8 and see if you get the same issue, if not try to upgrade to 2.37.2 from 2.36.8 and see! Just a thought that it might work :smiley:

@Gassim Ugh. It’s a fair bit of effort for something that “might” work, as you put it. OK, I’ll see if I have a pre-upgrade backup to do this on.

@Gassim a possible alternative. I did a metadata export from the problematic instance and imported that data into a clean local DHIS2 2.37.2 instance that I created from scratch. While some test data are missing, this seems to have resolved the Users app issue. Is there any reason why this would not be a good solution? Thanks.

Yeah sorry! (: The installation manual says you should keep a pre-upgrade backup so I hope you still do.

I’m glad you thought of an alternative approach to solve this. Importing the data from an instance to another clean instance of the same version should work fine! I hope it’s a good solution but we’re not 100% sure what caused the issue in the other instance in the first place so please keep all the back-ups with you.

I’ll see if I can get more info. Thank you!