Remove Team field from signup form?

Hey @joacimnilsson,

The team field is displayed on registration whenever the use CanJoinTeams; is added to the User model. However, if you disable the CanJoinTeams you will not have the ability to create teams.

I just updated this post, as i thought it was possible to allow team creation if the maxTeams() was added to a personal plan, however that just returns this error when subscribing. Call to undefined method Illuminate\Database\Query\Builder::ownedTeams()

When using the team feature you either create a new team or you will be invited into a team. It's not needed to enter the team name when invited and using the e-mail invite link.

I don't see a way to mix it with the current setup.

@joacimnilsson did you get anywhere with this?

i am in the same position i think - i don't want to force the user to have to create a team when signing up

I would also be interested in this.

I solved it by removing

if (Spark::usesTeams()) { $this->configureTeamForNewUser($request, $user); }

from Register.php spark/src/Interactions/Auth/Register.php

and then in the register-common-form.blade.php I set the input field with name "team" to input type "hidden" and set the value to something random. Like this.

input type="hidden" name="team" value="s" v-model="registerForm.team"

It worked for me. And now when a user register they see the missing-team.php page but I changed it to getting-started.php.

Hope it helps! @SamStenton & @xirkus & @cboxdk

If I am not mistaken the change your are describing gets overwritten with the next spark:update or a composer update/install as it resides in the vendor folder (which gets managed by the composer.json contents in a standard setup - again with the "if I am not mistaken"-disclaimer...)

Any thoughts on how you plan to handle this? I'd be very interested as there are quite some more fields in the signup process that should be removed for usability and conversion rate optimization...

@EventFellows According to Taylor the update script checks to see if a file has been modified since the last version and skips it!

@SamStenton

That's for views. Anything else is far game

@SamStenton

When i updated form 1.0.6 to 1.0.7 I could just verify that the console puts out promts for view that it skipped like @jekinney mentioned.

My understanding has always been that the folders in /vendor (managed by composer.json) and folders in /node_modules (managed by npm) are NOT to be touched by user as they can get overwritten at any time by the functionalities of the different package managers.

That's also why these folders are by default contained in .gitignore.

@EventFellows @jekinney I assumed it works for the whole Spark directory as it doesn't live in the vendor folder?

There are several directories by the name of "spark" - so let's be sure we talk about the same

If you are talking about spark directory that lives directly in the root of your application on the same level ass /app, /config etc.

I am not quite sure what this directory is for or if it is USED AT ALL!?

BECAUSE I have now installed spark the "composer way" (see documentation) and then this directory does not even exist at all (but spark is fully functionally, even update from 1.0.6 to 1.0.7 worked without any issues)

To me it seems that spark in root and spark in vendor/laravel/spark are exactly the same (same size, same number of folders/ same number of files - I did not get into any more detail to verify it)

We're definitely veering off topic here guys

@EventFellows I am definitely going to look into Spark the composer way - I'm not a fan of the spark folder in root - but would be very keen to hear the pros and cons of each approach.

@joacimnilsson I can definitely see how what you're suggesting works. But it feels/is hacky ;-)

Personally, I would expect Spark to default to optional teams and you should set a flag to force users to join teams. But, making a user fill in a team name on registration is odd. Am I missing something?

@xirkus Yeah it's hacky. I got this answer from Taylor so decided to solve it somehow.

https://twitter.com/taylorotwell/status/724287876293267456

@joacimnilsson Er. Wow. That's not really an answer ;-)

I'll be honest, when I saw the Team Name was required I just created a note to come back to it when we're doing the UX as it's obviously wrong. I hope that's the case!

I get the point about invites - but why put a potential blocker in the way of people signing up? Get them in and let them join teams or be invited to them once there in. AND let them come via the invite route.

I am still on the search for a cleaner setup without Team Field on signup...

Here is an idea: what do you think?

1 - We could hide the team field via CSS on signup form and fill it with a random string behind the scenes

2 - So team get's created and should pass all validation build in by Taylor

3 - Should be possible to listen to an appropirate system event that gets fired by default and remove the team from the database right after/ during creation.

(In a sense this would automate the process where the user would create a team on signup and then delete it manually from his team page)

I would hope this can work as there does not seem to be any hard requirement for a team on the database or so.

Opinions?

@EventFellows @joacimnilsson I'm just guessing here (I'm too bogged down with the business logic of the app currently to take a look just now) but I would imagine that you can modify the logic that displays the relevant form.

There will be an if (teamsEnabled) conditional somewhere that determines which sign up screen is displayed. So, maybe set an config variable called OPTIONAL_TEAMS and change the logic to if (teamsEnabled && !optionalTeams) then display team related reg screen. Otherwise, display the user reg screen.

The same change may be required for the validation. But it should be trivial to override.

As I say, I am guessing here. By all means prove me wrong. Or right ;-)

Also, I am guessing (again) that the above won't kill the invite system!

@xirkus You mentioned that

'... it should be trivial to override.'

How would you overwrite something that resides within the vendor folder without running the risk of having composer overwrite it in future? If that is trivial, please share - I'd be very interested!

I have opened a new thread with a suggestion abou the cleanest way I could come up with (as this is already marked as complete) https://laracasts.com/discuss/channels/spark/make-team-field-optional-remove-from-registration-form

@EventFellows Because it's a view. We don't have to have the Spark views.

So craft you're own registration page and apply the logic for which form gets displayed there.

@xirkus

The view is trivial, i agree. But the view is not what makes it difficult - it is the validastion logic that get's applied with all its different conditions and that is living in src folder of spark....

@EventFellows but it's overridable I assume. And without modifying the vendor package I'd hope.

As I've said, I am guessing here. Just trying to throw some ideas out there to help others explore a solution to this as it does appear to need one. If you've done the research on this and say it can't be done this way then great, we know to go looking in another direction.

We'll be moving on to it in a couple of weeks so I'll post our solution then. But if anyone has a solution in the meantime please do post it.