Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Can't turn assign Admin Set back on #3137

Open
julesies opened this issue Mar 10, 2017 · 10 comments
Open

Can't turn assign Admin Set back on #3137

julesies opened this issue Mar 10, 2017 · 10 comments

Comments

@julesies
Copy link

julesies commented Mar 10, 2017

7.2 upgrade to 7.3rc3

I was testing Workflow/Admin Sets for rc3 and turned off the setting Ability to Assign Admin Set. Then later, I went to turn it back on and it doesn't turn back on. Dean found this in his local instance too, but this could use a test by someone else to confirm.

To recreate:

  • Under Settings: Make sure setting for assigning to admin set is ON
  • Turn off Assign Admin Set
  • Navigate away
  • Under Settings Turn Assign Admin Set back on.

screen shot 2017-03-10 at 1 55 33 pm

@mjgiarlo
Copy link
Member

@julesies Huh. It would be interesting for you and/or @lfarrell to check a few things. The value of this feature flipper can live in a few different places, including in a cookie, in an ActiveRecord db, and in a YAML file. When you're seeing this behavior, could you check to see what's going on with the cookies and what's in the database? I'm not sure where this is getting "stuck."

@mjgiarlo mjgiarlo added this to the 7.3.0 milestone Mar 10, 2017
@lfarrell
Copy link

@mjgiarlo I cleared cookies, but it didn't have any effect. Is there a table in the db I should be looking at?

@mjgiarlo
Copy link
Member

@lfarrell I believe it's called "sufia_features"?

@lfarrell
Copy link

@mjgiarlo Looks like it's set to false, though I'm guessing the table didn't have any entries before today given the created_at and updated_at are the same time.
"1","assign_admin_set","f","2017-03-10 18:46:31.555705","2017-03-10 18:46:31.555705"

@mjgiarlo
Copy link
Member

@lfarrell Well, that'd explain why it's false. When you set it back to true and submit the form, can you double-check what's in the db? And see if doing so adds a cookie?

(Thanks for doing the legwork here.)

@lfarrell
Copy link

@mjgiarlo Not that I can tell. It does have a session cookie, but I assume that's unrelated. Should the cookie have a particular name?

@mjgiarlo
Copy link
Member

@lfarrell You've got me! It may be worth putting a byebug in the code (perhaps around where the form gets processed by the controller) to see what the params looks like and whether the db is engaged at all.

@mjgiarlo
Copy link
Member

@lfarrell Have you had a chance to troubleshoot this any deeper? Thx for looking into it.

@lfarrell
Copy link

@mjgiarlo I haven't. I'm not actually sure where to begin looking. I've thought of testing out a fresh vanilla install to see if I could replicate some of the local issues we've been having.

@mjgiarlo
Copy link
Member

@lfarrell OK, no problem. I'm pushing on this issue this week only because it's the one remaining unassigned 7.3.0 issue. Going the vanilla route would yield interesting information. If y'all are seeing any other issues that haven't yet been written up or resolved, do let us know!

@mjgiarlo mjgiarlo modified the milestones: 7.3.0, Backlog Apr 7, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants