Adding user roles and even document types

(Prussiap) #1

I just started exploring this Rails CMS tool a few days ago and am considering using this app for a non profit 3D printing venture I have as well as my personal consulting site. For that project I’ll have community specific discussions (forum), wiki content that can be modified by certain members and potentially collaborative blog articles. In addition, a teacher or other admin would have the ability to add new users or upgrade registered users and maybe assign users to content.

For this type of project to work my guess is that I would need to be able to create and assign user roles like with the built in devise. I would probably also need to have different document roles say for wiki and blog. Aka somebody can create a wiki article and allow others to modify (local community or full site), or a blog article can be edited, published and/or owned.

I would normally use devise and somehow add user roles but it looks like
push_type has basic admin and devise usage. I’m a bit lost on how to either add my specific user roles or for the site through Push_type to be able to add user roles into the existing user system with minimal breakage and hassle.

I’m a bit lost on the the wiki node aspects too. Assigning wiki pages users, and edit groups or something like that seems to be the way to go. That way we could have project specific pages for wiki and maybe even knowledge tree (arduino-> coding -> iot -> home automation -> etcc) all of which can have tags and possibly have associated blog articles and forum communities in the long run. For something like this a user say with an editor role can edit/modify everything while a user with a view_ role can see wiki articles and blog but change nothing.

I’m guessing i would need to do this the rails way but thoughts and ideas on how to work within the pushtype framework and existing system or how to begin has me lost for words and code.


(Aaron Russell) #2

Hi @prussiap thanks for explaining this.

As it stands, PushType has no concept of user authorisation. A user is a user, and can manage all node types without restriction. User authorisation will be built in to PushType in the future - it’s long been on the radar but I’ve not yet spent time truly understanding the problem and considering how best to solve it. So, it is really useful hearing about your use case, but right now there is no built in solution I’m afraid.

If you wanted to completely replace PushType’s built in user model with your own user class and devise/authentication then that’s relatively trivial. Read here and here for pointers. That doesn’t really help much with the user roles aspect, but might give you some flexibility to do things the way you’d usually approach it.

Alternatively, here’s a little known secret: you can add custom fields to users just like you can with nodes, but it’s a little less convenient. Try something like this in an initializer, which should allow you to select a role on a user-by-user basis. You’d need to implement your own authorisation logic somehow.

PushType::User.class_eval do
  field :role, :select, choices: %w( Admin Editor Contributor )

All of the above only gets you so far. Eventually you need to somehow enforce the authorisation logic. I’d suggest something like this:

PushType::AdminController.class_eval do

  # will be called before every action within the admin engine
  before_action :authorize_user!


  def authorize_user!
    # You're own custom authorisation code


None of the above is a solution to your problem, but hopefully points you in the right direction if you fancied hacking around at this. I don’t think you’re gonna get minimal breakage and hassle here. But if you do give it a go, keep me posted. I’m happy to help out if you hit any brick walls. One day PushType will offer a nice clean way to do this, but what that clean way looks like is yet to be discovered so I’m keen to learn about any approaches people take.

(Prussiap) #3

Hi Aaron,
Sorry for delay in response. Health had me put everything on back-burner and take a rather long detour from playing around with PushType and my site.

I haven’t quite tried any of these changes so far but I have setup one of those rails APP customizer with a rails 5 app with devise and roles, HAML and foundation 5 (which you have with Push)… ````

Now one thing I saw in all your notes on devise and making my own roles and this is that User ends up being in devise using a standard Rails model (I think)… so for example User class is this:
class User < ApplicationRecord or say Activerecord::Base

or the pushtype method which is a user node:
class User class User < PushType::Node

Now how that user node destroy how devise works for authentication or authorization? how do you do the normal

devise functions of

other view or controller stuff… I’m not sure how the model changes effect usage if at all.

So on my end I will most likely use the basic Rails 5 app as mentioned above combined with omniauth for multiple providers (Git, FB, Twit, linkedin, maybe another) and the ability to create your own account with email.

I want to combine that with user roles to edit/create/delete for any or all of CMS parts of my site. AKA i’ll have a blog, wiki and forum. I’d like to be able to link info in all directions but will probably create a PushType basic Node that is say: a Page with title, body, images and/or links… the blog/wiki will inherit that to make for specific blog/wiki functions and roles. Discource or threaded will probably handle forum as long as i can use my roles and users on my end.

Finally I’ll add rolify or other Authorize CRUD options for those different pages etc so i can easily edit and mofity the CMS documentation and curate it as needed. All goes well these will be project site for site specific 3d Printer projects and that individual communities will be able to help each other and share info as the groups grow :).

Having said ALL that extraneous crap I could use some help still understanding the changes between the User ::base method or the User node, with relationships, role relationships as well as omniauth/provider options that are noraml Base vs PushType Node and how using either or can or will break things before i jump blindly into this :) again.

Thanks again. hope I didn’t confuse everyone thoroughly with my questions and my own confusion :)

(Aaron Russell) #4

Hi @prussiap - sorry I’ve take a few days to reply to your last post. I hope you’re keeping well?

Right… im not sure how to begin :stuck_out_tongue:

What you’re trying to do is not a feature of PushType yet. It will be in the the future but right now it’s a completely undeveloped area. As such there is no alternative but to roll up your sleeves and dig in to the internals of PushType. I’ll be honest, I think this will be a fair amount of hassle. I can’t tell you exactly what you need to do because I simply don’t know. But if you have specific questions I can try and answer them.

In your post above there’s a bit of confusion about Nodes and Users - I’ll try and clarify:

  • PushType::Node - is the base class for all content types (nodes). This has nothing to do with users. If you create your own users class, don’t inherit from PushType::Node, that’s not what it’s for.
  • PushType::User - is the built in user model. This is not designed to be inherited from, it is just a standalone model for basic user features that come with PushType out of the box. For most simple sites, you just use the built in user model and don’t worry about anything else. To a certain extent you can patch and extend the class to add some extra functionality, but if you really want to customise things you should ignore the built in user model and define your own user model.

If you end up wanting to use your own user model, you are effectively replacing PushType’s built in authentication with your own. In this case follow the two links I mentioned above:

Other than that clarification, I’m not sure how else to help at this point. If you have specific questions then fire them at me and I’ll try and point you in the right direction :slight_smile:

(Aaron Russell) #5

Hey again @prussiap, wanted to reply to your post on github. Thought it best to keep that here rather than on an open issue:

I’d love to help build and improve if i can work on some stuff or there are issues.

Cool. I’d love any help. If you haven’t already, have a skim through the contributing guidelines.

If/since I intend on rewriting some of the devise/omniauth/role related stuff maybe i can merge or do some work there that kills two birds one stone and helps you? thoughts and future directions? I can do it as a plugin, or option.

The whole area of user authorization/roles/permissions is something I want in PushType. In fact I think this is a very important development. However, because of that it’s one I want to get right before it goes in to the product. Up until now I’ve been of the opinion that I would not start this until I begin learning from users how this needs to work and bide my time until I’ve got a very clear idea of how best to approach this.

If you wanted to take the initiative and move this forward I’d be more than happy for you to do so, but for this kind of dev I think it would be right to propose a solution on these forums first - we can discuss it, pull it apart, make sure it’s right, and then turn it in to dev work. There’s no rush with this, like I say I want to get the “design” of the feature right. The best place to start might be to actually just implement it in your app and then explain here what you did, what works well, what less well etc. So we can learn from your experience.

I haven’t dug enough in your code yet but can. Like I said I think as is PT provides a very simple way to have users do some basic CMS and if we could a few fun templates this could compete with square but for people that have technical skill. AKA packaging this with AWS (bitnami), dockerize, DigitalOcean, or my favorite the free heroku setup that gets people quick access and setup.

There is already a Heroku demo repo, which kinda does what you describe. This uses an open source WordPress theme, it’s just meant to show how a simple WordPress-like site with a blog and a few pages can be very easily replicated.

If there are other “one click” deployment mechanisms, like digtal ocean and AWS, then I’d be delighted to see pull requests on the demo repo above that allows deploying the demo to these platforms.

Eventually I’d like to replace the theme in the demo with something that isn’t WordPress… even though there’s nothing wrong with using an open source theme, I’m not sure how cool it is to use a WordPress asset to essentially say “don’t use WordPress”. The Zurb themes are OK as a boilerplate, but not particularly sexy for a demo. Maybe someone could contribute a nice demo theme.

The idea of themes can be taken further. Out of the box, PushType is just a blank slate waiting to be structured how the developer requires. We could use Rails engines to package themes and some basic Node models so you can install a gem that gives you site some basic structure. Eg - a “blog” engine, or a “portfolio” engine. I’d love to see the community experimenting with this kind of thing.

Then for more advanced folks we can build on top of that with Thredded/discource, wiki and blog which are basically default PT, combined with role specific devise admin.

One thing I would say is that PushType’s focus is on being a CMS, and then it gets out of your way. So whilst I love to see PushType being used alongside other platforms such as forums, ecommerce etc, it shouldn’t ever try to recreate that functionality. So these forums can be a great resource for sharing how to integrate PushType with, say, Spree or Thredded. How to share User models between the engines etc.

I need to head out now but if you have any questions about how to get started, ask here or PM me. Cheers.