Splitting off part of UCP

[mrgoldy]

This is a discussion in regards to the User Control Panel.
This will have to be done once the control panels (in general) have been moved.
However, the discussion can already be started, so here we are.

Currently there are quite a few modes that belong to the UCP, which do not really belong there.
There are quite a few exceptions coded to make these modes work within the UCP, and prevents a regular 'straight-forward' approach.
The modes in question are:

• activate
• resend_activation
• reset_password
• forgot_password
• register
• confirm
• login_link
• login
• logout
• terms
• privacy
• permissions_switch
• permissions_restore
• delete_cookies

The problems with these modes are the following:
- Should not be displayed in the UCP menu
All these modes are more 'functions', rather than modules within UCP. And all these modes are not listed within the UCP menu's.
- The UCP Indicator is incorrect
Within the (currently ucp.php) control panel there is an indicator to indicate that "we are inside the UCP", which can be used by style authors. But as stated above, that is not correct. These are not listed in the UCP menu's, nor do the pages for these modes show the actual control panel.
- Not logged in
For all 'common' modes within the user control panel, there is a base requirement that the user is a registered user and logged in. However, for the modes listed above, for a lot of them, this is not a requirement. Or better yet, the user has to be logged out instead.
- Possibly more, but can't remember them right now.

Anyways, the point is, that it prevents a clean approach for the ucp, as exception upon exception, if statement upon if statement has to be created to filter out these modes and allow them to be accessed.

It would make a lot more sense in my eyes, to make these modes part of a separate 'directory', not control panel as that's not fitting. I would suggest adding all of them to the /account/ route. And then we can handle each mode invididually if necessary and have a clean way to handle the UCP.

[david63]

Sounds reasonable to me.

I would suggest adding all of them to the /account/ route.

Not sure what that actually is but to me "account" is too generic - perhaps "user_account" or "user_tools" would be more intuitive.

[mrgoldy]

To clarify, the ucp will have the /user route prefix, so for example yourforum.com/user/index, etc
And I meant to use /account as route prefix for these, so for example yourforum.com/account/delete_cookies, etc

[david63]

To clarify, the ucp will have the /user route prefix, so for example yourforum.com/user/index, etc
And I meant to use /account as route prefix for these, so for example yourforum.com/account/delete_cookies, etc

I would take "account" to mean the whole board account. But if you are dealing with a user then, to me anyway, it would be clearer if it was yourforum.com/user_account/delete_cookies as there will, inevitably, be some items where yourforum.com/account/some_action would be valid.

If something is as user/moderator/admin/board level then to me it makes more sense to identify which "role" is being used.

[EA117]

Agree wholly with the reasons for splitting these functions into a module separate from "user".

If I could create as many as I want and name them anything, maybe slightly more granular?

"registration": // no confirmed account exists yet

• terms
• privacy
• register
• activate
• resend_activation

"account": // actions for an existing account which are not UCP modes

• reset_password
• forgot_password
• login_link
• login
• logout

"session": // actions which aren't "about your account"

• delete_cookies
• confirm
• permissions_switch
• permissions_restore

Just to try and avoid perpetuating any unnecessary inertia of "ugh, guess I'll just to put new thing X under 'account' even though it doesn't really belong" in the future. (Presuming that's how we arrived in the current UCP situation.) But maybe the primary goal here is "get these functions out of /user", more than it's important that "all the modes of /account should logically belong there." In which case, I understand. 😁

"account" seems better than "user_account" in my mind, especially if this route can end up being in the URL. Having "user_" doesn't make me logically distinct "oh, that kind of phpBB account" in any way that "account" didn't already achieve.

[Senky]

...
"registration": // no confirmed account exists yet

• terms
• privacy

...

This should be on a top level, it needs to be available to everyone everywhere, not just during the registration process. So <root>/terms and <root>/privacy makes the best sense, imo.

[mrgoldy]

Oh, I like the idea of splitting them up into multiple parts.
I was still in the mind set of 'get them out of there, i don't care where'.

About Terms and Privacy needing to be available everywhere. Yes that's true, and it's not like they are no longer available afterwards. And you can explain it as 'these are the policies you agreed upon registration'. Moreover, they can not really be 'top level', as they do need a prefix and location within /phpbb/ namespace. See this tracker ticket: Move front facing files to controllers

But splitting everything up is a good solution nonetheless.
And it allows us to set up a few default paths and namespace structures where we can later on more easily can expand upon.

So, I would go for something like this:
registration
- register
- confirm (the confirm email adress page)
- activate
- resend_activation (possibly make it just 'resend')
board or policies
- terms
- privacy
account
- delete_cookies
- logout
- login
- login_link
password
- reset_password (possibly make it just 'reset')
- forgot_password (possibly make it just 'forgot')
permissions
- switch_permissions (possibly make it just 'switch')
- restore_permissions (possibly make it just 'restore')

This does however bring forth an other interersting dilemma. For example /passwords/ is already namespace within phpbb, so should front-end controllers always be in a separate namespace or can they be inside existing ones?

[EA117]

board or policies
- terms
- privacy

Understood that it must have a name/prefix. "policies" does seem like it could be long-term appropriate, with maybe other board-wide policies (COPPA, cookies) somehow ending up with a front-end page in here at some point too.

"registration" had just seemed appropriate at least for "terms", because that UCP page actually has an "I agree / I do not agree" interrogation which only makes sense during registration. Making it available for viewing even while not in registration (and a "you already agreed" rather than a new "I agree / I do not agree" decision) sounds plenty appropriate though.

- confirm (the confirm email adress page)

I was probably looking at the wrong thing then, because I took from the current ucp.php that mode=confirm was an invocation of captcha. Which is why "session" had seemed appropriate, since you're not proving anything "about your account", but rather that you didn't let your robot take over at the keyboard.

account
- delete_cookies

Blowing away cookies didn't "feel like an account thing", since it neither uses any information out of your account, nor changes any information in your account. But without any separate "just about your session" category, its understandable how its placed "where ever the login actions are"; due to the k= cookie being among them.

This does however bring forth an other interersting dilemma. For example /passwords/ is already namespace within phpbb, so should front-end controllers always be in a separate namespace or can they be inside existing ones?

I don't know enough about the technical ramifications in order to say what exact challenges "inside existing ones" could present immediately or in the future. i.e. At a source code and design level, I don't know what to picture in my head as to how "separate" or "co-mingled" the source files or interface invocation semantics might become if /passwords (related to hash and storage technologies) shared the same namespace as /passwords (related to front-end UI pages), etc.

If the only "true co-mingling" was at the file system namespace level -- e.g. /passwords/driver and /passwords/controller sharing the same parent /passwords folder, for example -- sharing the single name space seems preferable. To retain the clarity of the naming being "the succinct and logical thing you would have expected" (/passwords) rather than "made arbitrarily weird" just to avoid naming collisions (/passwords_management, /password_pages, /passwords_ui, etc.).

password
- reset_password (possibly make it just 'reset')
- forgot_password (possibly make it just 'forgot')

Should "password" even exist as a separate route, at peer with "account"? It's the same "you're going to specify and account, and eventually do something with the password of that account" as one could describe for the "login" actions. So if logging in with "the password on this account" is a function of "account", wouldn't "reset the password on this account" also be a function of "account"? We're not changing the password's password; we're changing the account's password.

- resend_activation (possibly make it just 'resend')
...
- reset_password (possibly make it just 'reset')
- forgot_password (possibly make it just 'forgot')
...
- switch_permissions (possibly make it just 'switch')
- restore_permissions (possibly make it just 'restore')

Agreed; do not have the name duplicate the name of the namespace we're already in, if we end up in those situations.