Testing: Hierarchy Module

[matthewjmckinley]

Create hierarchies of resources for organization and display. Each hierarchy can contain multiple nested groupings, and each grouping may optionally contain objects from a selected item set.

Please test:

• Creating, updating & re-ordering hierarchies
• Creating, updating, assigning item sets & re-ordering groupings within hierarchies
• Hierarchies & groupings display and in correct order on:
  • Site page block (admin interface and actual page)
  • Public & admin side item page (for an item that belongs to an item set assigned to a grouping. Test assigning an item to multiple groupings too)
  • Public item set browse page
• Checking/unchecking "Show all hierarchy groupings" in the Hierarchy module configuration, ensuring that all groupings in a hierarchy appear on item & item set page when checked, and only direct ancestors/descendants of relevant itemSet grouping appear when unchecked
  • Note that the site page block appearance should always show all groupings in a hierarchy, regardless of this setting

Thanks!

[katknow]

I don't know if it matters, but even after I click save my browser doesn't want me to click away because it says it won't save. However, it's saving perfectly fine. Even if I don't change anything I get the warning. Don't know if there's anything to do about this, but I thought it was unusual considering this doesn't usually happen when I save in S. It's happening in Firefox, Chrome, and Edge.

[katknow]

Should the Hierarchy Label appear when you add a Hierarchy block to a page?

[matthewjmckinley]

Whoops thought I responded to this earlier! Hierarchy Label display is a great idea, I've added it as a checkbox option on the module config page.

The warning dialogue when navigating away is a trickier one. There's a markDirty flag attached to the o:before-form-unload event which looks to see if form content has been changed and triggers the warning when navigating away from a page, to let someone know their changes might not be saved. It's not behaving as expected, obviously, and seems to be acting up on other jsTree-utilizing features such as site navigation and List of Pages site block as well. Will keep looking at it!

[katknow]

Should it be impossible to delete a grouping from a hierarchy? I'm having this weird thing happen where I can delete a whole hierarchy, but if I try to delete a grouping it is reappearing after I hit save... (which I don't think was happening before)

[matthewjmckinley]

@katknow Oops, forgot to implement grouping deletion when I redesigned the JSTree to save each grouping individually to the database. Should be added (back) in latest commit!

[katknow]

This now seems to be working for the most part! Just to clarify though--where on the private item page should I be seeing the hierarchy listings? See it on the public side but not the admin page. Also, the appearance of the hierarchies on the public item set page looks odd in several themes.

[matthewjmckinley]

Hmmm, I'm seeing the hierarchy on both the public and admin side for items, even when set to private. Can you give me more info or a screenshot?

Or perhaps you meant on the item set admin page? I realized I had added Hierarchies to the item set public page but not on the admin side. Fixed in one of the recent commits.

Finally, I did what I could for how Hierarchies display in different themes but I think I need to talk to Kim and/or Nelson about a more holistic review/approach. The fact is that including the Hierarchy titles and nested list is more complicated than pretty much any other metadata value fields, styling-wise, so probably needs more finesse in how all the dt, dd and list elements are handled.

[allanaaa]

1) I didn't understand the "Hierarchy label" checkbox - I thought it would replace all the in-module labels with the item sets' original names, which I imagine would be helpful for many people who have no interest in titling things twice. I'm not totally clear on the use case for having separate labels that override item set names, but as long as you can turn it off and on it's fine by me.

1b) What about an option to display both, "[Hierarchy label] - [Item Set Title]"? Then you could have hierarchical context information in one place (like folder identifiers) and a plain-language name on the item set.

2) Got an odd line break on the hierarchy title here.

3) I would like a setting that allows parent item sets show child item sets' resources - in an archives usage only the very bottom level of item sets will have content, and the upper item sets will all be empty. Item Sets Tree does it (https://omeka.org/s/modules/ItemSetsTree/) so I hope it's not too complicated.

[allanaaa]

4) There's nothing stopping me from setting an item set as its own parent, child, or sibling. It will probably be kind to people who are setting up digital representations of physical collections to eliminate an item set from a hierarchy's dropdown when it is already selected. This may also be a setting you can turn on and off, if you can see a reason to allow it sometimes.

[matthewjmckinley]

@allanaaa

1. Hierarchy label checkbox has to do with displaying the titles of the whole hierarchy as the hierarchy title/header on public pages, and doesn't have to do with hierarchy grouping labels. Maybe I shoud change the Hierarchy label/setting from 'label' to 'title' to more clearly differentiate from the hierachy grouping label?

Regarding the manually-set label vs. itemSet title, very fair point. I think I had conceived of this approach when we were still discussing having different resource selection methods than just itemSet for each hierarchy grouping, but with only itemSet it does seem silly there's no way to 'carry over' the itemSet title to the grouping.

How about this: I updated the module's logic so that 1) if a grouping has a manually inputted label from the Hierarchy module page/form, use that, 2) If no label, copy the itemSet title into the grouping label field, or 3) if no label AND no itemSet, leave both label and itemSet blank (this would effectively create a 'blank' grouping/list item in the hierarchy). This allow users flexibility in how they apply grouping labels, while still saving them the work of manually labelling a bunch of groupings that already have corresponding itemSets. Is this satisfactory?

2. I couldn't recreate this, even with the same # of groupings arranged in the same way. Can you give me more info on the page/theme/any other environmental details where this is happening?

3. Can you give me more detail on how this would work? As in, when you click on a 'parent' grouping, it would return a page with all child grouping itemSet resources grouped together? Feels like it would be less confusing to leave the parent groupings unlinked and only have content available for groupings/archival containers that actually contain content. Also, although maybe not as common I've definitely seen archives organized with content at a folder level and additional content within a subfolder of that same level, and AFAIK there's nothing discouraging this organizational scheme in traditional archives practice so I think we need to allow people that flexibility.

4. This is a good idea but hard to implement in practice. Since the itemSet selections are 'set' only when the form is saved, there's not really a way to remove itemSets from consideration in 'real-time' while multiple groupings are being set up. I suppose there MIGHT be a way to move the itemSet population logic to javascript but even then I'm not sure it's possible to repopulate the drop-downs dynamically without reconfiguring/ignoring how Omeka S traditionally handles forms, which would introduce a lot of other complications.

Keeping the form submission as-is, we could probably pick out groupings from the same hierarchy that are set to the same itemSet and only assign that itemSet to the first grouping found, but this seems like it would also be confusing to users. I do see how this is useful to someone with a lot of groupings/itemSets but it would just be pretty complex to implement for something that isn't a core requirement of the module. Happy to talk more about it though!

[allanaaa]

For 2, it's got a dt width value of 22.2222%. Probably things in the sidebar should not be picking up that CSS:

[allanaaa]

For 4, I'm thinking of other ways we remove an option once it's been added.

I'm not clear on the underlying code for each of these types of selectors, but surely we have a method already in place? Maybe each grouping should be on its own page, since you probably only want to eliminate options per grouping....

[allanaaa]

For 3, I would direct you to the Collection Tree plugin for Classic, and the Item Sets Tree module. It shows a total item count for the parents based on their items + children's items, displays the children sets in a tree on the parent view page, and shows all the cumulative items on the parent view page. I'm using it here (see the bottom of the page where the tree is, and the "Publications" item set, which has 0 items in it): https://cfha.info/omekas/s/digital-archives/page/welcome

Another use case: A general grouping called "Photos", wherein the photos are organized chronologically, and the box titling is arbitrary date ranges based on however much fits inside a physical box. So we get "Famous Person's Fonds > Personal Stuff > Photos > 1920-1924; 1925-1926; 1926-1935; 1936-1972" because that's just how many physical photos there are in each grouping. If we wanted to represent the photos in Omeka there would be no need to FORCE users to look inside one item set/box at a time, but we still want to align the digital and physical by keeping the photos sorted by their boxes. You should be able to go to the "Photos" parent item set and browse all those child photos, or go to a box if you want to. In this case "Photos" shows the total number of items inside its children, not "0" for its own items. I think a lot of organizations want to do "groupings" in Omeka by making lots of item sets, sticking things in one item set each, and then organizing those item sets hierarchically with parents showing their children's contents. Yes, we could do that with another metadata value. But for importing from another system, this is probably a lot more direct. Which is not to say there isn't room for groupings based on search queries in the future! Intellectual groupings are often applied on top of physical groupings. But we definitely want to get the physical stuff right before we release a first version of this. Now, since we're thinking of importing, why not just take an item and put it in all of its hierarchical item sets? Import the photo into 1920-1924, into Photos, into Personal Stuff, and into Famous Person's Fonds (and into some thematic item sets too). Problem solved! But for making new items, adding them to five item sets each might be annoying, even batch-editing. Hence, a setting to turn it off and on.

This is also helpful for 1, the title display discussion. I may not want item set titles like "Famous Person's Fonds > Personal Stuff > Photos > 1920-1924" and "Famous Person's Fonds > Personal Stuff > Photos > 1936-1972", nor might I want hundreds of item set titles like "1920-1924". One is cumbersome and the other is vague, depending on the collection. If I was being really officious my org would use identifier codes for item set titles, and have the more human-readable titles as secondary values and/or the custom labels in the module. But we can save people effort here by having that full hierarchy breadcrumb displayed really prominently, adjacent to the title. Note that ArchivesSpace has a breadcrumb like this:

It's not my favourite visually, but at least it's right there at the top of the page.

I agree that it would be challenging to have items in a parent set, and more items in a child set, and try to represent both at the same time. We don't really have a means to differentiate those, like adding a third metadata value to the browse heading and browse body properties .... maybe "[Item Set/Label] - Item Title" in the heading? It would also be difficult to, say, include children items in the parent browse and then offer a user button to exclude those children items in order to expose the parent's items more easily. "Show only contents of this folder and not the subfolders"? Confusing. But I think a setting to "include descendants" will cover the intentions of most orgs.

I would also inclue Zach in this discussion, because his museum background will add some things to model outside my archives thinking.

[allanaaa]

5) I am hoping the hierarchy will be its own resource page block - like Mapping - rather than just stuck on the end of the Values block? Then people can make it as prominent as they want. 5b) There is nothing visually different right now from the item set view page, and an item view page in that item set. I.e. the hierarchy on this page, http://dev.omeka.org/amayer/amayer-s/omeka-s/s/my-second-omeka-s-site/item-set/4255, and one of its items look identical. Could we maybe put the item title in the hierarchy on the item pages? Or do something different there?

6) I should double-check with you that the module handles multiple title values well, e.g. language-tagged titles respect locale settings on sites, etc. I wonder if there is a clever way to make multiple titles and labels work together....

7) When I tried to remove the hierarchy label, it gave me an error, but it ALSO displayed the "successfully updated" message.

Otherwise, emptying an existing item set and existing label worked great.

8) I see it pulls the item set title into a textual label when you save; I wonder if we can instead just leave the label blank when not in use, the way we do on site navigation?

[matthewjmckinley]

2. OK I see the problem. Fixed in the latest commit!
3. There’s a lot of different facets to this, as you’ve covered. With the additional context I can see how consolidating resource counts/resources for child groupings underneath parent groupings is useful for expressing archival fonds structure. I think that is mostly doable and will start looking into it. It’s a little trickier having the parent grouping link to a page showing all child grouping resources, since right now it’s simply linking to the omeka s core itemSet page, and we wouldn’t want to override the itemSet page for all use cases to only show the ‘combined’ hierarchy grouping resources. I guess the solution here is instead of linking to the existing itemSet page, create a new ‘hierarchyGrouping’ page/route/url that can combine all the resources on a single page. This has the added bonus of allowing for more visual customization of this page in the future. And yes, wrapping all this in an ‘show child grouping resources in parent grouping’ option seems like the best move.
4. The problem is not that we don’t have methods for removing options as they are added, it’s that these methods are all designed to work with a single entity. So if you have say a hierarchy that contains 4 groupings, each grouping has its own itemSet selector, and there’s no way that I can see to update the other groupings’ selectors in real time as options are assigned within the current grouping. Breaking out each hierarchy into its own page could be a way forward, but this would introduce complexity for both the codebase and the end user, so I’d have to think a bit more about how that would work…
5. Again, maybe I’m looking in the wrong place, or I’m missing a setting somewhere on my Mapping module, but as far as I can tell the Mapping map appears within the same item Values block as the metadata, Item Sets, etc. which is why I also put the Hierarchy values there. Does yours look different? 5b. I’m getting a permissions error when I try to view the linked page you included, but I see what you are getting at. Perhaps I can change the title on each page to ‘Hierarchies containing [itemSet title]’ and ‘Hierarchies containing [item title]’, respectively.
6. Not totally clear on multiples of which title you mean—do you mean if an itemSet has multiple language-tagged, locale-specific titles, AND the itemSet title is copied over into an empty grouping label value? Because in that case yeah, the dynamic local-specific title would not be happening in the grouping label. However, if we do have a setting to display the itemSet title in addition to the label, that would (or could) be dynamic. We could also have all itemSet title values display after the label in that case, perhaps separated by a ‘-‘. Thoughts?
7. Hmm I can’t replicate this one either. I can’t find anything in the code requiring a label value. Is this still happening and if so can you describe more of the context?
8. I’m confused—I can definitely leave the label field blank (as happens when an itemSet is not chosen), but I thought you wanted a way to “replace all the in-module labels with the item sets' original names, which I imagine would be helpful for many people who have no interest in titling things twice” ? Or maybe I can also make this a ‘Replace empty grouping labels with title of assigned item set’ option in the module config?

[allanaaa]

I've just updated to the latest.

7 is still happening - create a hierarchy, give it a hierarchy label, save, then clear the field and save.

[allanaaa]

For 8, I mean like this:

The Label field stays blank when you're not overriding the page name with it. It's just a clearer UX way to show that you haven't manually entered anything. But it's fine I guess. (When I said "replace" earlier, I didn't mean literally replace a new variable with identical content from elsewhere, I meant just load the original content.)

[allanaaa]

For 6, yes, I mean the same issue we've had with timeline and map and carousel just respecting a site locale and pulling the correct language-tagged title if available. It was just a reminder of something I thought of - I haven't tested it myself. I suppose this would relate to 8 - if you're just showing the item set title instead of copying that text into a label, respecting language tags should be easier, right?

[allanaaa]

For 5, I mean here on the resource page block config:

I would want to be able to move Hierarchy around the page, for items and for item sets.

5b. The permissions error is coming from this module, right?

Item set hierarchy:

Item hierarchy (in that item set):

So, maybe just another indented bullet showing the item title within the item set, for the second one (doesn't need to be a link). And I guess don't bold the item set?

[matthewjmckinley]

3. The config options to display the # of items contained after each grouping, as well as the option to 'combine' the counts of child groupings and also return the items within all child groupings on the hierarchy grouping browse page, are in place.

One thing to note that tripped me up for a while: if an item belongs to multiple itemsets and both of those itemSets are assigned to groupings within a hierarchy, the item count that displays after the grouping will be different than the # of returned items on the public hierarchy grouping page, because the itemSetCount() function is counting the item each time it appears in a respective item set, but when the database is queried for the paginated list the item is obviously only going to be retrieved once. I don't think this will be an issue bc placing the same item into multiple folders goes against fundamental archival practice, but just FYI.

For the other issues, in the order raised:

7 OK apologies, I see what the issue was. This is is fixed with latest commits, BUT it required a redefining of database entities, which means you'll need to do a full uninstall/re-install of the module for it to work. But after that, empty hierarchy labels should be allowed.

8. I get it now--leave the label field blank if not provided, but still use the itemSet title (if an item set is assigned) on public and admin pages in place of the label. This should be in place and working.

9. Locale fix is in place, anywhere itemSet titles are used for the grouping label.

10. and 5b. Working on these, but may take a little while to get right because I have to redo how and where I'm rendering both the item and itemSet hierarchy lists. Let me know if this is a must have for first release.

[matthewjmckinley]

LMK if there are any other issues or must-haves before we ready for initial release. Thanks!

I did do some testing with all the various themes, and noticed some nested list display issues with The Daily, Freedom, and Center Row (though I haven't tested with all the recent changes yet). If you wouldn't mind playing around with the themes and noting which ones might need fixing before we go live, and if so we can reach out to Kim and Nelson.

[matthewjmckinley]

The markdown is forcing the incorrect numbering of my reply list above, even when I manually change it. Hopefully you can figure out which number refers to what by context, sorry!

[matthewjmckinley]

@allanaaa OK I actually got Hierarchy working as a resource page block for both items and itemsets in the latest commit, so another thing to do a quick test on.

LMK if everything is working right from the list above, and with the different themes, and/or if anything else is a must have before I package for first release.

Thanks and have a nice holiday!

[allanaaa]

I just got a Hierarchy error when testing something else. Having the module enabled in its current state is giving an error to my Editor-level user merely on accessing an item:

Omeka\Api\Exception\PermissionDeniedException Permission denied for the current user to search the Hierarchy\Api\Adapter\HierarchyGroupingAdapter resource.

Details:

Omeka\Api\Exception\PermissionDeniedException: Permission denied for the current user to search the Hierarchy\Api\Adapter\HierarchyGroupingAdapter resource. in /var/www/html/amayer/amayer-s/omeka-s/application/src/Api/Manager.php:208 Stack trace:

0 /var/www/html/amayer/amayer-s/omeka-s/application/src/Api/Manager.php(59): Omeka\Api\Manager->execute(Object(Omeka\Api\Request))

1 /var/www/html/amayer/amayer-s/omeka-s/modules/Hierarchy/Module.php(88): Omeka\Api\Manager->search('hierarchy_group...', Array, Array)

2 /var/www/html/amayer/amayer-s/omeka-s/vendor/laminas/laminas-eventmanager/src/EventManager.php(319): Hierarchy\Module->addItemAdminHierarchies(Object(Laminas\EventManager\Event))

3 /var/www/html/amayer/amayer-s/omeka-s/vendor/laminas/laminas-eventmanager/src/EventManager.php(171): Laminas\EventManager\EventManager->triggerListeners(Object(Laminas\EventManager\Event))

4 /var/www/html/amayer/amayer-s/omeka-s/application/src/View/Helper/Trigger.php(60): Laminas\EventManager\EventManager->triggerEvent(Object(Laminas\EventManager\Event))

5 /var/www/html/amayer/amayer-s/omeka-s/vendor/laminas/laminas-view/src/Renderer/PhpRenderer.php(407): Omeka\View\Helper\Trigger->__invoke('view.show.sideb...')

6 /var/www/html/amayer/amayer-s/omeka-s/application/view/omeka/admin/item/show.phtml(108): Laminas\View\Renderer\PhpRenderer->__call('trigger', Array)

7 /var/www/html/amayer/amayer-s/omeka-s/vendor/laminas/laminas-view/src/Renderer/PhpRenderer.php(519): include('/var/www/html/a...')

8 /var/www/html/amayer/amayer-s/omeka-s/vendor/laminas/laminas-view/src/View.php(194): Laminas\View\Renderer\PhpRenderer->render(NULL)

9 /var/www/html/amayer/amayer-s/omeka-s/vendor/laminas/laminas-view/src/View.php(222): Laminas\View\View->render(Object(Laminas\View\Model\ViewModel))

10 /var/www/html/amayer/amayer-s/omeka-s/vendor/laminas/laminas-view/src/View.php(187): Laminas\View\View->renderChildren(Object(Laminas\View\Model\ViewModel))

11 /var/www/html/amayer/amayer-s/omeka-s/vendor/laminas/laminas-mvc/src/View/Http/DefaultRenderingStrategy.php(98): Laminas\View\View->render(Object(Laminas\View\Model\ViewModel))

12 /var/www/html/amayer/amayer-s/omeka-s/vendor/laminas/laminas-eventmanager/src/EventManager.php(319): Laminas\Mvc\View\Http\DefaultRenderingStrategy->render(Object(Laminas\Mvc\MvcEvent))

13 /var/www/html/amayer/amayer-s/omeka-s/vendor/laminas/laminas-eventmanager/src/EventManager.php(171): Laminas\EventManager\EventManager->triggerListeners(Object(Laminas\Mvc\MvcEvent))

14 /var/www/html/amayer/amayer-s/omeka-s/vendor/laminas/laminas-mvc/src/Application.php(360): Laminas\EventManager\EventManager->triggerEvent(Object(Laminas\Mvc\MvcEvent))

15 /var/www/html/amayer/amayer-s/omeka-s/vendor/laminas/laminas-mvc/src/Application.php(341): Laminas\Mvc\Application->completeRequest(Object(Laminas\Mvc\MvcEvent))

16 /var/www/html/amayer/amayer-s/omeka-s/index.php(21): Laminas\Mvc\Application->run()

17 {main}

[matthewjmckinley]

Whoops, forgot to add specific permissions when I retooled the public item/item set/hierarchy view page. Should be fixed in latest commit!

[allanaaa]

I'm wondering whether sites can have more individual control over how this module displays.

1. If an item set is not added to a site via the Resources tab, how should this module display the relevant groupings? Should the hierarchies for an item just display the same no matter what site it's on, or should the hierarchies only display if the item sets are part of the site? Is that 1) only if all of the item sets in the hierarchy are resources, or 2) if at least one of the item sets is a resource?
2. Should the global configuration options actually be site-specific options? They are all display-related.
3. ... Alternatively, should hierarchies themselves be site-specific? What if you could add each hierarchy to a site like it's a resource itself? Because hierarchies don't actually affect any behind-the-scenes organization of materials, it probably shouldn't be all-or-nothing for public display - users should be able to choose which hierarchies are going to show on each site.

[allanaaa]

I'm still getting "Permission denied" on public pages:

https://dev.omeka.org/amayer/amayer-s/omeka-s/s/my-omeka-s-site/page/welcome

[allanaaa]

AND I'm getting lower-user-level errors on items:

Omeka\Api\Exception\NotFoundException Omeka\Entity\ItemSet entity with criteria {"id":4146} not found

Details:

Omeka\Api\Exception\NotFoundException: Omeka\Entity\ItemSet entity with criteria {"id":4146} not found in /var/www/html/amayer/amayer-s/omeka-s/application/src/Api/Adapter/AbstractEntityAdapter.php:722 Stack trace:

0 /var/www/html/amayer/amayer-s/omeka-s/application/src/Api/Adapter/AbstractEntityAdapter.php(440): Omeka\Api\Adapter\AbstractEntityAdapter->findEntity(Array, Object(Omeka\Api\Request))

1 /var/www/html/amayer/amayer-s/omeka-s/application/src/Api/Manager.php(230): Omeka\Api\Adapter\AbstractEntityAdapter->read(Object(Omeka\Api\Request))

2 /var/www/html/amayer/amayer-s/omeka-s/application/src/Api/Manager.php(115): Omeka\Api\Manager->execute(Object(Omeka\Api\Request))

3 /var/www/html/amayer/amayer-s/omeka-s/application/src/View/Helper/Api.php(69): Omeka\Api\Manager->read('item_sets', 4146, Array)

4 /var/www/html/amayer/amayer-s/omeka-s/modules/Hierarchy/src/View/Helper/HierarchyHelper.php(165): Omeka\View\Helper\Api->read('item_sets', 4146)

5 /var/www/html/amayer/amayer-s/omeka-s/modules/Hierarchy/src/View/Helper/HierarchyHelper.php(174): Hierarchy\View\Helper\HierarchyHelper->Hierarchy\View\Helper{closure}(Object(Hierarchy\Api\Representation\HierarchyGroupingRepresentation))

6 /var/www/html/amayer/amayer-s/omeka-s/modules/Hierarchy/src/View/Helper/HierarchyHelper.php(177): Hierarchy\View\Helper\HierarchyHelper->Hierarchy\View\Helper{closure}(Object(Hierarchy\Api\Representation\HierarchyGroupingRepresentation))

7 /var/www/html/amayer/amayer-s/omeka-s/modules/Hierarchy/src/View/Helper/HierarchyHelper.php(145): Hierarchy\View\Helper\HierarchyHelper->getChildItemsets(Object(Hierarchy\Api\Representation\HierarchyGroupingRepresentation), Array)

8 /var/www/html/amayer/amayer-s/omeka-s/modules/Hierarchy/src/View/Helper/HierarchyHelper.php(259): Hierarchy\View\Helper\HierarchyHelper->itemSetCount(Object(Hierarchy\Api\Representation\HierarchyGroupingRepresentation), Array)

9 /var/www/html/amayer/amayer-s/omeka-s/modules/Hierarchy/src/View/Helper/HierarchyHelper.php(294): Hierarchy\View\Helper\HierarchyHelper->Hierarchy\View\Helper{closure}(Array, Object(Omeka\Api\Representation\ItemSetRepresentation))

10 /var/www/html/amayer/amayer-s/omeka-s/modules/Hierarchy/src/View/Helper/HierarchyHelper.php(217): Hierarchy\View\Helper\HierarchyHelper->Hierarchy\View\Helper{closure}(Array, Object(Omeka\Api\Representation\ItemSetRepresentation))

11 /var/www/html/amayer/amayer-s/omeka-s/modules/Hierarchy/src/View/Helper/HierarchyHelper.php(308): Hierarchy\View\Helper\HierarchyHelper->Hierarchy\View\Helper{closure}(Array, Object(Omeka\Api\Representation\ItemSetRepresentation))

12 /var/www/html/amayer/amayer-s/omeka-s/modules/Hierarchy/Module.php(106): Hierarchy\View\Helper\HierarchyHelper->buildNestedList(Array, Object(Omeka\Api\Representation\ItemSetRepresentation), Object(Omeka\Api\Representation\ItemRepresentation))

13 /var/www/html/amayer/amayer-s/omeka-s/vendor/laminas/laminas-eventmanager/src/EventManager.php(319): Hierarchy\Module->addItemAdminHierarchies(Object(Laminas\EventManager\Event))

14 /var/www/html/amayer/amayer-s/omeka-s/vendor/laminas/laminas-eventmanager/src/EventManager.php(171): Laminas\EventManager\EventManager->triggerListeners(Object(Laminas\EventManager\Event))

15 /var/www/html/amayer/amayer-s/omeka-s/application/src/View/Helper/Trigger.php(60): Laminas\EventManager\EventManager->triggerEvent(Object(Laminas\EventManager\Event))

16 /var/www/html/amayer/amayer-s/omeka-s/vendor/laminas/laminas-view/src/Renderer/PhpRenderer.php(407): Omeka\View\Helper\Trigger->__invoke('view.show.sideb...')

17 /var/www/html/amayer/amayer-s/omeka-s/application/view/omeka/admin/item/show.phtml(108): Laminas\View\Renderer\PhpRenderer->__call('trigger', Array)

18 /var/www/html/amayer/amayer-s/omeka-s/vendor/laminas/laminas-view/src/Renderer/PhpRenderer.php(519): include('/var/www/html/a...')

19 /var/www/html/amayer/amayer-s/omeka-s/vendor/laminas/laminas-view/src/View.php(194): Laminas\View\Renderer\PhpRenderer->render(NULL)

20 /var/www/html/amayer/amayer-s/omeka-s/vendor/laminas/laminas-view/src/View.php(222): Laminas\View\View->render(Object(Laminas\View\Model\ViewModel))

21 /var/www/html/amayer/amayer-s/omeka-s/vendor/laminas/laminas-view/src/View.php(187): Laminas\View\View->renderChildren(Object(Laminas\View\Model\ViewModel))

22 /var/www/html/amayer/amayer-s/omeka-s/vendor/laminas/laminas-mvc/src/View/Http/DefaultRenderingStrategy.php(98): Laminas\View\View->render(Object(Laminas\View\Model\ViewModel))

23 /var/www/html/amayer/amayer-s/omeka-s/vendor/laminas/laminas-eventmanager/src/EventManager.php(319): Laminas\Mvc\View\Http\DefaultRenderingStrategy->render(Object(Laminas\Mvc\MvcEvent))

24 /var/www/html/amayer/amayer-s/omeka-s/vendor/laminas/laminas-eventmanager/src/EventManager.php(171): Laminas\EventManager\EventManager->triggerListeners(Object(Laminas\Mvc\MvcEvent))

25 /var/www/html/amayer/amayer-s/omeka-s/vendor/laminas/laminas-mvc/src/Application.php(360): Laminas\EventManager\EventManager->triggerEvent(Object(Laminas\Mvc\MvcEvent))

26 /var/www/html/amayer/amayer-s/omeka-s/vendor/laminas/laminas-mvc/src/Application.php(341): Laminas\Mvc\Application->completeRequest(Object(Laminas\Mvc\MvcEvent))

27 /var/www/html/amayer/amayer-s/omeka-s/index.php(21): Laminas\Mvc\Application->run()

28 {main}

[matthewjmckinley]

The Permission Denied should be fixed with latest commits, I did not cast a wide enough net with the permissions.

I'm not able to reproduce the lower level "Item Set Not Found" error--I'm guessing this happened after you deleted an itemSet? In any case this made me realize that Hierarchy Grouping records were getting deleted when an associated Item Set record got deleted, which is not what we want. Fixed that with latest commits as well, but since it changes DB fields it will require a re-install of the Hierarchy module. Sorry about that!

Hopefully the commits fix both issues but can def keep troubleshooting if not.

I will look into your hierarchy display/site setting suggestions

[allanaaa]

I just noticed that groupings only display a count if they are set to an item set. That means that if you have a parent grouping without an item set selected, it doesn't show the combined total of all its children. Can that be fixed?

[matthewjmckinley]

Yep, added in latest commit!

[allanaaa]

I am still getting errors on the public side, for people who aren't logged in. If an item is in no hierarchy, it's fine, but if it's any grouped item set:

https://dev.omeka.org/amayer/amayer-s/omeka-s/s/my-omeka-s-site/item/10098#lg=1&slide=0

[allanaaa]

Ah! One of the item sets in the hierarchy is set to private. That will need to be handled more gracefully.

[matthewjmckinley]

Good catch! Took some finessing but I believe private itemSets are hidden with the latest commit.

They're handled the same way as groupings with no title and no itemSet assigned--they will appear in the hierarchy tree but just as a blank space (or sometimes an underscore, I found on some pages the blank list item was causing formatting problems without anything there). If there's items in child groupings and the proper settings are set, those should still be appearing even with private/unassigned itemSet groupings.

[matthewjmckinley]

For the site settings questions:

It does seem like a good idea to allow more site specific tailoring. It seems to me that options 1 and 3 you gave are different approaches to enabling site-specific hierarchy customization--which seems like a better choice? Both seem do-able from my current perspective. Option 3 seems maybe a little cleaner but also adds a step, i.e. a hierarchy must be added as a discrete resource before it appears on a site. Whereas with option 1 the hierarchy will just show up for relevant items/itemSets on a site and can be tailored from there. I'm game for either really.

For question 2, I can work on making the settings site specific. Keep in mind this will mean that combined/discrete item counts will not appear for the hierarchy module/items/itemSets on the admin side. Or alternately, they can appear on the admin side but there will be no way to turn them off. I guess I could leave the module config settings just for the admin side but that seems like it muddies the waters too much?

[allanaaa]

Sorry, a short aside: Can you rearrange the configuration options? "Display resource counts" should probably come above "Combine resources".

[allanaaa]

I'm getting an odd issue where some groupings are disappearing on the admin side but showing on public:

The first "Bottom shelf" grouping seemed to be gone, so I made a second one, and that's not displaying either.

[allanaaa]

Deleting its parent didn't do anything.

There seems to be some inconsistency when deleting a parent node, as well - sometimes the children are retained and just bump up their level, and sometimes they are deleted too. Is that, perhaps, only if a grouping has an item set, it's retained, but groupings without item sets are deleted?

[matthewjmckinley]

Config options have been re-arranged, will updated with my next commit push.

I'm seeing both those errors too. It's a pretty complicated thing to have the ability to create/edit/rearrange a multi-dimensional drag and drop list along with all the grouping-specific metadata and settings without duplicates etc. There's a lot of iterating, conditionals and nested for loops happening.

All this to say that grouping printing and/or deletion especially for some reason can have some funky behaviors that take a while to track down, but looking into it now!

[allanaaa]

So, what's the plan for groupings that don't have anything to link to, but still appear as links on the public pages? Are you going to remove links when there is no item set attached? Or keep the links when one of the children has an item set, and there are items to show, but get rid of them if the count is 0 items?

http://dev.omeka.org/amayer/amayer-s/omeka-s/s/my-omeka-s-site/hierarchy/60

In this hierarchy I've got items in Folder 2, so Shelf 5 and some of its contents, but the rest of the links will bring up an error message because they have no items to point to.

Notice: Undefined variable: itemSetIDArray in /var/www/html/amayer/amayer-s/omeka-s/modules/Hierarchy/src/Controller/Site/IndexController.php on line 27

And when you get that, it shows all the items added to the site.

[matthewjmckinley]

Latest commit gets rid of both the grouping page link and the item count text if there are no returned items to show

[allanaaa]

I've updated but I'm still getting the link (though the count thing is working):

http://dev.omeka.org/amayer/amayer-s/omeka-s/s/my-omeka-s-site/hierarchy/60

[allanaaa]

The resource page block (for both items and item sets) shouldn't be showing when the item set itself isn't in any hierarchies:

[matthewjmckinley]

Latest commit should fix both the missing admin-side sibling issue and the deleting-parent-not-deleting-nested-descendants issue. Will look into the newer stuff when I am back next week!

[matthewjmckinley]

Made link appearance/removal consistent and removed hierarchy resource page block when no hierarchies exist with latest commits. Also, moved removed hierarchy appearance settings from Module config and moved to Site settings.

Now working on adding hierarchies as a tab to the Site resources form, so users can control which sites they appear on.

[allanaaa]

The sidebar needs to calculate its width better for 5+ levels. Maybe we can also shrink the bullet-point indentations a bit?

[allanaaa]

Hierarchy browse pages don't respect my site pagination settings (18 results per page) and are instead showing the installation pagination (60 results per page).

http://dev.omeka.org/amayer/amayer-s/omeka-s/s/my-omeka-s-site/hierarchy/75

On item sets where the hierarchy resource block is displaying, same:

http://dev.omeka.org/amayer/amayer-s/omeka-s/s/my-omeka-s-site/item-set/4255

Item sets not yet in a hierarchy are fine:

http://dev.omeka.org/amayer/amayer-s/omeka-s/s/my-omeka-s-site/item-set/4147

So I assume the module is the issue, but I have no idea why.

[allanaaa]

Also, a grouping with an item set attached appears in bold when you're on its page, while a grouping without an item set does not appear in bold. Should probably be bold all the time if it's for navigation purposes.

[matthewjmckinley]

OK most of these things are addressed with the latest commits. All probably need a little further testing, especially assigning which hierarchies to display per site from the site left nav bar.

Two outstanding things:

• I'm not seeing any issues with the test pages you linked RE: pagination. The items are paginating properly for me, with 18 per page. The second page has changed and only has one object, and is also throwing a warning, which will hopefully be fixed with the latest code.

[matthewjmckinley]

RE: the calculated width issues above for larger hierarchies, @kimisgold do you think you could take a look when you have a moment? I think you probably have a better sense for how the containers are working together. Though I can definitely take a look if you're too busy rn