Allow null group assignment for users (Issue #867)

[amosfolz]

I think this is ready for a review.
Maybe someone else can suggest a better way to handle showing an empty option using select2.

Ref.: #867

[lcharette]

Looks like something is broken with the new migration : https://travis-ci.org/userfrosting/UserFrosting/jobs/518564703#L873

[amosfolz]

I am going to try to see if I can figure out what is causing Travis to fail here. I noticed the migrations are all completing without any errors...

[lcharette]

The good news is, you're not crazy. I checked out your branch and can't replicate the Travis issue. Even if I replicate Travis env locally (ie not using the :memory:database), the only issue I see is related to testGetAsset.

[lcharette]

One thing to note, Travis complains about UpdateUsersTable.php:56, which means the issue would be with the down method...

Actually, it could be a MySQL config thing. The error is different on PgSQL. Something might be different between Travis MySQL setup and local/Homestead one.

[amosfolz]

Okay, so I believe the PgSQL error is actually related to this https://github.com/userfrosting/assets/releases/tag/5.0.4

[lcharette]

Okay, so I believe the PgSQL error is actually related to this https://github.com/userfrosting/assets/releases/tag/5.0.4

And I believe it was fixed in hotfix here : 36ed889

Since this PR target UF 4.3, I suggest we leave it as is for now and look at it once we have released 4.2.1. We'll need to merge hotfix into develop at some point anyway.

[amosfolz]

Is this something in the migration that needs to be fixed or is there possibly something in the test environment/configuration causing this?

[codecov]

Codecov Report

Merging #964 into develop will increase coverage by 0.02%.
The diff coverage is 88.88%.

@@              Coverage Diff              @@
##             develop     #964      +/-   ##
=============================================
+ Coverage      66.93%   66.96%   +0.02%     
- Complexity      1913     1918       +5     
=============================================
  Files            159      160       +1     
  Lines           6684     6693       +9     
=============================================
+ Hits            4474     4482       +8     
- Misses          2210     2211       +1

Impacted Files	Coverage Δ	Complexity Δ
.../src/Database/Migrations/v430/UpdateUsersTable.php	100% <100%> (ø)	3 <3> (?)
.../sprinkles/admin/src/Controller/UserController.php	99.79% <50%> (-0.21%)	110 <0> (+2)

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update df8495e...71b2cd1. Read the comment docs.

[amosfolz]

I think this will need to be a non-reversible change. I have been trying for hours to get a down migration to work that will set the column back to not null and have had no success.

And now that I think about it, because this PR makes changes to templates and asset, without a way to reverse the changes in those files other than reverting back to a prior version of UF, there is really no reason to reverse this migration as it will break the interface by having an empty option in UI.

[lcharette]

I think this will need to be a non-reversible change. I have been trying for hours to get a down migration to work that will set the column back to not null and have had no success.

If the change in the db is not reversed, and the files are reversed to 4.2.x, does it still works? Obviously, you won't be able to select "no group", but as long as the db still works, we should be good.

[amosfolz]

I think this will need to be a non-reversible change. I have been trying for hours to get a down migration to work that will set the column back to not null and have had no success.

If the change in the db is not reversed, and the files are reversed to 4.2.x, does it still works? Obviously, you won't be able to select "no group", but as long as the db still works, we should be good.

It should still work.

If that happened the only difference would be group_id would remain nullable.

   $table->unsignedInteger('group_id')->default(1)->comment('The id of the user group.')->change();

[lcharette]

Only issue I see so far is in the user detail page :

The • separating the username and group makes it weird now. Simple if in Twig should fix that.

[amosfolz]

Only issue I see so far is in the user detail page :

The • separating the username and group makes it weird now. Simple if in Twig should fix that.

Do we want this to show "No group" or just remove if they have that option select?

[lcharette]

Do we want this to show "No group" or just remove if they have that option select?

I think removing it by default makes more sense if someone doesn't want to use groups at all.

[amosfolz]

Only issue I see so far is in the user detail page :

The • separating the username and group makes it weird now. Simple if in Twig should fix that.

Fixed in 3467690.

I think this will need to be a non-reversible change. I have been trying for hours to get a down migration to work that will set the column back to not null and have had no success.

If the change in the db is not reversed, and the files are reversed to 4.2.x, does it still works? Obviously, you won't be able to select "no group", but as long as the db still works, we should be good.

I retested and can confirm the DB still works fine in this situation.

[lcharette]

I retested and can confirm the DB still works fine in this situation.

I did too last and it does works fine.