Best method for storing payment transactions

[NikNak]

EDIT:  The LimitPageTable module seems to offer the ability to remove the trash icon from PageTable. 

I'd still be interested if anyone thinks this approach could be improved though

Hi

I'm looking into using Stripe to take membership payments for a society. ie - once per year, so not lots of transactions.

The process all works fine, but I am not sure of the best way to structure storing the transactions records in PW.

My initial thought was to create a pageTable for payments and add this to the $user template. So each time a payment is made, a new page is created (in a payments folder under admin section) that logs the transaction, and this is then added to the pageTable list in the $user admin page via the API. This way, all transactions for the user are easily visible to the admin. All adjustments to these records would need to be by the API and not by manual editing. I like the idea of each transaction being a page.

The trouble with this method, is that I do not want the administrators to be able to remove these entries from the pageTable, as they can currently via the trash icon. I can set the actual transaction page itself to be un-editable - but this doesn't stop its removal from a pageTable.

If you set the visibility of the pageTable field so it is un-editable (locked), it then only shows you a list of page id's (ie, no pageTable layout) - so the listing becomes meaningless to the administrator.

So my question is....  Does this approach seem to make most sense (if I can remove the trash icons in the pageTable listing) - or should I try a different approach for storing this data. It needs to make life easy for the administrators of the site.

Many thanks 

Nik

 

Edited December 14, 2016 by NikNak

[Robin S]

I think maybe you are already onto this idea (saw your posts in another thread), but you could use RuntimeMarkup to create a non-editable table view in Page Edit showing the payments.

[NikNak]

Thanks Robin - I was indeed considering this. The RuntimeMarkup module doesn't scope the current $user being edited though - it only works on normal pages. So I think this counts this option out.  I didn't realise that $page wouldn't return the current user being edited.

Kind regards

Nik

[kongondo]

Nik,

Maybe I am missing the point but my example code above is meant to show that ALL ProcessWire variables are available to you. They will just have to be called as if they were in  function, i.e. user wire(). You are not limited to page(s) only . However, for syntactic convenience, $pages and $page are available without resorting to wire('page'); I don't understand what the current user being edited means. However, to get the current user, you would do, for example...

if(wire('user')->name=='santa') return "Dude, where's my stuff?";
else {
// do something else
}

Instead of typing all that code in there, you can user wireRenderFile() and write all your code and logic in an external php file. 

[NikNak]

Hi again

If you are editing a users page at a url like "/admin/access/users/edit/?id=3718" I was trying to access the id 3718, so I could find other pages related to this id. I wasn't trying to get the current $user

Sorry for not being clear.

Kind regards

Nik

 

 

[kongondo]

In that case, the following code should work....

$out = '';
$u = wire('users')->get(3718);
$related = $pages->find('your-relation-here');
foreach ($related as $r) {
  $out .= $r->title;
}
return $out;

[NikNak]

Thanks - but if you want to get the id without hard coding it.  In other scenarios you use the $page->id which returns the id of the current page being edited.

How do you return the id of the current user being edited?  

Kind regards

Nik

 

[kongondo]

1. Add the field to your user template
2. Do what you want ...e.g.

$process = wire('process'); 
$u = $process->getPage();// this is an object
$id = $u->id;
return $id;// will return 40 for guest, 41 for superuser, etc...
//return $process->className();// would return ProcessUser. Useful to know if you are using the field elsewhere and want to do different things based on context
// return $u->email;// etc...

Edit:

But that only works when you are actually editing that page, of course

[NikNak]

Awesome - thank you so much.   That is exactly what I needed. 

Kind regards

Nik