Enhancement: add an admin reporting page #2420

Activity

1. fiver-watson commented on Aug 27, 2026

   

   fiver-watson

   on Aug 27, 2026

   Contributor

   More actions

   Cool idea! But this also opens a can of worms in some ways... Some long-term thoughts for the product team:

   First:

   This sounds like the makings of an excellent dashboard-style landing page for admins, or even just authenticated users. Implementing something like that becomes much more imaginable when we actually fully separate out the public-facing UI from the staff interface.

   I know that seems huge and should likely be considered separately from this proposal. However:

   • ASI needs an actionable plan in place YESTERDAY for the long-term maintenance and development of AtoM 2.x, and a way to separate that from any next-generation reimagining (e.g. something linked data-driven, etc). In the meantime, any new feature development in AtoM that builds upon the existing framework should be seriously questioned, as it adds complexity and maintenance burden. We need to incorporate the features that our users want into our plan so we can make it happen sooner rather than later, and not treat them as separate issues
   • Internally we have a lot of experimental work that could speed us towards such a possibility. The most promising of these is the AtoM Facade. If this were fully fleshed out and stress-tested, it igives us everything we need to start the work of building a new separate front-end for AtoM mediated by a modern API with transactional integrity. At first the new front-end could be lightweight, proof of concept even - and we could then quickly iterate on it over time and through subsequent sprints, depending on key user problems and priorities. However, this immediately starts helping us solve many of AtoM's long-standing issues and complaints - permissions module not working at scale, no publication statuses for other entities, archival domain language in places where researchers might benefit from different labeling, federation of many AtoM sites to a single front-end - and of course, administrative and reporting features like this enhancement request!

   Second:

   Half of the proposed query functionality already exists via Description Updates. Most of the other information is already in the application, but scattered around (settings, result pages, repository view pages, etc), making it difficult to see and manage at a glance. I think that makes this issue ticket a strong candidate to be rewritten as a problem statement first, to determine what the real need is here and how else it could be addressed.

   Not that an overview dashboard is a bad proposal! Frankly I think it would be very helpful, especially for larger and/or multi-repository sites.

   In any case, there is a strong argument to build on Description Updates for this enhancement proposal, rather than adding a brand new page that duplicates a good part of the query options.

   Whatever solution is considered, it should consider these overlaps and how that affects testing and maintenance going forward.

   Third:

   Whenever you start talking about site-wide data, you are going to have clients asking for repository-specific data, and that needs to be considered for any long-term planning as well. Artefactual should remember its AtoM history in this area.

   Specifically, we once built a per-repository analytics module for one of the regional portal clients - but at scale it quickly became a problem to manage and maintain. Years later, the alternative was to remove the custom feature (which never did make it into a public release) and instead add public support for Google Tag Manager, which if configured properly, can be used to give detailed per-repository analytics. See the Web Analytics docs.

   Analytics will continue to be a requested feature, especially for portal sites ,but it would be great to a) support an open-source alternative by default, and b) have a little more configuration or visibility directly in AtoM.

   All this to say: the placement and use of web analytics in AtoM has a strong overlap with reporting and admin-view requests. Ideally it should be considered alongside any kind of proposal, in light of my other points above.

   Finally:

   Obviously work should be scoped to a problem, done in small batches, and built-upon iteratively. But in terms of visioning, that doesn't mean you shouldn't start looking down the road at the possibilities and consequences that any design choice opens and closes.

   To wit: once you start thinking about an Admin overview / dashboard type page, there is also the option to start easing the support burden for our team, particularly with lower-service tiers who do not have CLI access.

   I am thinking about UI support for non-destructive, low-risk command-line tasks and/or database queries that are frequently asked, and can often resolve common support requests. Just look at our Troubleshooting documentation for examples. Having an Administrator be able to clear all caches, rebuild the nested set, regenerate slugs, etc. via the user interface would actually help free up support staff to focus on more trenchant client problems, and would fit well on such a page. Similarly, many of the common database queries in our docs and asked in the forum are either informational for reporting purposes, or else to solve common data issues. We should consider how incorporating these into an Admin module would help our team focus on the right work.

   Just a thought or two to consider long-term!
2. sromkey commented on Sep 1, 2026

   

   sromkey

   on Sep 1, 2026

   Contributor

   More actions

   Potentially related: #2284