Add cron

[elplatt]

Paul B from Dallas Makerspace says:

I was wondering if you guys would want to integrate the access controller we're
using - with seltzer. I'll send you a 4-door controller for free. You might need to
code an optional "hook" + cronjob into seltzer so it can call a webservice
when unpaid people are "deactivated" after a grace period.

Drupal's approach would probably work quite well. We add a cron.php file that loads the core and runs hook_cron() for every module. Then all the user has to do is add "wget http://localhost/cron.php" to their crontab.

Approval? Objections?

[pawl]

This repository has info about the access controller Dallas Makerspace is using: https://github.com/pawl/Chinese-RFID-Access-Control-Library/

This is the web service we're using to deactivate/activate badges: https://github.com/pawl/Chinese-RFID-Access-Control-Library/blob/master/examples/webserver.py

We use a billing system called WHMCS which has a hook for when people get deactivated by the daily cronjob. That hook triggers a request to the webservice above.

I would like to implement the same hook system in seltzer to help other hackerspaces automate their access control systems.

[pawl]

I've been looking more closely at Seltzer. It looks like this request would also involve implementing a Status field (Active/Inactive/Overdue) in the Members section. The cronjob would run each morning and update the Status field based on the member's payments.

This allows you to do things like automatically send e-mails when a person is considered "overdue".

The cronjob would need settings like how many days until the member is considered overdue or inactive.

[elplatt]

You can achieve this by using the functionality in the member and payment
modules:

If you call payment_accounts(["cid" => 1]) it will return an array of this
sort:
[
"cid" => [
"amount" => 4237
, "code" => "USD"
]
]

Which corresponds to a balance owed of $42.37. If it's greater than 0, you
know the member owes. It could be handy to add a payment_has_balance()
function to do that automatically. The member module has functions that
will tell you whether the member has an active membership plan. (See the
code that generates the member table's "plan" column).

-Ed

On Mon, Apr 21, 2014 at 12:17 PM, Paul Brown notifications@github.comwrote:

I've been looking more closely at Seltzer. It looks like this request
would also involve implementing a Status field (Active/Inactive/Overdue) in
the Members section. The cronjob would run each morning and update the
Status field based on the member's payments.

This allows you to do things like automatically send e-mails when a person
is considered "overdue".

The cronjob would need settings like how many days until the member is
considered overdue or inactive.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/316#issuecomment-40948220
.

Edward L. Platt
http://elplatt.com
http://civic.mit.edu/users/elplatt
http://i3detroit.com
@elplatt http://twitter.com/elplatt

[pawl]

The purpose of the status field would be to prevent the cronjob from doing the same thing over and over. Once the user goes Overdue, that's the only time we ever trigger the overdue e-mail. Once they go Inactive, that's the only time we trigger the badge deactivation.

[elplatt]

Are you concerned about the performance of running payment_balance() for
each user ever time the cron job runs? My concern is database
normalization. I'd rather not have the same data in two places if we can
help it.

On Mon, Apr 21, 2014 at 12:30 PM, Paul Brown notifications@github.comwrote:

The purpose of the status field would be to prevent the cronjob from doing
the same thing over and over. Once the user goes Overdue, that's the only
time we ever trigger the overdue e-mail. Once they go Inactive, that's the
only time we trigger the badge deactivation.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/316#issuecomment-40949518
.

Edward L. Platt
http://elplatt.com
http://civic.mit.edu/users/elplatt
http://i3detroit.com
@elplatt http://twitter.com/elplatt

[pawl]

Getting the payment balance only shows you whether they are overdue at that time. It doesn't show what actions were taken in the past.

So, it looks like the current functionality will send emails to everyone with a positive balance when you press "Send Billing Emails". If this was automated, it needs to know not to spam the same people every day. The cronjob would know it already sent an e-mail to that person because their status is now "Overdue".

Just running the calculations everyday without changing the status would be a problem if the server goes down. It needs to know it still needs to process everything it missed while the server was down. All the cronjob would need to do is find things which need their status changed, and do the processing like normal.

[elplatt]

I see, you're accounting for the case where every member's billing cycle
might begin on a different day?

Currently the billing module assumes billing cycles begin on the 1st. So
it only makes sense to deactivate people once per month. Pro-rating is
built in, so you can still add people on any given day though.

I'd love to see the billing module extended to allow arbitrary billing
cycles. That's probably a hefty project though.

-Ed

On Mon, Apr 21, 2014 at 1:09 PM, Paul Brown notifications@github.comwrote:

Getting the payment balance only shows you whether they are overdue at
that time. It doesn't show what action were taken in the past.

So, it looks like the current functionality will send emails to everyone
with a positive balance when you press "Send Billing Emails". If this was
automated, it needs to know not to spam the same people every day. The
cronjob would know it already sent an e-mail to that person because their
status is now "Overdue".

Just running the calculations everyday without changing the status would
be a problem if the server goes down. It needs to know it still needs to
process everything it missed while the server was down. All the cronjob
would need to do is find things which need their status changed, and do the
processing like normal.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/316#issuecomment-40953325
.

Edward L. Platt
http://elplatt.com
http://civic.mit.edu/users/elplatt
http://i3detroit.com
@elplatt http://twitter.com/elplatt

[ramgarden]

I would also like to add a few web service REST endpoints to Seltzer. Any good places to stick those in already? I was imagining something like http://yourserver.com/crm/GetKeyWhiteList.php?allinfo=true&f=JSON that would be called from the door lock computer each day at 1 am or something to update its local whitelist.
That would do the queries required to find a list of all the members who have not lapsed on payments then grab all of their key serial numbers and return it as a JSON string (f = format could also be XML,CSV or similar) that could then be parsed and saved on the door lock computer as a whitelist. Then when people scan their RFID it could check it against the whitelist and throw the door lock or not.

[elplatt]

Yes! REST endpoints are something I've been thinking a lot about. I'm
currently prototyping a REST API that could bridge the gap between Seltzer,
future development, and other systems.

On Fri, Feb 6, 2015 at 11:32 AM, Josh P notifications@github.com wrote:

I would also like to add a few web service REST endpoints to Seltzer. Any
good places to stick those in already? I was imagining something like
http://yourserver.com/crm/GetKeyWhiteList.php?allinfo=true&f=JSON that
would be called from the door lock computer each day at 1 am or something
to update its local whitelist.
That would do the queries required to find a list of all the members who
have not lapsed on payments then grab all of their key serial numbers and
return it as a JSON string (f = format could also be XML,CSV or similar)
that could then be parsed and saved on the door lock computer as a
whitelist. Then when people scan their RFID it could check it against the
whitelist and throw the door lock or not.

—
Reply to this email directly or view it on GitHub
#316 (comment).

Edward L. Platt
http://elplatt.com
http://civic.mit.edu/users/elplatt
http://i3detroit.com
@elplatt http://twitter.com/elplatt

This electronic mail message was sent from my desktop personal computer.
Please forgive any long-winded, overly-prosaic ramblings.

[ramgarden]

Should we create a new thread in the issues tracker for REST endpoints /
features instead of putting all the discussion here on the cron
thread/issue?

On Fri, Feb 6, 2015 at 1:09 PM, Edward L Platt notifications@github.com
wrote:

Yes! REST endpoints are something I've been thinking a lot about. I'm
currently prototyping a REST API that could bridge the gap between Seltzer,
future development, and other systems.

On Fri, Feb 6, 2015 at 11:32 AM, Josh P notifications@github.com wrote:

I would also like to add a few web service REST endpoints to Seltzer. Any
good places to stick those in already? I was imagining something like
http://yourserver.com/crm/GetKeyWhiteList.php?allinfo=true&f=JSON that
would be called from the door lock computer each day at 1 am or something
to update its local whitelist.
That would do the queries required to find a list of all the members who
have not lapsed on payments then grab all of their key serial numbers and
return it as a JSON string (f = format could also be XML,CSV or similar)
that could then be parsed and saved on the door lock computer as a
whitelist. Then when people scan their RFID it could check it against the
whitelist and throw the door lock or not.

—
Reply to this email directly or view it on GitHub
#316 (comment).

Edward L. Platt
http://elplatt.com
http://civic.mit.edu/users/elplatt
http://i3detroit.com
@elplatt http://twitter.com/elplatt

This electronic mail message was sent from my desktop personal computer.
Please forgive any long-winded, overly-prosaic ramblings.

—
Reply to this email directly or view it on GitHub
#316 (comment).

[elplatt]

Sure. I think a broader discussion needs to happen first, but it doesn't
hurt to create a stub. This conversation is just getting started on the
cooperative software mailing group:
https://groups.google.com/forum/#!forum/coop-soft

On Fri, Feb 6, 2015 at 1:37 PM, Josh P notifications@github.com wrote:

Should we create a new thread in the issues tracker for REST endpoints /
features instead of putting all the discussion here on the cron
thread/issue?

On Fri, Feb 6, 2015 at 1:09 PM, Edward L Platt notifications@github.com
wrote:

Yes! REST endpoints are something I've been thinking a lot about. I'm
currently prototyping a REST API that could bridge the gap between
Seltzer,
future development, and other systems.

On Fri, Feb 6, 2015 at 11:32 AM, Josh P notifications@github.com
wrote:

I would also like to add a few web service REST endpoints to Seltzer.
Any
good places to stick those in already? I was imagining something like
http://yourserver.com/crm/GetKeyWhiteList.php?allinfo=true&f=JSON that
would be called from the door lock computer each day at 1 am or
something
to update its local whitelist.
That would do the queries required to find a list of all the members
who
have not lapsed on payments then grab all of their key serial numbers
and
return it as a JSON string (f = format could also be XML,CSV or
similar)
that could then be parsed and saved on the door lock computer as a
whitelist. Then when people scan their RFID it could check it against
the
whitelist and throw the door lock or not.

—
Reply to this email directly or view it on GitHub
#316 (comment).

Edward L. Platt
http://elplatt.com
http://civic.mit.edu/users/elplatt
http://i3detroit.com
@elplatt http://twitter.com/elplatt

This electronic mail message was sent from my desktop personal computer.
Please forgive any long-winded, overly-prosaic ramblings.

—
Reply to this email directly or view it on GitHub
#316 (comment).

—
Reply to this email directly or view it on GitHub
#316 (comment).

Edward L. Platt
http://elplatt.com
http://civic.mit.edu/users/elplatt
http://i3detroit.com
@elplatt http://twitter.com/elplatt

This electronic mail message was sent from my desktop personal computer.
Please forgive any long-winded, overly-prosaic ramblings.