Database constraints and building an admin area

[Pete Jones]

We are currently looking at building a custom administration area with the basic outlined functionality. Users will be able to login and see their horses, their events and their payments. Admins will be able to login and see all users, horses, events, payments. Data structure below.

Questions

1) Would this make sense to build as a single frontend with different 'admin' levels' rather than customising the backend of PW? Ultimately the PW install will be running a full frontend website (showing Horses for Sale, Events and other misc content) so users will need to login to update content.

2) How does PW handle database relationships? Could this structure be built?

Users
------
ID
Email

Horses - one user can own many horses
-------
ID
UserID
Membership Level (payment)

Events - one horse can enter many events
-------
ID
HorseID
Required Membership Level

Payments
-----
ID
TransactionID

Payment Items - one payment can have many payment items
----
ID
PaymentID
Order Type - Horse Registration/Donation/Event
ItemID - HorseID, DonationID, EventID
Cost
VAT

 

Many thanks

Pete

 

[LostKobrakai]

ProcessWire plainly doesn't use database constraints at all (Foreign key constraints are not available for MyISAM). Those need to be handled in you application logic / by processwire's logic.

[Pete Jones]

OK. So if we were creating this sort of structure in the admin area of PW, could we build it using linked pages/repeaters?

Also, is there any benefit in building the sort of admin functionality as a frontend or as part of the standard admin area?

[LostKobrakai]

Sure, there are just no database backed constraints. The benefit of building a custom frontend is also the biggest drawback: It's custom. In the backend you can harness a lot of already existing functionality, which works if that's how you need to handle things, but might get messy if you need to work against it almost everywhere.

[Pete Jones]

Right, so let's just say we have a members area which holds all of the User/Horse/Payment details and a CMS. Is there a way in which we can have a single point of access for all this? We've been discussing perhaps a Laravel user/horse system and expose some JSON for the website area.

What I don't want to to provide 2 'admin' system to the client. One for users/horses and one for the CMS.

[renobird]

Hey Pete,

What kind of functionality do these subsystems have? I don't see anything  that you couldn't build in the admin. 
On a smaller scale, but somewhat related, I have a help desk system that has some similar relationships.

Users
There are about 20 fields associated with each user

Tickets
Each user can have multiple tickets

Equipment
Each ticket can have multiple pieces of equipment attached.
The equipment may be assigned to the user, or it may not be.

Those sound like they are similar to your User/Horses/Events
Although, I don't have anything that's analogous to the payments

You can build some pretty complex stuff in the admin, but if you have a lot of custom UI requirements, then you might end up fighting against it like LostKobrakai mentioned. I don't know if that gives you anything more to go on other than, "Hey, I've done something *kind of* similar".

[Pete Jones]

Hi Tom,

Thanks for posting. For me, it's about making the admin area nicely maintainable. To that extent we'd need to be able to customise the admin area fairly heavily.

Is your ticketing system something I could take a look at from an admin perspective?

Pete

[renobird]

Sure. I posted some screenshots in this topic.

 

[Pete Jones]

Wow.

Can I ask how you built the data structure? Was this all through processwire and pages?

Did you customise the PW admin area or is this entirely frontend?

Having tried to build a basic proof of concept the data structure it's tough to amek the admin area work sensibly.

 

Pete

[renobird]

Hey Pete,

It's all a combination of Pages and FormBuilder. Although, there's no need to use FB, I was just piggy-backing on some other systems I built. You could do all the same stuff without FB at all.

Short explanation: We have lots of these systems, and there are even multiple Help Desk types, so there would have been hundreds of PW fields. Instead we use FormBuilder for creating the input method, and then send certain parts of the data to a PW page. It probably sounds complicated, but it's really not.

Ultimately everything is a page. The relationships are maintained with Page fields. InputfieldMarkup provides a way to display some of the related data (like the effected equipment list) in whatever format we need. It makes it fairly easy to style it however you'd like.