[NFR] Public subdomains

jonphipps commented 11 years ago

[new Feature Request]

A configuration option that would make subdomains:

all private (as they are now)
all public (allow viewing without auth)
optional (allow selection when account is created)

One of our potential business models for SaaS is making everything public but charging for private, with potentially two modes of private:

public account with a mix of public and private projects
entirely private account

Being able to make the whole subdomain publicly readable, either by default or by customer selection at signup, would allow us to selectively make portions of it private based on an access level determined by payment level or editorial level.

Is this the best place to put a request like this, or should it be brought up in the community?

jbroadway commented 11 years ago

You can always start a thread on the forum, but this is probably a better place to discuss the details of a new feature. Just yesterday I posted a feature proposal for Elefant on Github, but mentioned it in the relevant thread on the forum.

I like the idea of more control over customer accounts. I can see building a service that a customer then uses to offer their content to their member accounts, and there's no reason a handler has to call the saasy\App::authorize() at the very top of each script, there could be some public content too as you say.

We should define each setting we'll need and its behaviour, so we have something to refer to when I get confused ;) I wrote something similar when we revamped the navigation app's internals recently, although that was a strange interaction between several settings...

I can see access_mode=private being Saasy's current behaviour, and would there need to be separate semi-public/public settings, or would one public setting be enough to give developers the ability to create semi-public offerings? I guess your third would be something like access_mode=optional to allow customers the choice in their settings.

This could be really cool :)

jbroadway commented 11 years ago

Off the top of my head...

`access_mode=private`

Whole customer area is behind login wall

`access_mode=public`

Handlers are all accessible publicly
Up to the developer when to authorize visitors
Account replaced with Signup link for public visitors

`access_mode=optional`

Switches customer account between those two modes depending on their settings
Developer would need to be aware of how their app works in both modes

We may also want a setting to allow public signups or not.

jonphipps commented 11 years ago

This looks great! I think app-level paywall access and/or role-based app access is a different issue than public/private and for maximum flexibility would be available in either mode.

Re: public signups...

Yes, I could see a customer wanting their site to be invitation only, which would mean providing a means to invite members (which we mostly already have via verification transactional emails) and the ability to request an invite directly or by referral.

jonphipps commented 11 years ago

At some we probably should think about prioritizing and assigning responsibility for implementing some of these issues to me (or you) so that neither of us just assumes that the other will do it. It seems we both have a lot on our plates and multiple drivers of how we prioritize our time and it might be good to be clear about who takes the lead on an issue that we both think is a good idea, as well as how urgent an implementation is.

jbroadway commented 11 years ago

Good idea. Why don't we keep track by assigning ourselves to an issue on Github and trying that out as a way to keep track, and maybe note in the issue comments if we need as well?

For myself, I'm in hyper-mode on an app built on Saasy for the next few weeks, but I don't think it needs any more changes to Saasy itself, so I'm not sure if I'll be able to add much until after that's done. And on Elefant I'm probably in the same boat too, just trying to keep up with fixes, pull requests, the forum, and rewriting the homepage :)

jonphipps commented 11 years ago

I can't assign myself an issue. I think you'd have to add me as a collaborator in settings to do that, and I'm still not sure I could even then. Or you could setup an organization, which would give you fine-grained control. I'm not asking you to do any of that, just pointing out what seems to be a pre-requisite.

But without being a collaborator I don't think you can assign me an issue either. I read some place that a workaround might be to create labels with "@[user]". We could also use a search phrase like "owner.Jon".

I understand hyper-mode all too well, and you shouldn't consider any issue I raise as urgent unless I add [urgent] to the issue title.

https://help.github.com/articles/what-are-the-different-access-permissions

jbroadway commented 11 years ago

Ah yes, you're right. I'd like to keep to the pull request model since it gives everyone their own fork to work with and forces me to review changes (which in theory improves our QA), but that definitely limits the usefulness of Github issues...

It would be good to have a way anyone can "claim" an issue and work on it without going through "official channels" first, which creates a barrier to entry. What if we add instructions to the contributing page to formalize a process, which could be as simple as:

Fork the main Elefant repository
Create a new issue, or add a comment to an existing, unclaimed issue that says Working on this in [username/elefant](https://github.com/username/elefant).

That will trigger an email to me and I can then add an "in progress" label to it to make it easier to see at a glance what's open. If something stays in progress for a long time, we can always enquire about it in the issue comments and reopen it.

What do you think? Can we improve on that?

jonphipps commented 11 years ago

(Reemerging from internet-challenged travel)... That looks good. Would it be asking too much to require someone claiming an issue like that to create and reference a specific branch in their fork? You'd want that for a PR anyway.

Working on this in [https://github.com/username/elegant/feature/newfeature]

Should be enough.

jbroadway commented 11 years ago

Just updated the Contributing page about this.

jbroadway / saasy