Dennis Bridges talks about some features (to the left)
Need rankings...
Jira Legacy |
---|
server | System JiraJIRA |
---|
serverId | 01505d01-b853-3c2e-90f1-ee9b165564fc |
---|
key | UXPROD-2565 |
---|
|
- has plenty of comments back and forth
- use cases requested
- when an order is opened, a hold is placed on the item as soon as its created
- the requester field could potentially be user ID
- formerly free text
- Hold needs a user ID to create the hold
Comments: the item needs to exist in order to have a request put on it - so this Jira is designed to make that step easier by minimizing steps
question from the chat ""Create a hold" also mean create a recall?
I think this would be really good and time saving! We now have to go Inventory after having opened the order and then create the request (for us recall)."
Jira Legacy |
---|
server | System JiraJIRA |
---|
serverId | 01505d01-b853-3c2e-90f1-ee9b165564fc |
---|
key | UXPROD-2553 |
---|
|
- keeps tracks of organizations and roles
- controlled vocab
- multi-select is available
- editable (not required)
- filterable
- Jack Mulvaney talked about how useful a similar feature was in Coral
- Owen Stephens expresses some concerns about roles, licences, agreements...(Worried about blurred implementation of this and wants specificity in application)
- Mulvaney uses Coral as a backbone of FOLIO and did not provide a problem for roles and agreements information
- Virginia suggests it could be used as a workaround at Duke
- fields are not repeatable (in GBV context)
- Type of type is different than type of role
- Most would want repeatable
- The type would need to be stored in other apps in order to expand usage (but this could allow for searching/filtering)
- Would not want to compromise any direct workflows (maybe for year end stats)
- needs multi-select (not required multi-select but good for use)
- Owen: Might tags be used?
- general response is that this is NOT very usable (because they are not deletable and unreliable)
- Dennis suggests the controlled vocab works as a tag
- Yet, some feel that tags could be better developed if they could be deleted or used in very specific workflow scenarios
Jira Legacy |
---|
server | System JiraJIRA |
---|
serverId | 01505d01-b853-3c2e-90f1-ee9b165564fc |
---|
key | UXPROD-2409 |
---|
|
- designed to limit spending per expense class
- tethers expense classes to budgets
- uses unique account numbers
- Mt Holy Oke can't see limits in the expense class view (percentages spent, etc) to make sure overspending does not happen
- there are issues when a spending amount is a fixed number as opposed to something in a more dynamic situation (involving credits)
- Mt Holy Oke wants to know how much of total one expense class has paid as opposed to another
- wants that information to be folded into information about the budget
- As in an expense class is itself a percentage of the total available budget
- Wants alert as opposed to a stop when limits are being neared or reached
- Folks want to use this tool, but it still needs more usefulness
- Would you want to reset the target $ each year?
- nicer to roll over but that one could edit each year
- Some years simply need more manual engagement than other years (like 2020)