New features to investigate for 2.0

[splendido]

• integration of mail check js for email validation (see #99)
• better 3rd party account services control: only sign in, only sign up, only link... (see #111)
• add more helpers to expose single sign up fields, and their validation process, for user profile pages (see #114)
• tests! (see #73)
• two factor authentication
• mixed case username/password detection (see this issue on telescope)

[mattkrick]

1 final suggestion from me :-) On registration, after meteor throws the error that the username/email already exists, try logging in with those submitted credentials (and return a result so we can notify them what we did via toast). It's a delightful little helper because a surprising number of users have no recollection of whether or not they already created an account.

[Sivli-Embir]

Definitely profile helpers. Having a drop in way to let users manage multiple emails and social logins would be amazing. This could be a good place to hook in useraccounts:meld.

Another thing I have been playing with is invite only apps. Being able to invite a user to an app or even to a scoped group would be fantastic. It would need to check if the email/social account is already tied to an existing user and add them to the group, or just tell the inviter that they exists. This may be too much for 2.0 but its worth thinking about. Maybe it does not fit into useraccounts?

[splendido]

@Kestanous, you're right useraccounts:meld will be a plug-in package for v2.0! The invites is also something I'd like to add: not sure if as another plug-in package or as a standalone useraccounts:invites but I guess it is something very well coupled with accounts management.

Also Sasha suggested to integrate this so to have another part of Telescope delegated to external packages. See this issue and this post on crater.io

[Sivli-Embir]

@splendido Thanks for the links ^_^ responded appropriately. Feel free to message me when you get started on this, I should have some time after the new year.

[splendido]

:+1:

...I'd like to try to make up the skeleton for v2.0 during these holidays, I'll ping you afterwards ;-) Tnx!

[Sivli-Embir]

@splendido looks like telescope's invites are now done here: https://github.com/TelescopeJS/Telescope/tree/master/packages/telescope-invites

Its a good start but my use case would be more complex: http://crater.io/comments/RNun3jHtBNf7n4BQn

[splendido]

Ok, good to know, tnx!

[Sivli-Embir]

@splendido sorry to bump but issue #114 is still a large priority for me. I was thinking that I could add a accounts package for http://creativepure.meteor.com/. But which of all the beautiful input options should I pick? I think v2 should have a lot less stylized packages and be a lot more customizable.

[splendido]

@Kestanous, could you explain it a bit more? You mean you'd like to create a useraccounts:creativepure package? ...how is this connected with #114?

[Sivli-Embir]

So creating a creativepure package would not make sense. The point of that package is to only add the css you want with an import. Any users of it will want different inputs styles for their user forms. I guess #114 is not a perfect example. Maybe something closer to https://github.com/aldeed/meteor-autoform. Have you seen how they do custom styles?

[splendido]

See the trello board

[Sivli-Embir]

What is the state of the new code? Anything to look at? The V2.0 bunch look stale and I was curious if you moved it. No pushing, just wonder.

Quick thought on V2, are you going to make it with ES2015? Having it be built in a class structure might make extending it very easy for third party packages.

[splendido]

I went back to v2.0 a little in the last couple days... I have some local code which has still to be pushed to GitHub, hopefully it will be by the end of the week ;-)

In any case at the moment there's a bit of OAuth flow and FR working quite good, but the code is still to be polished and a few patterns need to be figured out to make it esay for plugin packages to play easily with base ones...

At the moment I have no idea when an alpha release could be published, but it could be helpful to throw out something, even if not really comprehensive, to let who is interested about it to play around and give feedbacks...

ES2015 would be a god thing, for sure! The class structure is more or less already in place for modules and plugins bout would actually benefit from ES2015 ;-)

[awatson1978]

Hi all.
So, last month the clinical:active-entry package got a suite of Gagarin tests and Nightwatch tests set up and running on Circle CI. Yay! Everything is green! We're ready for refactoring and V2!

I also recently received an email from the Open Health Imaging Foundation, and they have some grant funding and are going to be getting a developer to work on a list of enhancements to the entry page(s).

Long story short, we have test suites and some grant funding, and would be amenable to merging efforts, and combining the useraccounts:core and clinical:active-entry projects in some way. Most likely by moving logic from our ActiveEntry object into useraccounts:core, and using it as a dependency.

We have some usecases that are specific to the healthcare industry... Card UI, Autologout, FullName fields on signup, etc. But nothing that wouldn't make the useraccounts:core package a better product in the long run. We're also Blaze-centric, and using inline style helpers as part of our page components, which is one peculiarity; but that logic could stay in the clinical:active-entry package.

Other than that... any reasons why we shouldn't combine efforts here?

[splendido]

Hi Abigail! I really appreciate you considered useaccounts packages as something to leverage and contribute to!

Unfortunately I never had a chance to check out your clinical:active-entry package and have no idea about its features and state. Out of curiosity, which are the differences between the two at the moment? Is there something that can be done with one and not with the other?

Some months ago I started a big refactoring of the code (which can be found in v2.0 branches here and there, e.g. core@v2.0) to make everything more modular and even more customizable (LDAP sign-in was among the targers for example but difficult to integrate within current code base...). I think I got to a good point at that time: I had a bunch of working modules (title, 'separator', OAuth, and flow-routing) and a configurable skin layer allowing to attach different class attributes to the form elements based on the selected UI framework. The 'only' missing part was the one deailng with accounts-password, the most complex actually, but since logics and workflows are already dealt with in the current version I'd say there wasn't that much missing to get to a release candidate...

My dream was to get v2.0 onto atmosphere soon but then I started to have very few spare time, the discussion about Blaze-React opened some questions about whether try to support both or not, the Meteor Guide project brought me back to revise the current version and in the meanwhile issues and PRs started to pile up... I was also about to write tests but suddenly no one knew which was the official way to test Meteor code... What more, the new support for ES6 syntax and the upcoming modules support of Meteor 1.3 are making me a little lost...

Eventually everything evolved into a frozen state! :-(

...and now everytime I have a spare hour I don't know where to start from: only trying to reply to all open issues would probably require more time than I have available.

Despite this I still dream of a v2.0! And I'd say the right direction would be continuing to work on it rather than adding new features to v1.

My idea is still to make every bunch of independent features into a separate package so we might end up with (all under the useraccounts namespace):

packages providing logic-less templates

• blaze-templates
• react-templates

packages providing underlying logic for templates

• title
• OAuth
• password
• invites
• re-captcha
• password-strength-meter

routing packages

• flow-routing
• iron-routing
• react-routing

plugin packages (providing additioal behaviour)

• meld
• tfa
• auto-logout
• etc. etc.

If you asked me to consider your list of enhancements, I'd say most of them could became plugin packages for useraccounts@2.0 (while a couple items are already implemented...).

I'm not sure what you might think about this plan but what I think is the meteor community would need somethink like this!

This said, what would you suggest? How to proceed, also considering your availability to contribute to the project?

In any case thanks for the offer, I truly appreciate it. Lets try to combine efforts and see whether there's a possibility to start again supporting all community requirements (at least at design level).

Cheers, Luca

[SachaG]

I'm happy to pitch in for the React version if I can help :)

[splendido]

That'd be lovely @SachaG!

[splendido]

@awatson1978 have you had a chance to read my above comment? I realize only now I haven't mentioned you therein, so you might have not received any notifications...

How could we go about this alltogether?