These are chat archives for collectiveaccess/support

19th
Sep 2017
Kehan Harman
@kehh
Sep 19 2017 03:59
@juliaweist This is so that users don't choose terms that don't apply to their particular record type when editing records. These are effectively dependant values in the lists where the values are dependant on the type of record being edited. We are planning on implementing this functionality in CA - we just wanted to do it in a way that was consistent your way of doing things rather than just tacking it on. This is the result of the fact that there will be some users who are less trained than others and we want to still ensure data quality by putting the onus on the system to do this rather than the user, thereby reducing the chance of PEBKAC.
ericwm
@eriwm
Sep 19 2017 14:39
Hi,
Has his seting been removed from prov 1.7.5 I was not able to find it in my app.conf.
Enabling a "cross-table" hierarchy
Cook Book Chapter 2
Problem
You want to be able to nest Object records underneath Collections hierarchically.
Solution
In app.conf, set:

ca_objects_x_collections_hierarchy_enabled = 1
ca_objects_x_collections_hierarchy_relationship_type = part_of
Julia
@juliaweist
Sep 19 2017 15:00
Hi @kehh ok understood. The way that would most closely follow how we are currently handing this would be a type restriction on the list item, articulated the same way we handle restrictions on displays in the profile, i.e.:
<display code="example" type="ca_objects" system="1" typeRestrictions="library" includeSubtypes="0">
the problem is, though, that we don't define list items for a particular table the way we do for displays, editors, etc.
Julia
@juliaweist
Sep 19 2017 15:07
Are the values that are applicable to the record types grouped in any way in the list, for example underneath common parents?
If so a better solution may be to adapt the style of our restrict_to_list setting to target specific hierarchy levels and all their children
Julia
@juliaweist
Sep 19 2017 15:16
Hi @eriwm thanks for catching that. The feature wasn't removed but it was accidentally left out of app.conf when we redesigned the layout with ASCII art headers :-). I've added it back and pushed to GitHub/develop.
ericwm
@eriwm
Sep 19 2017 15:37
@juliaweist Thanks Julia, I will do an update,
Kehan Harman
@kehh
Sep 19 2017 16:50
@juliaweist thanks for those pointers. I was starting to think something along the lines of what you've recently done with bundle placements on forms where there's a setting to restrict the types / subtypes for a specific placement similar to https://github.com/collectiveaccess/providence/blob/master/app/models/ca_editor_ui_screens.php#L1719-L1738. However your idea of a parent term may work. However there are options that might be shared between collections so the sublists are not mutually exclusive I don't think.