Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for adjustments #114

Open
wants to merge 4 commits into
base: master
Choose a base branch
from
Open

Add support for adjustments #114

wants to merge 4 commits into from

Conversation

glee-
Copy link

@glee- glee- commented Jun 15, 2019

Depends on ocf/ocflib#182

Allows staff members to adjust users' paper quotas in a more flexible manner.
We add the following functionality to the paper script:
forward: increases a user's daily quota for the day only

This is intended to be used to give users some degree of freedom when printing documents.

For example, if the daily print limit was set at 10 pages and a user wanted to print 12 pages, this would not be possible with the current way things are configured. forward provides the way to increase the daily print limit without increasing the amount of pages a user can print in a semester.

Copy link
Member

@abizer abizer left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

cursory check but lgtm

printing/paper Outdated


def staff_creds():
"""Return dictionary of staff creds, if we can read them."""
return json.load(open('/etc/ocfprinting.json'))
return json.load(open('/etc/ocfprinting-dev.json'))
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

fix this for prod

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

good catch

Copy link
Member

@MrMinos MrMinos left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this is a quite useful feature, might want to publicize this to the users at some point?
I don't think this at all needs to be hush-hush thing.

@@ -87,6 +88,11 @@ def main(argv=None):
parser_refund.add_argument('--reason', '-r', required=True, type=str)
parser_refund.add_argument('user', type=str)

parser_forward = subparsers.add_parser('forward', help="allow a user to print above today's quota")
parser_forward.add_argument('--pages', '-p', required=True, type=int)
parser_forward.add_argument('--reason', '-r', required=True, type=str)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Forward probably in itself is the reason, I don't know if this needs to be a required field. What do you think?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this is still fine, and it's a database constraint anyways

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Despite the reason being clear, I think this would be important to include due to the human aspect of it. A person who is issuing the forward request will need to think twice before actually increasing the daily quota for a particular user.

printing/paper Outdated
@@ -96,7 +102,10 @@ def main(argv=None):
print(bold(red("The user {} doesn't exist.".format(args.user))))
return 1

return commands[args.command](args)
if args.command == 'refund' or args.command == 'forward':
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Instead of an if statement here, which makes the subcommand logic harder to understand, you should put the same if statement in the adjust command (which has access to args and therefore args.command).

@@ -87,6 +88,11 @@ def main(argv=None):
parser_refund.add_argument('--reason', '-r', required=True, type=str)
parser_refund.add_argument('user', type=str)

parser_forward = subparsers.add_parser('forward', help="allow a user to print above today's quota")
parser_forward.add_argument('--pages', '-p', required=True, type=int)
parser_forward.add_argument('--reason', '-r', required=True, type=str)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this is still fine, and it's a database constraint anyways

Copy link
Member

@TonyLianLong TonyLianLong left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just a suggestion

printing/paper Outdated
user=args.user,
time=datetime.now(),
pages=args.pages,
action=type,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You can just leave refund as a method with 1 argument, but use args.command for the action parameter instead of adding parameter type (This is probably what @dkess says and in this case my comment can serve as a clarification).

Copy link
Member

@cg505 cg505 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

tyty

printing/paper Outdated
prompt = bold('Refund {} pages to {}? [yN] '.format(refund.pages, refund.user))

stringtype = 'Refund' if type == 'refund' else 'Forward'
prompt = bold(stringtype + ' {} pages to {}? [yN] '.format(payload.pages, payload.user))
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we're already using format here, just use it consistently.

Suggested change
prompt = bold(stringtype + ' {} pages to {}? [yN] '.format(payload.pages, payload.user))
prompt = bold('{} {} pages to {}? [yN] '.format(stringtype, payload.pages, payload.user))

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

8 participants