Status of New Resource Lists and Acquisitions
When a new list is created and saved- it is instantly live. In order to allow the list creator to decide when the list is finished and ready to be made public or ready for the library to acquire resources for the course- other options for status of a list are needed.
Suggestions: Draft- Finished- Published- Archived
Idea: A status 'Finished' could automatically generate a report to the library so that they can acquire the necessary resources for the course. This kind of report would need to include course information as well as some indication around the importance of each item to the course - essential reading- further reading- recommended student purchase etc in order to inform purchasing decisions.
We are in progress with a story which will allow users to edit in “draft” and only publish to the world when they choose. However this does not include an Archived state – if this is still required please raise a new idea
AdminIan Corns (Talis) (Admin, Talis) commented
IMPORTED COMMENT HISTORY
16/06/2009 03:15:48 [Chris Clarke (Talis)]
Our current thinking is to split this problem into two and break the dependencies between them. The problems as I see it are:
1. Being able to make unpublished changes to a list and at a later date make them published
2. Indicating to a "reviewer" that a list is ready for some form of checking
In the case of 2 I would expect that the reviewer could be an acquisitions department making sure the relevant stock is available to the student.
I worry that if we couple these two problems together into a workflow sequence then they cannot happen in parallel, e.g. review MUST happen before Publishing changes.
17/06/2009 01:52:54 [a.moore]
Just to clarify your points, are you thinking that changes could be made to a list and the list published without being reviewed by acquisitions because not all changes to a list would require 'review' or have resourcing implications?
17/06/2009 02:41:48 [Chris Clarke (Talis)]
I think we want to be able to support customers who want to provide unmediated and mediated lists - so I think the system should be built to be configured to allow both cases. In the case of mediated lists, i.e. wanting to review all lists before a "publish" step can be completed, perhaps we could configure the permissions so list creators can only save changes and request a review, and not actually publish. Then the reviewers can review and when happy, maybe they could instigate the publish step?
17/06/2009 04:28:56 [a.moore]
I really like this solution. Configuring the permissions for list creators would give greater flexibility and meet the needs of customers with both mediated and unmediated resource lists.
28/07/2009 11:49:20 [Ian Corns (Talis)]
We have started to do some work on this under XIP-1324, which deals with saving changes and publishing later (e.g. draft, published). However, as this covers some other transitions, I'm going to leave it as "Active" for the moment until we get the early
functionality out. We can then revisit this idea, and see if we need to separate some of the other concepts it deals with out into new ideas.