Open pkoenig10 opened 8 years ago
Maybe not outright prevent, but force the coordinator to acknowledge a message that the org ABSOLUTELY needs the tool. Or require the coordinator to tap/swipe their ID.
-- Aamer On Apr 13, 2016 2:23 PM, "Patrick Koenig" notifications@github.com wrote:
Either show a warning or prevent an org form checking them out.
— You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub https://github.com/sc0v/binder-app/issues/182
I think an acknowledgement is good. I would say having the coordinator tap their ID is too much.
This does point to an issue which was never really resolved. We currently don't do any verification that the user logged-in is who they say they are. There are lots of things such as this that can be resolved by looking at logs to see who did something, but unless people are super diligent about logging in and out on the trailer computer those logs aren't very useful to actually show who did something.
On Wed, Apr 13, 2016 at 12:55 PM Patrick Koenig notifications@github.com wrote:
I think an acknowledgement is good. I would say having the coordinator tap their ID is too much.
— You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub https://github.com/sc0v/binder-app/issues/182#issuecomment-209621260
Maybe implement a tap in/tap out feature?
--Aamer On Apr 13, 2016 17:25, "Chase Brownell" notifications@github.com wrote:
This does point to an issue which was never really resolved. We currently don't do any verification that the user logged-in is who they say they are. There are lots of things such as this that can be resolved by looking at logs to see who did something, but unless people are super diligent about logging in and out on the trailer computer those logs aren't very useful to actually show who did something.
On Wed, Apr 13, 2016 at 12:55 PM Patrick Koenig notifications@github.com wrote:
I think an acknowledgement is good. I would say having the coordinator tap their ID is too much.
— You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub https://github.com/sc0v/binder-app/issues/182#issuecomment-209621260
— You are receiving this because you commented. Reply to this email directly or view it on GitHub https://github.com/sc0v/binder-app/issues/182#issuecomment-209652909
We discussed the potential for a soft limit on the tools of a certain type that orgs can checkout, but to mitigate tool hoarding, we are opting for a tool checkout time length after which orgs can renew the tools instead.
Our IS Team is looking into this new feature now, so I will close this issue.
I'm not sure a time limit is the right solution. That places a relatively large burden on SCC to hunt down tools when their time expires. I think any solution with hard and fast rules (time limit, tool checkout limit, etc.) might be more work than it is worth.
I think an acknowledgement by the coordinator may be the best option because it doesn't add require any additional work, but surfaces that relevant information to the coordinator when the tool is being checked out.
The renewal feature is part of a notification feature that would allow people to renew tools with a phone. We agreed to pilot the feature this year but we will be revisiting the issue after Carnival, where we can decide how well this solved the problem and can again consider the other solutions.
Renewing with a phone doesn't solve the issue of it being the Coordinator's responsibility to track down people. Also if you can renew with a phone then what does that really solve other than reminding people they have stuff checked out, and if that's the goal then let's just make it a reminder and get rid of the "renewal" portion
The goal is to remind people of tools that they have checked out and prevent tool hoarding by increasing tool turnover.
Amalia and I have already discussed this with this years exec board and are moving forward with this plan. Like I said before, after carnival we will certainly revisit this issue and evaluate our implemented solution against other potential solutions, and make a decision from there.
Please don't close an issue until it has been resolved in the master branch. Just discussing an issue doesn't mean it's resolved because it's easy for things to be forgotten or overlooked. Even if this isn't the exact solution we want, it's useful to keep the issue open as long as the real-world problem still exists.
Sorry, that is my fault! I meant to open a new issue that better captured the notification feature we want our IS team to work on this semester, but never did.
Instead of closing this issue by opening another, I will just adjust this issue to reflect the notifications feature we decided to implement this semester.
This is now a sub-issue of issue #244
Either show a warning or prevent an org form checking them out.