The prepaid model which I have is as follows:<br><br>1) Customer purchases time credit and can use that credit as required. When purchasing time, only a specific qty of data will be allowed<br>2) Customer purchases data credit
<br><br>Therefore, there are 3 fields that need to be recorded for each user:<br><ul><li>credit_time - amount of time in seconds which was pre-paid<br></li><li>credit_timedata - amount of data in Mb which was part of the pre-paid package
<br></li><li>credit_data - amount of data purchased</li></ul>I will try to catch up with you on IRC.<br><br>PS: For info, the project takes place in the French Territory of Wallis and Futuna, in the pacific. This will be an interesting new location to add to your list of communities
<br><br><br><br><br><br><div><span class="gmail_quote">On 12/11/06, <b class="gmail_sendername">Benoit Grégoire</b> <<a href="mailto:bock@step.polymtl.ca">bock@step.polymtl.ca</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On Sunday 10 December 2006 22:02, Raphael Alla wrote:<br>> Hi,<br>><br>> I am currently planning to use wifidog in a context where users purchase<br>> pre-paid credit, either in time or in data. When they are connected they
<br>> use their credit and then when their credit has expired, they get logged<br>> off.<br>><br>> I am currently writing an Authenticator class, which is relatively<br>> straightforward. The auth/index.php file however does not have the
<br>> capability to check whether the acctUpdate function returns a true value or<br>> not.<br><br>Humm, you're right. While this will probably change in the future, the way to<br>fix this for now is to modify the base Authenticator class to have acctUpdate
<br>return one of the "ACCOUNT_STATUS" constants, and take an additional output<br>parameter which will contain the returned error message (if applicable).<br><br>> All my code is GPL and I am more than happy to contribute the changes back
<br>> to the list once done.<br><br>Excellent, welcome!<br><br>> Some questions:<br>><br>> - what are the rules to submit patches to the list?<br><br>Usually, the way to sent significant patches is as an attachements to a trac
<br>ticket. Note that this is in no way meant to discurrage discussing a patch<br>on the list.<br><br>> - i need additional fields for users. Would it be better to store<br>> those in the user table by altering it or would it be better to create a
<br>> new table that can be used by my extension only. The second option has the<br>> benefits that users can install the extra table only when they require and<br>> maintains compatibility with the code coming from cvs
<br><br>It really depends on what the fields are and do. There is a sizeable amount<br>of design on how connections are to be limited (time, bandwith) which is a<br>completely generic problem. Depending on the fields the answer will be one
<br>or more of either:<br>-Extend the connections table<br>-Extend the users table<br>-Create a table specifically for your authenticator, linked to the users<br>table<br>-Use a Key-Value-Pair style system.<br><br>Try to catch me on IRC, or send your proposed fields here for discussion.
<br>--<br>Benoit Grégoire<br>Technologies Coeus inc.<br><br><br>_______________________________________________<br>WiFiDog mailing list<br><a href="mailto:WiFiDog@listes.ilesansfil.org">WiFiDog@listes.ilesansfil.org</a><br>
<a href="http://listes.ilesansfil.org/cgi-bin/mailman/listinfo/wifidog">http://listes.ilesansfil.org/cgi-bin/mailman/listinfo/wifidog</a><br><br><br></blockquote></div><br><br clear="all"><br>-- <br>Raphael Alla<br>Mitija Australia
<br>+61 4 15 678 576<br><a href="http://www.mitija.com">http://www.mitija.com</a>