Common Modifications

[brian]

By "complicates the end-users experience" you mean by adding an extra page for example during signup?

Okay, we are completely open to suggestions here, what I posed was the only option I came up with. What you proposed is a sort of "plugin" idea which I think can work. There would be two parts to each plugin action in this case...the PHP form processing, and the actual form elements which would of course need to match. This would mean the "plugin" would have two parts (I'm quoting plugin since it isn't quite a true plugin, but sorta is).

The second part of the question is about what forms people what to modify and how they want to modify them which is a very open ended question. In US5, we have already made things a bit more flexible by separating it into more of a front end and back end experience in the hopes to make things a little easier to manage and customize. The front end forms like login.php and join.php would obviously be designed to match the look and feel of the users main project...the backend, in my mind, is obviously far more complicated and I would expect there is less desire to modify it.

Are you interested in previewing what US5 is looking like at the moment (per my other post about whether people are interested in that or not)?

[plb]

Sure - I'd like to see where you're going with it for US5.

I was about to put together a "proof-of-concept" script to quick-and-dirty implement my idea, but maybe I'll wait and see...

Yes, it was the need for a 2-page process for end-users during signup that I was referring to.

[brian]

Ok, I agree that multi-page signup would be a more tedious approach.

I will need to make a few changes to US5 to make it friendly for sharing...it won't have an installer and will likely just be a DB dump with some things cleaned out along with a zip of the files. Alternatively, I could just setup a demo site like @mudmin does for the main release and then you can just take a look there to see it.

Up to you I guess.

[plb]

I'm just as happy with a couple PHP scripts (join.php and anything it depends on that has been changed) attached to an email. My email is the first 2 letters of my username on this forum followed by my last name (found at http://userspice.org/forums/topic/hi-my-...#post-2292) at gmail.com.

I'm happy to see a demo or a DB dump if that's what you prefer, but I'm looking more at implementation details so the code is fine for me.

[brian]

Okay, let me see about putting something together.

[plb]

Any possibility of renaming "permissions" to "groups"? Minor point ("a rose by any other name...") but it is a pretty standard concept which has been nicely implemented within US but named something that at least I have never seen before... It might help adoption by other developers if they came and saw that users AND GROUPS were automatically implemented if they chose this platform...

[plb]

Any possibility of implementing nested permissions (or "groups" if my previous suggestion is implemented)? I was just presented with the next project I will probably be using US for, but it has a complicated set of authorizations with teams within departments within divisions within the company as a whole and then team leaders often work together and need certain pages accessible to them, same for department heads, etc. If it is a flat permissions/groups setup then it is an admin nightmare to keep it updated when people come/go/change-teams/etc. But if we had the capability of a *group* being a member of another *group* (probably limiting nesting to N levels) then it would become much more do-able.

[brian]

I like the Groups idea personally. I can see a front end implementation not being a problem, back end of course, permissions or perms is used throughout the code so that would be more difficult.

Many, including myself, first get the impression that permissions are levels, like what you might find on a forum where as you go "up" you get more and more control. Perhaps it would have been more clear if Administrator were permission id 1 and Users were permission id 2. Do you feel this confusion exists? Would it be enough to change to Groups in the admin panel and the documentation?

Again, I personally like it, and it would have little burden for implementation.

[brian]

So, the first level of implementation could be only one level deep, and I see it as being an alias for a set of permissions. So you assign a user to the "Designer" group, and they automatically get "Read" "Edit" or whatever else is a part of that Group. I'm still having trouble thinking about how that would be implemented though. Again, I like the idea, but this definitely has a bit more implementation burden to it.

[mudmin]

Right. I totally agree. Groups is the better term. That all goes back to legacy. I think it would be hard and would break things unnecessarily to change function names, but we can definitely be more descriptive. When you tie that in with the fact that we're giving less and less reasons to modify core code... I think that would work great.