-
Notifications
You must be signed in to change notification settings - Fork 0
Features
The typical Drupal Node edit form is not available to users. Instead, build sections are used. By dividing the input fields into sections, it allows users to work on a record one section at a time without having to fill in all the required fields. If we used node edit, people would have to fill in all the required fields prior to saving a draft. This can be frustrating to staff and can result in people entering inaccurate data so the form can be saved.
The build pages are custom view modes and form modes. On the form display settings for the data_set content type, add the fields you need in a particular form mode.
Metadata records are a content type like any other in Drupal. How they get created and edited (built) differs from the Drupal default.
Staff create records using a webform on the dashboard. The Webform content creator module uses the fields from the webform to create a record with the title and the Office of Primary Responsibility pre-populated. Using a webform allows us to control the values that go into a record when it is created. It is also a better user experience, as the record appears in the My unpublished records view immediately. Once the node is created, we no longer need the webform submission. It gets auto-deleted 24 hours after creation.
The information schedule is managed by fields on a term in the Information schedule vocabulary.
Each information schedule has its own number, stored in field_schedule_code. The value of this field is generated on node save from the values in field_schedule_number of the current and all ancestor terms: Empty values are omitted and the remaining are concatenated, separated by hyphens. The code that does this is in html/modules/custom/bc_dc/bc_dc.module.
Note: for information on how the information schedule is put together, see Working with taxonomies > Information schedule (
node/53) in the data catalogue documentation.
The Taxonomy Access Control Lite is used to control access to a metadata record. Typically tac_lite works by assigning a taxonomy to a content type and a user. If the term on the user and on the node match, access is granted.
For the data catalogue, this wouldn’t work because of the requirement that the OPR always has access to their content, in other instances the public, BC government employees or members of another branch or branches may have access.
There is custom code that extends tac_lite. This allows administrators to restrict the access check to specific fields.
On the node, the fields field_primary_responsibility_org and field_visibility both reference the taxonomy Organization.
On the tac_lite settings page, manage > configuration > people > Access by Taxonomy, restrict access check to specified fields as needed per schema. In each schema, grant permissions to the term for each role as needed.
Warning
Because the settings for access control have a dependency on taxonomy terms, which are content, the settings for Access by taxonomy are not tracked in config.
Caution
For this feature to work as designed, the taxonomy organization has to be flat. Taxonomy Max Depth is used to ensure no additional levels can be added. Adding additional levels will break the feature.
By default, tac_lite provides a tab on the edit user page for administrators to assign people to terms. In the data catalogue, this behavior has been changed. A field, field_organization has been added to the user profile. Organizations chosen in this field are applied as the Access by Taxonomy terms. The addition of the field_organization in the user profile allows Data Catalogue administrators to easily assign org-based permissions and provides developers with a field to use in the development of organization-related features for users.
Warning
Make sure the field_organization field is always used to assign tac_lite permissions. If tac_lite permissions are assigned under the Access by Taxonomy tab, there will be a disconnect between a user's assigned org and the permissions they have in the catalogue.
What do future developers need to know about how this works?
Every Sunday, the web site will email authors a reminder with the link of each data_set that is due for an update. The review due date is the date in field_last_review_date plus the integer number of months recorded in field_review_interval. When the due date approaches within the number of days configured in bc_dc.settings:data_set_review_period_alert, the message given is the one configured in bc_dc.settings:review_needed_message. After the due date, the message is the one in bc_dc.settings:review_overdue_message. Sending the message is triggered in bc_dc_cron(), which is configured to run on Sundays by ultimate_cron.
data_set nodes that need review appear in a section on the dashboard. Next to each link on the dashboard, there is a badge indicating the needed update. On each node view and build page, there is a message indicating the needed update which is generated by block bc_dc_review_needed_message.
All of the sending is done by a call in bc_dc_cron(). The assumption is that this will never be a high volume of email messages. If messages fail to send, investigate if it is because of a failure of the cron task. A high volume of messages will require a queue worker to be set up to do the sending.
Data columns can be added to the data dictionary of a metadata record from section 6 of the build page. Users can download the current columns or a sample file, make edits, then upload. The uploaded columns will replace the existing ones. The code for this is in BcDcAddColumnsForm. The import runs in batches; by default, it adds 50 columns per batch. The batch size can be configured on admin/config/data-catalogue. Every batch will create a new draft revision (these will get cleaned-up by the pruner after the updated metadate records is published).