Tool renewal text notifications

[pkoenig10]

Either show a warning or prevent an org form checking them out.

[arakla]

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" [email protected] 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
#182

[pkoenig10]

I think an acknowledgement is good. I would say having the coordinator tap their ID is too much.

[ChaseBro]

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 [email protected]
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
#182 (comment)

[arakla]

Maybe implement a tap in/tap out feature?

--Aamer
On Apr 13, 2016 17:25, "Chase Brownell" [email protected] 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 [email protected]
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
#182 (comment)

—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub
#182 (comment)

[sclark]

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.

[pkoenig10]

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.

[sclark]

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.

[ChaseBro]

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

[sclark]

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.

[pkoenig10]

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.

[sclark]

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.

[sclark]

This is now a sub-issue of issue #244