Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Info

Outside of the scenarios described above, the system solution to updating stale data is to enable the task_directory_person_refresh_trigger and set for a time to execute the refresh process as described above.  This should only need to be done one time as the external person sync process should trigger a refresh of the view.  Alternatively, the materialized views can be updated directly.  There is a risk that the Caseload and Search will not work while the database processes are executing.  The following queries could be used with the caution.

  • PG: select REFRESH_MV_DIRECTORY_PERSON()

  • SQL: exec REFRESH_MV_DIRECTORY_PERSON

  • PG: select REFRESH_MV_DIRECTORY_PERSON_BLUE()

  • SQL: exec REFRESH_MV_DIRECTORY_PERSON_BLUE

Also note that for SQLServer the "operational" SSP database user (db_username from $SSP_CONFIGDIR/ssp-config.properties) must be allowed to execute stored procedures. In most deployments this does not require special configuration, but in the event your security policies are such that that user must be explicitly granted execute permissions on specific stored procs, here are the statements which you would likely need to run. (Use 'dbo' for <schema> unless db_schema from $SSP_CONFIGDIR/ssp-config.properties is set to something else.

No Format
GRANT EXEC on <schema>.REFRESH_MV_DIRECTORY_PERSON to <ssp-operational-user>;
GRANT EXEC on <schema>.REFRESH_MV_DIRECTORY_PERSON_BLUE to <ssp-operational-user>;
GRANT EXEC on <schema>.update_directory_person_from_view_where_school_id to <ssp-operational-user>;
GRANT EXEC on <schema>.update_directory_person_from_view_where_person_id to <ssp-operational-user>;