Click anywhere to close this dialog

Farewell

Great is the art of beginning, but greater is the art of ending
Henry Wadsworth Longfellow

I announce that I cease all development and activity in the programming universe indefinitely. My career has reached the turning point I was not expecting for at least another year, leaving me highly off guard and without laid-out plans for this hobby's continuity. I have begun a 5-year residency program in Neurosurgery which is clearly not compatible, time-wise, with programming.

I gave in all my passion for developing, and you gave me back your loyalty and trust, even when I did not deserve that much. Now it is the time for payback. I release all my present and past work as Open Source software, in the hope some talented developer will continue maintaining and expanding my vision of a modern, sleek forum software. The intrinsic flexibility of MyBB is the true hidden gem of an otherwise outdated codebase; I do hope the project can continue and be updated complying to the latest coding standards.

I hereby thank Euan, kawaii, andrewjs18, Ben, Matt, Omar G., effone, Eric J., Devilshakerz, Wildcard, JordanMussi and all the other team members I have had the opportunity to work with when I was a MyBB team member. I thank Tomm M, my mentor, who inspired me to pick up coding with his piece-of-art plugins. And finally, I thank all of you MyBBoost subscribers who have helped me getting through my toughest university years economically.

Yours sincerely, Filippo

Logs page and refunds not working

8 Apr 2020 Edited
#1
This issue is marked as solved
Internal SQL error is displayed when opening
admin/index.php?module=config-bankpipe&action=logs

Sending a refund just displays ! in the HTTP status in sandbox API call history.

Refund amount should have a option lock at the base price, so if the forum gets compromised they wouldn't refund thousands.

Does refunding not auto-accept a PayPal claim?

Re-activating a subscription does not change usergroup.

Closing the Coinbase window without doing anything sets the transaction to pending instead of cancelling.

I need a mode where additional usergroups are never modified.

Is there a way to save the entire IPN data received from PayPal, atleast the email and transaction ID, ideally display it in logs? The memo on PayPal should contain the account username and UID.
What is the best way to see which forum account was upgraded from which payment?
For example when a claim is opened on PayPal I need the upgraded account banned instantly. There should also be a blacklist for emails.
Or when I ban a forum account, how do I instantly find the payment related to the account?

There should be info if a payment is to PayPal or Coinbase.

Add a way to delete entries.

Need a way to not display bankpipe anywhere.
Shade 8 Apr 2020
#2
Next time please open a thread for each suggestion or issue, so I can keep track of everything separately.

Internal SQL error is displayed when opening
admin/index.php?module=config-bankpipe&action=logs
Kalju (8 Apr 2020)
This is probably related to your peculiar MySQL configuration. Can you please share the error displayed? ONLY_FULL_GROUP_BY is known to interfere with plenty of plugins and I suggest you to disable it. This doesn't mean I'm gonna apply a fix for your issue, but it greatly simplifies things not only for my plugins.

Sending a refund just displays ! in the HTTP status in sandbox API call history.

Refund amount should have a option lock at the base price, so if the forum gets compromised they wouldn't refund thousands.

The memo on PayPal should contain the account username and UID.
Kalju (8 Apr 2020)
Can you elaborate more on these? Can't understand.

Does refunding not auto-accept a PayPal claim?
Kalju (8 Apr 2020)
This might be a nice addition, and in the docs there is the CUSTOMER.DISPUTE.CREATED webhook which might be useful. I will see what I can do.

Re-activating a subscription does not change usergroup.
Kalju (8 Apr 2020)
This is a known issue which will be fixed in a future update. The current method to deal with this is either to move the account manually or to manually subscribe the user yet again.

Closing the Coinbase window without doing anything sets the transaction to pending instead of cancelling.
Kalju (8 Apr 2020)
This is intended behavior. All Coinbase payments are set to "pending" as soon as you open the window, as even legit payment windows are closed manually by the user. Coinbase usually sends failure notifications after 1 hour if a payment is not detected, and the user is informed accordingly.

I need a mode where additional usergroups are never modified.
Kalju (8 Apr 2020)
There is already an option in each subscription which lets you choose between primary or additional groups when upgrading an user.

Is there a way to save the entire IPN data received from PayPal, atleast the email and transaction ID, ideally display it in logs?
Kalju (8 Apr 2020)
BankPipe doesn't work with IPN. Email and transaction ID are logged already for each payment: the email is not displayed at the moment, I can add this.

What is the best way to see which forum account was upgraded from which payment? Or when I ban a forum account, how do I instantly find the payment related to the account?
Kalju (8 Apr 2020)
You can see a payment's info in your ACP by either:
1) going into BankPipe > Payment history > Edit purchase;
2) going into BankPipe > Logs > Click on a log's "associated items" link

If you want to see it in each profile, you must add the {$memprofile['purchases']} variable to your member_profile template. Only admins will see the purchase list. Only transaction IDs and the full amount are displayed at the moment but in future updates you will be able to quickly jump to your ACP and see the details.

There should also be a blacklist for emails.
Kalju (8 Apr 2020)
I don't think this is feasible. If PayPal lets you block emails, you should do so on their side. There is no way BankPipe can blacklist PayPal accounts.

There should be info if a payment is to PayPal or Coinbase.
Kalju (8 Apr 2020)
This is a known improvement which has already been added to the upcoming version. As of beta 10, you can discern between PayPal and Coinbase payments by looking at the "fee" value: if it's 0, it's a Coinbase payment. If it's more than 0, it's a PayPal payment.

Add a way to delete entries.
Kalju (8 Apr 2020)
You can delete logs. You cannot delete payments at the moment. I am not sure if allowing to delete payment records is a good idea, I will think about it.

Need a way to not display bankpipe anywhere.
Kalju (8 Apr 2020)
You have full control over the link to BankPipe's subscriptions page; if you want to restrict access to a particular usergroup, you can do so from the settings.
Kalju 8 Apr 2020 Edited
#3
How do I display the error for logs?

Sending refunds doesn't work, where do I display the error?

After upgrading, no matter the settings, it moves registered group to additional groups. This also happens when revoking subscriptions even when I remove all additional groups beforehand.

I found that one of the ways to resolve a transaction to user is to search for the sale ID in a sql query.

Deleting sandbox, refunded/revoked and permanently banned accounts entries for example.

The bankpipe.php and env=bankpipe url should be changeable.
Shade 8 Apr 2020
#4
Please open a thread for each issue next time, as I will reply just to the first issue and edit your post accordingly. Thank you.

How do I display the error for logs?
Kalju (8 Apr 2020)
Can't understand this. Please elaborate.

Sending refunds doesn't work, where do I display the error?
Kalju (8 Apr 2020)
Refunds are correctly applied in all my tests, so please check your error.log file for any issue which may be caused by your peculiar MySQL configuration.

After upgrading, no matter the settings, it moves registered group to additional groups. This also happens when revoking subscriptions even when I remove all additional groups beforehand.
Kalju (8 Apr 2020)
This is intended behavior at the moment. BankPipe backups the old usergroup in the additional groups field. I can add a setting to let the previous usergroup slip away.

I found that one of the ways to resolve a transaction to user is to search for the sale ID in a sql query.

Deleting sandbox, refunded/revoked and permanently banned accounts entries for example.
Kalju (8 Apr 2020)
So to get this clear, do you want to search for a transaction ID? I can add this even though I would like to hear what's your purpose.

The bankpipe.php and env=bankpipe url should be changeable.
Kalju (8 Apr 2020)
You can use Rewrite rules to shape your URLs as you want (example guide). By design, BankPipe works with those links and they won't be changed.
Kalju 9 Apr 2020
#5
I understand, I'm going to make a separate thread per problem, but you want me to separate these problems to separate threads?

Logs page:

SQL Error:
1055 - Expression #1 of SELECT list is not in GROUP BY clause and contains nonaggregated column 'mybb.l.lid' which is not functionally dependent on columns in GROUP BY clause; this is incompatible with sql_mode=only_full_group_by
Query:
SELECT l.*, u.username, u.usergroup, u.displaygroup, u.avatar, GROUP_CONCAT(l.type, '|', l.date ORDER BY l.date DESC) types FROM mybb_bankpipe_log l LEFT JOIN mybb_users u ON (u.uid = l.uid) GROUP BY l.invoice ORDER BY l.date DESC LIMIT 0, 20

Sending a refund by entering a custom amount doesn't work. For example I entered the same amount that would be refunded without filling the field. There is no readable error generated for this, if you know where to see them then let me know.

Backupping previous group should be in the payment log instead of actually setting it in additional groups.

There should be a search in payment history with the sale ID, to find the forum account related to the purchase. With the old plugin I had to ask customers for their transaction ID, to verify which account they purchased on, the uid was set in the memo.
Shade 9 Apr 2020 Edited
#6
For these it's fine like it is.

Disable ONLY_FULL_GROUP_BY mode. It's not necessary, and brings up too many unpredictable verbose errors.

I will double check the refund functionality.

The "previous usergroup" is already stored in each payment, but it's also backup'd in the additionalgroups field. There will be changes to this model since multiple payments do not work well with each other, so I may also add an option to disable this behavior entirely.

I still don't understand why would you need to look for the sale ID. It's not necessary to revise a payment as only successful ones are marked as such. Why would you need to search for the sale ID in the first place?
Kalju 9 Apr 2020
#7
When a claim is opened on PayPal I need to lookup the account.
Shade 9 Apr 2020
#8
Now I get it, thanks. Never had the chance to experience one myself, but I guess they might happen. AFAIK, there should be a webhook for that, so I can automate the process and mark payments as "disputed", but I need to check.