Abandoned project? Anyone interested in collaborating on a fork?

[mwalsher]

It looks like @inossidabile has been inactive for quite some time. Are there plans to continue development of Protector?

If not, are there any maintainers that would be interested in collaborating on a fork? There are a few issues with Rails 4.1+ that I'd love to see resolved. I'd be happy to help contribute of course.

[lessless]

I think this a pretty important piece of software and hope anyone will pick it up

[toxix]

👍
Not sure if I can be helpful. If just done some changes to the new prepend syntax/logic. That seems more readable to me. But didn't solve the issues I had with rails 4.2 #60 . So what are your issues with 4.2?

[CyborgMaster]

I don't think @inossidabile is completely inactive. His GitHub profile shows commits as recent as two days ago. However, it is true that he seems to have chosen to ignore protector (either too busy, lost interest, whatever. I can't judge; life happens). I would prefer to get @inossidabile's permission before officially forking his gem, but if that's the way things go, I wouldn't mind being involved.

We use protector extensively in production, along with its integrations with CanCan and InheritedResources. It has needed a few upgrades for our use and so I've made a few additions (see pull requests #64 #65 #66 & #67). So I guess I'm kind of already maintaining my own fork (all the pull requests are combined into a branch on my fork called cyborg-fixes).

@inossidabile, do you have any input?

[inossidabile]

That's true. I will unlikely support it reasonably well in any predictable future (read never). I can put the desired redirect info to the README. You don't really need permissions to do such things but thanks for asking. I'm glad it's useful to you and I'm glad there's someone to keep evolving the idea. If you need any other non-time-consuming things - feel free to ask.

My advise is that you would create an organization since there were at least few commiters that probably aren't active only because I lost my belief in OSS in its previous form. I'm confident they'd like to be involved as well. I'd also like to be a part of that organization. Not an active one but more for researching purpose (I still like the concept and I have ideas how to improve it).

[CyborgMaster]

@inossidabile, thanks for your input and permission. It's much appreciated.

Would anyone else like to be in charge of spearheading setting up the GitHub organization and repo? I would be happy to do it, I just haven't done it before and don't have the time at the moment. If no one else would like to, I'll probably get around to it in the next few months.

When we do get it set up, @inossidabile, it would be great if we could then get the rights to push to RubyGems as well so we can maintain the same gem name.

[inossidabile]

Yes, certainly.

[akshah123]

@CyborgMaster I have setup an org in github called protector-ruby as protector is already taken by a user.

I can invite you to it if you want to bring the project over there.

[CyborgMaster]

Actually, we have gone a different direction at our company. We unified our model level permissions and field level permissions into the CanCanCan gem. It used to only provide model/action level, and we submitted a few large PR's that went into the 3.0 branch that handle field level permissions. We've found that having it all in one place has been highly beneficial and have removed protector in favor of CanCan.

If anyone would like my PR's / fixes on protector merged into a community version of the gem, I would be happy to submit them.

[akshah123]

@CyborgMaster interesting. Do you know when 3.0 is expected to become GA? Also, how are you doing model level authorization there?

[CyborgMaster]

No, I wish I had better visibility into the release schedule, but I believe, like many community maintained project, it's a little ad-hoc.

CanCan pre 3.0 only does model / action level authorization using rules like can [:read, :update], Client. If you are asking about authorization from within each model file, then the answer is we've moved to centralized authorization rules in an Ability class, as that fit our domain better.

[hidr0]

@CyborgMaster Can you please give a little inside on how you managed to pivot?

Let's say that we have a user, manager and admin. The object they should read is a Book. Which all have these read rights:

user -> name, pages
manager -> name, pages, author
admin -> id, name, pages, author, UUID

What we are doing with protector is:

Book.restrict(user).first.uuid and we know that we will get nil if we do not have access to that field.

We are thinking of ways to go out of protector as it is not maintained and this falls only on us. We want to understand how and why the community has moved on and nobody picked up the pieces to maintain it.