Skip to content

Conversation

bradenmacdonald
Copy link
Contributor

Description:

This simple change sets ENABLE_COMBINED_LOGIN_REGISTRATION to be True by default in all environments. Beth had asked me to do this as part of the SSO work.

This is part of the Shibboleth/SSO work and is being merged to the shibboleth-tpa feature branch, which is due to be merged to master ASAP.

Compatibility / Notes: People can always override the feature flag locally, if they don't want the new page yet. The new page is required for many of the new Shibboleth UX enhancements, though the basic SAML/Shibboleth login support should work with the old as well as the new pages.

Sandbox: https://courses.stage.edx.org/login :-p

JIRA tickets / Discussions: OPEN-507

@openedx-webhooks
Copy link

Thanks for the pull request, @bradenmacdonald! I've created OSPR-668 to keep track of it in JIRA. JIRA is a place for product owners to prioritize feature reviews by the engineering development teams.

Feel free to add as much of the following information to the ticket:

  • supporting documentation
  • edx-code email threads
  • timeline information ('this must be merged by XX date', and why that is)
  • partner information ('this is a course on edx.org')
  • any other information that can help Product understand the context for the PR

All technical communication about the code itself will still be done via the Github pull request interface. As a reminder, our process documentation is here.

@bradenmacdonald bradenmacdonald mentioned this pull request Jun 19, 2015
14 tasks
@bradenmacdonald
Copy link
Contributor Author

Jenkins, test this please

@Kelketek
Copy link
Contributor

👍

@bradenmacdonald
Copy link
Contributor Author

@cpennington This is ready for your review. (It's small)

@sarina
Copy link
Contributor

sarina commented Jun 23, 2015

ugh I have some concerns about this, as shown by the discussion here: https://openedx.atlassian.net/browse/OPEN-507

@talbs

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there an issue of just leaving this defined in test files?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No. Since the default in envs/common.py would now be true, there's no need to override the default and set it true in the test file, so I removed this. But there'd be no harm in leaving it in, either.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah I guess I'm just wondering - it seems like the settings that tests depend on should all, always, be explicitly laid out in these files rather than implicitly relying on the values in common.py. If I run my own fork and I change values in common.py then try to run tests, I'll get unexpected, hard to trace failures.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess I was naively hoping that we'd be completely removing this feature flag in the near future :-p

I will push a little reversal of the changes to the test envs so the flag is there explicitly. I think you make a good point.

@sarina
Copy link
Contributor

sarina commented Jun 23, 2015

From an engineering pov, 👍 modulo my questions.

From an Open edX and UX pov, outstanding questions so please don't merge just yet.

@bradenmacdonald
Copy link
Contributor Author

@sarina I understand that; thanks for reviewing and for linking to the discussions. Note that some of the new SSO features only work with the combined logistration page, but from my perspective it is not critical to include this change in the release. That said, I do think the SSO work is a good excuse for switching everyone over, so we can start to remove the duplicate code paths, which would be really nice.

@sarina
Copy link
Contributor

sarina commented Jun 23, 2015

While I 100% agree about the duplicate code paths (note that I filed the
ticket!), I am very, very concerned about making the default be something
that more matches the Drupal site as opposed to the rest of the default
Open edX installations.

On Tue, Jun 23, 2015 at 11:19 AM, Braden MacDonald <notifications@github.com

wrote:

@sarina https://github.com/sarina I understand that; thanks for
reviewing and for linking to the discussions. Note that some of the new SSO
features only work with the combined logistration page, but from my
perspective it is not critical to include this change in the release. That
said, I do think the SSO work is a good excuse for switching everyone over,
so we can start to remove the duplicate code paths, which would be really
nice.


Reply to this email directly or view it on GitHub
https://github.com/edx/edx-platform/pull/8600#issuecomment-114541866.

@bradenmacdonald
Copy link
Contributor Author

Test failure is an unrelated buggy test with a hardcoded date that will always fail after June 22, 2015.

@sarina
Copy link
Contributor

sarina commented Jun 23, 2015

Isn't a fix for that merged to master?

On Tue, Jun 23, 2015 at 1:20 PM, Braden MacDonald notifications@github.com
wrote:

Test failure is an unrelated buggy test with a hardcoded date that will
always fail after June 22, 2015.


Reply to this email directly or view it on GitHub
https://github.com/edx/edx-platform/pull/8600#issuecomment-114577102.

@bradenmacdonald
Copy link
Contributor Author

Probably but this code is based on the feature branch and I haven't rebased it in a couple of days.

@sarina
Copy link
Contributor

sarina commented Jun 23, 2015

@mhoeber this may have docs impact, fyi

@talbs
Copy link
Contributor

talbs commented Jun 25, 2015

@bradenmacdonald and @sarina, thanks for the ping on this PR.

The UX team has taken very light steps to make this initially edX-only and marketing-driven UI look more like overall edX UI and use elements that are leveraged in Open edX (e.g. buttons). So the thoughts captured in https://openedx.atlassian.net/browse/OPEN-507 are slightly diffused.


If @ebporter has asked for this feature (and SSO functionality is built on top of this), I can understand the drive to get this merged. However, I would like the following items to be addressed by Beth as blockers or not, especially if this is getting into the official Cypress release:

  • This is a drastic UI change from the existing login/register views instance owners have now, especially if this is now the default UI. Their customizations and theming of the pre-Cypress views are probably not compatible with these new views. Is there documentation, a heads up, or any backwards compatibility at all for this?
  • These new views are derivative from edX Marketing efforts. I can't say their UI has been completely thought about from an Open edX instance PoV (@ebporter, this is what our Open edX onboarding project is supposed to tackle). I'm concerned that we're not actively deciding to use a UI, originally made for a specific purpose, in another context.

@ebporter, I'll leave it in your hands to note if these concerns are blockers as well as if they should be addressed at all.

@bradenmacdonald
Copy link
Contributor Author

Just a note of clarification: This only changes the default setting. Any instances/customizations/themes that depend on the old version will continue to work fine as long as they change the setting locally to use the old pages. So it is fully backwards compatible, and it doesn't remove any code.

@sarina
Copy link
Contributor

sarina commented Jun 25, 2015

@bradenmacdonald Why must this be the default? I am concerned about
everything Brian points out, and if it's so easy to turn off the combined
login, why not instead put the burden to turn it on for those who wish to
have it on?

On Thu, Jun 25, 2015 at 4:03 PM, Braden MacDonald notifications@github.com
wrote:

Just a note of clarification: This only changes the default setting. Any
instances/customizations/themes that depend on the old version will
continue to work fine as long as they change the setting locally to use the
old pages. So it is fully backwards compatible, and it doesn't remove any
code.


Reply to this email directly or view it on GitHub
https://github.com/edx/edx-platform/pull/8600#issuecomment-115378049.

@bradenmacdonald
Copy link
Contributor Author

@sarina I am 100% fine either way. If it's looking like too much hassle to do this now and everyone is fine with it, we can just close this PR, and just make sure that DevOps switches Edge to the new combined page.

There is a concern that new Open edX users who want to use SSO will find it confusing that they have to change the login page first, so we'll have to make that clear in the docs. The code is very unambiguous with deprecation warnings all over the old login/register views, but I'm not sure that the choice is as clear to people setting up instances.

@talbs
Copy link
Contributor

talbs commented Jun 25, 2015

Thanks for the 411 and discussion, @bradenmacdonald and @sarina. I'd say which version to lead with is @ebporter's call.

@talbs
Copy link
Contributor

talbs commented Jun 25, 2015

Assuming that this is just being released on Edge and that @ebporter has made a call + planned for communication and larger roll-out strategy with Cypress, I'll default to her judgement on this.

👍


@ebporter, let's talk about next steps with this switch and how it affects our onboarding UI plans.

@sarina
Copy link
Contributor

sarina commented Jun 25, 2015

@talbs this PR would make it the default for Edge, devstack, and all Open
edX installations. The other option is to close this PR and just explicitly
enabled combined registration on Edge, which it currently isn't.

On Thu, Jun 25, 2015 at 5:52 PM, Brian Talbot notifications@github.com
wrote:

Assuming that this is just being released on Edge and that @ebporter
https://github.com/ebporter has made a call + planned for communication
and larger roll-out strategy with Cypress, I'll default to her judgement on
this.

[image: 👍]

@ebporter https://github.com/ebporter, let's talk about next steps with
this switch and how it affects our onboarding UI plans.


Reply to this email directly or view it on GitHub
https://github.com/edx/edx-platform/pull/8600#issuecomment-115409768.

@talbs
Copy link
Contributor

talbs commented Jun 26, 2015

@talbs this PR would make it the default for Edge, devstack, and all Open
edX installations. The other option is to close this PR and just explicitly
enabled combined registration on Edge, which it currently isn't

Hmm, yeah, I'm not sure I can make that call (FWIW, I don't think we're ready for this to be the default in all of those places). @sarina, this sounds like a Beth (@ebporter) call. Can you get her to weigh in tomorrow while I'm OOO?

I'm definitely very comfortable with the option to set up Edge this way while figuring out a plan for the rest of the environments noted above.

@chrisndodge
Copy link
Contributor

Hey there, @wedaly pinged me on this PR. I'd like to try this branch out locally and see if there might be any impact on our existing white label sites in edX production servers which do not use the new logistration page (because our customer wants enhanced registration fields). My sense is that this will break our production environment.

Please don't merge this until I can check it out. I suspect there will have to be an additional small code change and a change to edX's production configuration. I believe I understand there's a bit of time urgency, so I'll get back to everyone by EOD tomorrow.

@chrisndodge
Copy link
Contributor

OK, I noticed @sarina's comment that this would be turned on - via production configuration - for Edge (not edx.org deployment). Then we wouldn't impact our White Label customers, but it'd probably still be good to get any necessary code changes (e.g. using microsite.get_value(), etc.) before it gets merged in, otherwise we might forget to do so in the future.

@sarina
Copy link
Contributor

sarina commented Jun 26, 2015

@bradenmacdonald @chrisndodge @talbs I just spoke about this with Beth and we've decided for now, we're going to turn this on just for edge. After Cypress is cut we can discuss turning this on for everyone by default. Before we do that we need to make sure that works with white label settings, per Chris' concerns. Additionally we may choose to do this after the ongoing UX audit is completed and we have a chance to clean up the stylings a bit. We are in agreement we'd like to turn this on by default before the Dogwood release.

Does that work for everyone? If so I'm going to close this PR for now and we can pick it back up in a few weeks.

@bradenmacdonald
Copy link
Contributor Author

@sarina Works for me; please go ahead and close this.

@sarina sarina closed this Jun 26, 2015
@bradenmacdonald bradenmacdonald deleted the shibboleth-login-default branch May 18, 2019 21:52
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
engineering review open-source-contribution PR author is not from Axim or 2U
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants