- Can only add one page at a time (need to do delete from zz_pages where zname is null;) then re-run config build with full – being triaged but apparently only in development at the moment.
'NoPagesFound' System Error on first loading - Needs update_fap then full config build then apache reload to get the security on the fap table correct. SR: 74878 e.g.
sudo zymonic_toolkit.pl System update_fap --system blacklist sudo zymonic_toolkit.pl System config_build --system blacklist --full yes sudo /etc/init.d/apache2 reload
Table 'alex_paf.zz_materialized_view_list' doesn't exist (manually creating it fixes the issue: SR: 74666
CREATE TABLE `zz_materialized_view_list` ( `mv_sequence_number` int(11) NOT NULL AUTO_INCREMENT, `flattened_query` varchar(255) DEFAULT NULL, `datetime_created` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP, `being_created` char(1) DEFAULT NULL, PRIMARY KEY (`mv_sequence_number`) ) ENGINE=MEMORY DEFAULT CHARSET=utf8;
- Role_permissions doesn't get populated initially – had to do: sudo zymonic_toolkit.pl System add_defaults --system paf --full yes : also SR: 74666
- Group didn’t set properly for the newly created superuser - update zz_user_groups set groupid = [ID OF ADMINS GROUP]; - being triaged
- Pages where the only block is a filter with no records in the DB do not show in the pages list (Transfer Management) - SR: 83904
- Systems that were created before role permissions were added require the following SQL running: update zz_process set current_state = 'zz_su_role_process_live', process = 'zz_superuser_role_process' where processid = (select parent_process_id from zz_roles where role = 'superuser');
- Zymobuild does not install zymonic.pl to the web root (noted in SR 75015). If the file at /var/www/localhost/cgi-bin/zymonic.pl appears to be out of date despite running zymobuild, copy it there from $zymonic-repo/cgi-bin/zymonic.pl, where $zymonic-repo is /root/trunk, /root/zymonic-qa or /root/zymonic-live for dev/qa/live respectively.
- On newly created systems, config_build sometimes creates duplicate system options, typically occurs with version. Workaround is to manually delete the duplicate from zz_system_options: it's usually missing the sec_id, sub_category and user_setting fields and will have a higher id than the original. See SR 81466 for any further developments.
- Under investigation - discrepancy between change column and add column sizes means primary keys attempt to be changed but then system fault.
- When a new table definition is added, it defaults to using the old record security mode even if all other tables use the new one, and thus needs updating to the new mode to avoid issues
- For tables with multiple definitions for the same SQLName, which table definition is used is sometimes random instead of using the one most appropriate for the system, which can lead to it using the wrong security mode if the definitions differ, see SR 96385
- No type or Zname system error occurs if the user has mutiple tabs open and re-logs-in in one of them; can be confirmed by searching system error for Security token does not match - SR: 96039
- Reports appear to be using outdated XSL - there's a known caching issue with tomcat and SaxonServlet. Can clear the cache by appending "?clear-stylesheet-cache=yes" to the url for the tomcat server, e.g. "http://10.40.40.222:8080/xslt/SaxonServlet?clear-stylesheet-cache=yes" for devtomcat if on the office network. Alternately, change the xslt_processor SystemOption from SaxonServlet to Saxon, as local saxon appears to avoid caching issues and will serve the updated stylehsheet.