Uploaded image for project: 'mod-orders-storage'
  1. mod-orders-storage
  2. MODORDSTOR-213

Illegal cross-module *_mod_finance_storage.fund access on migration

    XMLWordPrintable

Details

    • ACQ Sprint 110, ACQ Sprint 111, ACQ Sprint 112
    • 2
    • Thunderjet
    • R1 2021 Bug Fix

    Description

      Overview:
      data-migration/11.0.0/po_line_sync_fund_code.ftl contains this sub-select:

      SELECT jsonb -> 'code'
      FROM ${myuniversity}_mod_finance_storage.fund
      WHERE jsonb ->> 'id' = distrib ->> 'fundId'
      

      mod-orders-storage violates the module separation by directly accessing ..._mod_finance_storage schema.

      The FOLIO architecture mandates that cross-module communication goes through HTTP APIs only.

      Some deployments (for example GBV multi-tenant installation) use database ROLEs with access restricted to the current schema. They fail when running this migration script.

      If one module requires that some other module exists it must list that other module's interface in its ModuleDescriptor "requires" section.
      mod-orders' Module Descriptor has a "requires" section that lists

            "id": "finance.funds",
            "version": "1.3"
      

      and

            "id": "orders-storage.po-lines",
            "version": "9.4"
      

      https://github.com/folio-org/mod-orders/blob/v11.2.0/descriptors/ModuleDescriptor-template.json#L731-L767

      This makes mod-orders a suitable place to run the migration using API calls.

      mod-orders-storage doesn't have a "requires" section in its ModuleDescriptor - this is correct to comply with the FOLIO architecture where each storage module stands on its own.

      Steps to Reproduce:

      # in first shell console
      # checkout mod-orders-storage with any
      # commit >= version 11.1.3, for example HEAD of master
      mvn clean install
      java -jar target/mod-orders-storage-fat.jar
      
      # in second shell console
      curl -s -D - -H 'Content-type: application/json' -H 'x-okapi-url-to: http://localhost:8081' -H 'x-okapi-tenant: diku' -XPOST -d '{ "module_to": "11.1.2" }' http://localhost:8081/_/tenant
      
      psql 'postgresql://username:password@localhost:6000/postgres' -c 'ALTER ROLE username NOSUPERUSER'
      
      curl -w'\n' -s -D - -H 'Content-type: application/json' -H 'x-okapi-url-to: http://localhost:8081' -H 'x-okapi-tenant: diku' -XPOST -d '{ "module_from": "11.1.2", "module_to": "11.1.3" }' http://localhost:8081/_/tenant
      

      Expected Results:
      The last curl upgrade POST succeeds.

      Actual Results:
      The last curl upgrade POST fails with a 400 error. This is the error log entry in the first console:

      PostgresClient trying to execute:  UPDATE diku_mod_orders_storage.po_line SET jsonb =     (       SELECT jsonb_set(jsonb, '{fundDistribution}', jsonb_agg(jsonb_set(distrib, '\{code}', coalesce((SELECT jsonb -> 'code' FROM diku_mod_finance_storage.fund WHERE jsonb ->> 'id' = distrib ->> 'fundId'), distrib -> 'code', '""'))))       FROM jsonb_array_elements(jsonb -> 'fundDistribution') distrib     ) WHERE jsonb_array_length(jsonb -> 'fundDistribution') > 0
      PostgresClient ERROR: relation "diku_mod_finance_storage.fund" does not exist
        Position: 188
      

      TestRail: Results

        Attachments

          Issue Links

            Activity

              People

                Andrei_Makaranka Andrei Makaranka
                julianladisch Julian Ladisch
                Votes:
                0 Vote for this issue
                Watchers:
                6 Start watching this issue

                Dates

                  Created:
                  Updated:
                  Resolved:

                  TestRail: Runs

                    TestRail: Cases