Feature set for 1.0

[apeisa]

What feature set we are aiming for 1.0 release? Also - do we have release date for 1.0 release? I am happy to provide code and testing from here also in February.

Some themes: -Centralized management (seeing clearly all the places where ua is managed) -User group admins (ability to add/edit users within group) -Ability to define "add&edit children" groups, adding possibility for groups "not to edit homepage, but all the others" etc. -More scalable users list (rethinked ProcessUserExtended)

[apeisa]

cc @niklaka @teppokoivula

[niklaka]

I would like to keep the feature set for 1.0 release as small as possible to a) get it out as soon as possible and b) to be able to concentrate on making the core functionality rock solid. This is access control were talking about here after all :).

Also, this seems like something that could benefit from modular thinking. I mean, let's not try to bundle everything in one module (well, two atm) but rather make companion modules or at least optional features where not feasible to make things external from the main modules.

So, based on what I just said, this is how I see your themes (core = this module as it is):

• centralized management
  • useful for most users I'm sure
  • not essential for core, but a good candidate for a companion module
• user group admins
  • noise if you don't need it (most don't?), but a game changer if you do
  • not essential for core, but maybe needs to be built in as an optional feature later on
• "add & edit children"
  • a handy feature
  • not essential for 1.0, but definitely needs to built in as an optional feature later on
• more scalable users list
  • definitely something that needs to be done
  • not essential for 1.0 and would be useful without UserGroups as well --> companion module
  • could still integrate itself into UserGroups by providing a group filter if UserGroups is installed

More themes:

• better ui for managing access when editing a page (no offense; current implementation serves the cause just fine)
  • "access" tab and a view resembling that of template based access control
  • not essential, but nice to have in core - maybe not in 1.0 but soon after
• ui for managing access directly from the page tree
  • bits from centralized view and access tab making things more convenient
  • a companion module, no need to be in core
  • this is actually done already (Teppo will have his word on this in a minute)
  • has some parts useful for "access" tab as well
• module's co-operation with roles
  • role's role (!) needs to be defined
  • maybe could be broken in two: page access and application roles
  • page access handled by UserGroups as it is
  • application roles managed separately (i.e. not in user's edit view)
• view, edit, add children + "page admin" (page-template, page-lock)
  • on top of view/edit there are other things to be considered, maybe even on a page-by-page basis
  • core stuff, but preferably optional to account for the simplest case when only view/edit is needed - later on
• default access (guess where this comes from ;)
  • when defining access for the first time for a page it would be useful to have a default set of group/access-definitions added
  • a variation of this could be to force some definitions everywhere (where access is managed) to make sure some defaults go through the whole site even though it's possible to define things more precisely as well
• and a ton of other things --> we really want to consider carefully what belongs to core, what should be optional and what should be implemented as a whole another module extending the core

Is GitHub a good place to manage this kind of stuff? Maybe Trello is an alternative?

[teppokoivula]

Minute is flexible concept :)

Anyway, I don't have much to add to this list and agree with pretty much everything @niklaka said above, except that I'd consider "access tab" 1.0 feature.

I really wouldn't want to distribute any "finished" version of this module with current UI. It's not what users would expect or what best matches their needs.. and I don't see development of proper access management view as such a huge task that we should leave it out of 1.0. Note: this doesn't mean that the module can't be used, submitted to modules directory etc. already.

First companion module is Page List Permissions, available here: https://github.com/Aldone/PageListPermissions. It provides at least partial answer to our UI needs, but I felt that it shouldn't be bundled with this module. UI is definitely something that may change between individual projects, while core features remain same.

[apeisa]

Great progress guys. I really like the idea of smaller and more flexible building blocks (=modules) working together.

Yeah, public Trello board would be great to manage features and development. You guys want to set it up? I need to test @teppokoivula 's new module now... :)

I think one of the though ones is "co-operation with roles" - have you guys discussed about that? I didn't touch that issue at all when building the PoC module, kind of avoided the whole thing back then...

[apeisa]

Uh, that PageListPermissions is superb!

[niklaka]

Made a Trello board (https://trello.com/b/oOLePLle/pw-usergroups). It's still private but could be made public too. Maybe we should get it up and running first or what do you think? I'm not sure which of your accounts I should've added - tell me if it wasn't the right one =).

I added a list for 1.0, renamed Todo --> Backlog and added some of those things discussed above. Feel free to edit all and everything, you're permissions should allow that.

We certainly have discussed roles and it really is a tough one. See Trello for more thoughts on that.

Hmm, should there be some guidelines on what belongs in GitHub/issues and what in Trello? Don't want to check both if I'm looking something specific... Discussions here, more static stuff (specs are static, right?) in Trello, especially the roadmap part?

[apeisa]

My in use account in trello is anttipeisa1

[apeisa]

@niklaka I think we should discuss features and specs on trello cards, and keep the actual spec on Trello description. Discussion in comments, spec in card description.

GitHub would then be about bugs, code reviews etc. How does this sound?

[niklaka]

That sounds good. So far I've found Trello card comments a bit confusing to follow but then again I haven't really used them but only did a couple of tests. I'm sure that'll work just fine and I'll learn something new in the process as well.

[apeisa]

I moved trello cards back to here. I did go with "upcoming feature" (meaning we have decided which version that will go) and "backlog" (something to be discussed and decided later on). Happy to change those, if current setup doesn't make sense.

I left "more scalable user list" out, since we probably will use ProcessUserExtended for that (or what's your plan @teppokoivula ?).

[niklaka]

OK, I'll ditch that Trello board then.

Our intention was to go with ProcessUserExtended with steroids. I think Teppo actually has some progress with this already but let's see what he's got to say.

[teppokoivula]

@apeisa Well, ProcessUserExtended is the approach I've taken so far. I feel that there's aneed for extended (including, but not limited to, being "more scalable") user management view even with default (template based) access control and that seems like a good starting point for both needs.

UserGroups doesn't strictly speaking require new user list either, many small sites with relatively few users might still benefit from this access control method :)

[apeisa]

I agree. And current solution also helps finding the users, because you can go into single group and find the user from there.

And vice versa: default user list on PW doesn't scale at all, with or without UserGroups.