I would like to make support for the password change tab more generic through the user of a variable so that modules such as chgpwd may be used with password_policy.

CommentFileSizeAuthor
#12 password_policy-make_password_redirect_overridable-1424324-12.patch2.5 KBerikwebb
#10 password_policy-make_password_redirect_overridable-1424324-10.patch2.49 KBerikwebb
#3 password_tab_url-1424324-3-D6.patch1.65 KBpdrake
#2 password_tab_url-1424324-2-D6.patch1.62 KBpdrake
#1 password_tab_url-1424324-1-D6.patch791 bytespdrake

Comments

pdrake’s picture

pdrake commented
StatusFileSize
new password_tab_url-1424324-1-D6.patch791 bytes

Initial implementation.

pdrake’s picture

pdrake commented
Status: Active » Needs review
StatusFileSize
new password_tab_url-1424324-2-D6.patch1.62 KB

This patch includes both the above change and the necessary variable management in password_policy_password_tab.install.

pdrake’s picture

pdrake commented
StatusFileSize
new password_tab_url-1424324-3-D6.patch1.65 KB

Attached is a patch that will apply cleanly to 6.x-1.0-beta1 for anyone who may be running that version. Otherwise, this patch may be ignored.

erikwebb’s picture

erikwebb commented
Status: Needs review » Postponed (maintainer needs more info)

What is the exact use case here? I understand making the URL more generic, but how does this make interoperability any easier than just a form alter?

pdrake’s picture

pdrake commented
Status: Postponed (maintainer needs more info) » Needs review

In my use-case, it enables me to utilize this functionality with another module - specifically, chgpwd (see http://drupal.org/node/1424404).

erikwebb’s picture

erikwebb commented

I don't mean what module needs the integration. What is the point in making this more generic when someone could already use a form alter to modify whatever they need to?

pdrake’s picture

pdrake commented

I'm afraid I don't understand. In this case, the redirect occurs in hook_init and redirects the user (via drupal_goto) to a particular URL when a password change is forced. I'm not sure how a hook_form_alter could cause this to behave differently, except maybe to perform yet another drupal_goto in the hook_form_alter?

erikwebb’s picture

erikwebb commented
Status: Needs review » Closed (works as designed)

Ah I see. I don't think creating a redirect from a tab is good UX. I would suggest hiding the tab and creating a link within the normal user form. From the hook_menu() documentation -

Local tasks are menu items that describe different displays of data, and are generally rendered as tabs.

Since your application would require a redirect, this no longer fits into the tab menu model.

pdrake’s picture

pdrake commented
Status: Closed (works as designed) » Needs review

The existing code redirects the user to a fixed URL which is supported by 1 module. It does this in hook_init if a password change is forced. The change I'm proposing is to redirect to a variable URL which is supported by 2 modules. It will still do this at hook_init if a password change is forced. This does not have anything to do with tabs or menu entries.

erikwebb’s picture

erikwebb commented
Title: Make password change tab support more generic » Make password redirect URL overridable
Status: Needs review » Needs work
StatusFileSize
new password_policy-make_password_redirect_overridable-1424324-10.patch2.49 KB

Now I fully understand. You're not really making the change tab more generic. This is actually an issue to make the password redirect overridable. My apologies for being a bit stubborn.

I think your patch is a bit too assumptive. I've changed the install functions to be more adaptive if another module has taken over this behavior. Also I've properly namespaced the variable.

erikwebb’s picture

erikwebb commented
Status: Needs work » Needs review
erikwebb’s picture

erikwebb commented
StatusFileSize
new password_policy-make_password_redirect_overridable-1424324-12.patch2.5 KB

Sorry, stupid syntax mistake.

greggles’s picture

greggles
he/him
Primary language English
Location Denver, Colorado, USA
commented

Looks sane to me.

erikwebb’s picture

erikwebb commented
Status: Needs review » Fixed

Fixed and committed.

http://drupalcode.org/project/password_policy.git/commit/0e0fb93

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.