Can I add my endorsement to what was said below. I want academics to be able to assign a list to a node, and it makes sense for this to be bundled with the list publisher role.

What would be really useful is for the list publisher permission to allow a list to be linked to a node - that would cut down on the number of permissions needed

I endorse absolutely what Georgina has said. Academics will want to attach lists to nodes and if they cannot may lose interest in the system. We would also depend on their telling us each time a list was created, to which node they wanted it attached. This ability should be quite separate from the ability to edit the hierarchy.

We want the academics to be able to attach their lists to their modules - we've implemented Aspire in order to empower the academics in terms of them doing more work throughout the process. We definitely don't want them to be able to mess about with the hierarchy though! In addition, we'd like librarians (both academic and acquisitions) to be able to attach lists to modules, but we only want the sysadmin to be able to edit the hierarchy. Thus, we'd also like "edit nodes" split down into "attach lists to modules" and "be able to edit hierarchy" (still a bit unfamiliar with that side so perhaps that needs breaking down too or at least rephrasing). Thansk.

We have given library staff the role of list publisher, but also want the library staff to be able to attach lists to units without being able to edit nodes. This is because the we need to keep the hierarchy in the state it has been given to by the student registry system, which is the master source of data at the university. In the post by Ian Corns entitled 'What are the default roles and permissions in Talis Aspire?' for Jan, under the edit nodes permission description it notes "NB. We plan to split this permission down into more granular set of permissions in the future (edit, create and attach)." We'd like to see this granularity sooner rather than later.
Thanks