newspring / holtzman Goto Github PK
View Code? Open in Web Editor NEWThe main NewSpring namespace and utilities for all newspring packages.
Home Page: http://holtzman.newspring.io/
License: Other
The main NewSpring namespace and utilities for all newspring packages.
Home Page: http://holtzman.newspring.io/
License: Other
This should allow the query of name
to search for a nav by name to match a set in EE
@samclaridge we will need copy for this action. I think having it happen in a modal is probably the easiest solution for now?
I think its worth a discussion point as our models grow to start to utilize MongoDb's transform methods to refactor our helpers. These allow access to the helpers as prototypes of returned collection queries but can also be made to function by passing in arguments.
We should also add a safety check on the Error template to try and find the .message
of an error instead of locking up trying to render an object
Whoever does this, please take screenshots along the way so @samclaridge can verify it is a great experience. There are some technical limitations (for instance scheduling multiple gifts as once) that required a UI change.
To verify:
This should allow setting of App Name (i.e. NewSpring, NewSpring App), and application settings needed from other systems.
@samclaridge do we have the print / download icon?
This is the UI trigger + the retrieval of the file in Rock.
this issue should act as an easy way to check off / view scope of the giving 1.0 MVP
Apollos giving is configured to use Network Merchants to process transactions and Rock to pull financial accounts, store transaction details, giving history, and schedules. The feature set required for launch is the following.
Most of these are already done as of Feb 24. We need to test and verify like crazy though and fix any bugs
All in all I think give is very very close. There are some bug fixes (schedule times, first payment date, and alerting finance, saving payments, and a few more) but its pretty close. We did a test with staff last Wednesday (Feb 17, 2016) and it went over pretty well. I'd like to do another test this coming week if possible.
This may be a setting we are missing. We need to verify a mismatch will fail a transaction. That way a successful gift can also mean a successful saved account if checked
this issue should act as an easy way to check off / view scope of the profile 1.0 MVP
The initial scope of the NewSpring account is focused around data integrity and existing account merging. It is critical that this part of the site / app be excellent as it is the easiest way to loose the trust of our users. The initial scope of profile is as follows:
Most of these are already done as of Feb 24. We need to test and verify like crazy though and fix any bugs
Same order as scope
Profile is close already. I don't love the navigation on desktop of settings but its okay for launch probably. We need to test with staff accounts, infellowship accounts, and database accounts. This needs to be easy to use and reliable. I do think it is in a good place though
You can recreate the issue easily by SSHing into a circle ci build and executing these commands.
docker run -a stdin -a stdout -a stderr -i -t ubuntu /bin/bash
apt-get install curl
curl https://install.meteor.com/ | sh
apt-get install vim
cd /home/
meteor create app
cd app/
vim .meteor/packages
Once in VI, append a newline with velocityjs:velocityjs. Then exit VIM and run this command to execute the installation:
meteor update
You will get this error:
Error: EINVAL, chown '/tmp/<random dir>/<package you added>'
Running this in docker on my machine (Mac OS X) works correctly, but in CI, it always throws the error.
Questions I am trying to answer:
What I've tried with no success:
@samclaridge I'll get you a login to beta-rock so you can edit this template directly. We should probably chat with @jonhorton about copy for this too.
should match voice / content of new account email
This could be just back
or back
+ sections
or something else.
Ideally lets return 10 at a time. The GQL server can return back the total results if wanted.
I think this is an issue with the POST to Rock as the NMI methods seem to be good to go. MM and @jonhorton were unable to save a payment. @BenWiley and I could and use it for gifts.
This should be only accessible by the applications in the same vpc
Applications built on Apollos can expose two types of client side views: pages and cards.
Pages exists only via hitting a specific route and are meant to be the more traditional style view (think server side rendered). The subscription of data for pages happens entirely within the Apollos.Router route for the given page. Ideally these are set or configured) only on the top level application view (i.e. the site or app that is using the Apollos framework). The template for the page includes markup, components and cards (among other things).
Cards are patterned usages of components and subscription of data to supply components with cached data. This is important because when a component is destroyed, the client side data is jettisoned prior to the next template render. In order to cache the dataset between components, a card should specify what data will / can be shared by components to prevent over subscription. The goal of a card is it can be included (and optionally configured) on any page in an apollos application. Cards can also change the url of the application and read from the url to set the state of the card. This is useful for page reload or sharing links.
In order for cards to be used as pages (so that state can be bubbled up to the router and visited at a url), the state management of cards should be extendable to routes. For example:
The form is a card that can be used inline on any page. The top level application (view) should be able to configure routes of cards to customize the application. (e.g. all giving shouldn't have to be at /give//add-to-fund).
State management is helpful to preserve temporary data between components as well without a write to the minimongo or server side db. This can be done with card level reactive variables that all child components can read from or write to.
Setting a state should be done within each card component and should relate to a top level card.
In order to best explain this API and structuring, lets look at a sample card and its corresponding components and pages. For this example we will look at a card representing an account / item that money can be given towards.
Below are the files we will be working with for the sample fund card.
Note that the file system shown below is abbreviated and is not meant for large scale projects
- client
- components
- fund.add-to-fund.coffee
- fund.add-to-fund.html
- fund.summary.coffee
- fund.summary.html
- fund.vision.coffee
- fund.vision.html
- give.fund.coffee
- give.fund.html
- give.html
- lib
- collections.coffee
- router.coffee
- server
- publications.coffee
The first thing we will need to do is set up a collection and publish it to
the client
# lib/collections.coffee
Apollos.Funds = new Mongo.Collection "funds"
fund = Apollos.generateSchema
name:
type: String
imageUrl:
type: String
optional: true
description:
type: String
optional: true
Apollos.Funds.attachSchema fund
# server/publications.coffee
# all funds, all fields
Meteor.publish "funds", ->
Apollos.Funds.find()
# one fund, all fields
Meteor.publish "fund", (fundId) ->
Apollos.Funds.find(fundId)
Now that we have our collection and publications setup we can start to look at the client side application. The first thing to do is set up a layout template to render our page into. Then we will set up the give page.
<!-- client/give.html -->
<template name="layout">
{{! simple layout to include templates using Apollos.Layout}}
{{> Template.dynamic template=layout data=currentData}}
</template>
<template name="give">
{{#each funds}}
{{> give.fund name=name}}
{{/each}}
{{! Any other presentation data here}}
</template>
This template includes a head and body which would normally be abstracted to layouts. It also loops through all funds {{funds}}
and includes a give card for each using the name as the identifier {{> give.fund name=name}}
In order to get the data to /give we have two choices. One is to create a give component and subscribe to the data that way. The other is to use Apollos.Router to set up a route at /give and subscribe to the data there.
For pages it is preferable if the data is managed in the router that way the data can be server side loaded.
# lib/router.coffee
Give = Apollos.Router.group({
prefix: "/give"
subscriptions: ->
# subscribe to all funds for any page within /give
@.register("funds", Meteor.subscribe("funds"))
})
# /give
Give.route("/", {
action: ->
# render home page of give
Apollos.Layout.render("layout", {template: "give"})
})
Give.route("/:fund", {
action: (params, queryParams)->
# render page of a single fund
Apollos.Layout.render("layout", {
template: "give.fund"
name: params.fund
})
})
Alright, at this point we have our data published to the client, a route set up at /give to show all funds, and the client has subscribed to the data for funds so we shouldn't have to worry about missing data. Now time to set up the actual fund card. This is the part that could be used on any page and should just work.
First thing we will do is make the template to show a simple card.
<!-- client/give.fund.html -->
<template name="give.fund">
{{#if subscriptionsReady}}
{{#with fund}}
<img src="{{imageUrl}}"/>
<h1>{{name}}</h1>
<a href="#">
Information
</a>
<a href="#">
Give now
</a>
{{/with}}
{{else}}
{{! show loading state here}}
{{/if}}
</template>
The only problem at this point is our {{#with fund}}
doesn't have any data for {{fund}}
. We could have handled this in our /give page by wrapping each render in {{#with}} {{/with}}
blocks BUT then in order to use the card elsewhere, we would have to do the subscription and lookup instead of the fund card handling its own data. In order to get data to the card we create an give.fund component and can populate the fund loading here. because of our router, if a fund is used within a /give/* page, all data that it needs will already be stored client side
# give.fund.coffee
class give.fund extends Apollos.component
@register "give.fund"
# subscribe to fund publication with filter on fund specified
subscriptions: -> [
"fund":
args: [
@.data()?.name
]
]
# populate helpers within template to show fund data
fund: ->
name = @.data()?.name
return Apollos.Funds.findOne({name: name})
Now we should have pictures and names for any funds in our database! With a little setup, you can render pages with Apollos.Router and Apollos.Layout. Now we need to setup the internal workings of the give.fund
card.
The makeup of this card is as follows:
Things we need to figure out:
@card true
will try to bind urls if the @.data().bindUrls is true (should this be default?)A card has a 1 to many relation ship with its card elements. Each element has the option to register a state and url of the parent card. An element can only register with ONE card. Cards are the outer bounds of card elements and they act as the controller and data storage for the elements. When a component is registered they set what card they belong to and their stateful name. Unless specified on the card, the first to register is the default state. Pages are ultimately responsible for the initial rendering of cards. A card will parse the url onRender to decide which state to render. Cards also have no knowledge about what page they are on or what layout they are using.
Card elements can sometimes become pages? How do they do this? Sermon entry, give fund, sign-in page, etc...
<a href="{{Apollos.state 'fund.summary'}}"></a>
<a href="{{Apollos.state 'fund.summary' from 'give.fund'}}"></a>
# give.fund.coffee
class give.fund extends Apollos.component
@register "give.fund"
@card true # sets this component as a card
vars: -> [
state: "fund.summary"
]
# subscribe to fund publication with filter on fund specified
subscriptions: -> [
"fund":
args: [
@.data()?.name
]
]
# populate helpers within template to show fund data
fund: ->
name = @.data()?.named
return Apollos.Funds.findOne({name: name})
# fund.summary.coffee
class fund.summary extends Apollos.component
@register "fund.summary"
@card "give.fund" # set this component to belong to "give.fund" card
# fund.vision.coffee
class fund.vision extends Apollos.component
@register "fund.vision"
@card "give.fund" # set this component to belong to "give.fund" card
url: "#{@.data()?.name}" # set url to update on render / read
# fund.addToFund.coffee
class fund.addToFund extends Apollos.component
@register "fund.addToFund"
@card "give.fund" # set this component to belong to "give.fund" card
url: "#{@.data()?.name}/add-to-fund" # set url to update on render / read
<!-- client/give.fund.html -->
<!--
What a normal card would look out just from a data standpoint
-->
<template name="give.fund">
{{#if subscriptionsReady}}
{{#with fund}}
{{> Template.dynamic template=state.get data=currentData}}
{{/with}}
{{else}}
{{! show loading state here}}
{{/if}}
</template>
card
implementation (markup)<!-- from this -->
<template name="Apollos.profile.onBoard">
{{!-- Spacebars does not have else if statements :( --}}
{{! Need to extend so we can have else if statements}}
{{#if resetPasswordToken}}
{{> resetPassword
email=email.get
}}
{{else}}
{{#if passwordForget.get}}
{{> forgotPassword
email=email.get
}}
{{else}}
{{#if Template.contentBlock}}
{{#signin
email=email.get
}}
{{> Template.contentBlock}}
{{/signin}}
{{else}}
{{>signin
email=email.get
}}
{{/if}}
{{/if}}
{{/if}}
</template>
<!-- to this -->
<template name="Apollos.profile.onBoard">
{{> Template.dynamic template=state.get data=currentData}}
</template>
This is for Heighliner. @delianides let me know if you need help with this.
Trying to create a new apollos user in production results in an error:
[45.55.213.136] Exception while invoking method 'createUser' TypeError: Object.keys called on non-object
at Function.keys (native)
at Apollos.user.create.Accounts.createUser.email (packages/newspring:apollos-core/lib/lib/apollos.js:100:1)
at Object.Accounts.insertUserDoc (packages/accounts-base/accounts_server.js:999:1)
[45.55.213.136] at createUser (packages/accounts-password/password_server.js:718:1)
at packages/accounts-password/password_server.js:738:1
at tryLoginMethod (packages/accounts-base/accounts_server.js:161:1)
at Object.Accounts._loginMethod (packages/accounts-base/accounts_server.js:277:1)
at [object Object].Meteor.methods.createUser (packages/accounts-password/password_server.js:724:1)
at maybeAuditArgumentChecks (packages/ddp/livedata_server.js:1617:1)
[45.55.213.136] at packages/ddp/livedata_server.js:648:1
I think the issue is here:
https://github.com/NewSpring/apollos-core/blob/master/_source/lib/apollos.coffee#L92
This should use the
<p><small><em>text</em></small></p>
formating. The link can be generated from rock.newspring.cc/group/leader?groupId=${id}
this issue should act as an easy way to check off / view scope of the community 0.5 MVP
The initial launch of community section of apollos sites and apps is focused around finding a community by location and / or know filters of a group. The data is fetched from Rock using Rock's api/Groups/ByLatLng
method which is already mapped in heighliner. The initial scope of community is as follows:
Most of these are already done as of Feb 24. We need to test and verify like crazy though and fix any bugs
Community needs the most work of all the features. The client side data management is kinda gross, the api call takes too long, and our textarea input isn't excellent. Pagination is setup in heighliner using first: 10, after: 11
arguments so its more the UI / data side we need to do. Everything should be in place to add a person to a group and send the email but we need to test it. Also, we need to add additional merge fields to the email template to include the note from the user. I also think we can remove the name field fwiw.
Thoughts on how we can make this happen in a week.
We all have our area's of speciality and I think we stick with those in this case to be the most efficient. Instead of owning features, I think we should own technology.
@samclaridge I think you should be in charge of final UI decisions, UI cleanup / polish, UI copy, and asset generation. This will probably amount to a lot of small PRs. The more the better.
@johnthepink you have the best expertise with React and MySQL. I think you should handle client side functionality and interactions with server side methods as well as any additional GQL mapping needed to function with EE (navee for instance).
@delianides infrastructure is your heart. Lets make it great (again). Take care of the protected branches, Circle integration, alerts / monitoring / dashboards. If there is time, lets look at the redis integration with GQL to see if we can do it better. I think we can.
I have the most experience with Rock, NMI, and the GQL server in general. I'll take those interactions and improvements.
This needs to be a fluid week with minimal overlap. To do this we need to over communicate. The room #systems room in slack is a good place for real time feedback. Also, assign yourself when working on an issue and mention people as needed. @delianides I'm going to need you to keep me up to date often on deployments and alerts / dashboards so we can make sure we have somewhere to launch too.
For git, do as best as possible as 1 issue : 1 PR. This helps us review, merge, and revert if necessary.
Go team go.
This should be by clicking your photo, but also by a link the settings page?
Thoughts @samclaridge? I know we also talked about hover over the image
During a sync from Rock to Apollos, I received an email address like this: "[email protected]". Our email regex says this is invalid. I found Rock's email validation regex, which says that email is valid.
We could deal with this by:
I've run in to a few issues like this when validating data received from Rock. For instance, we had a validation on birth year that it could not be less than 1900, but apparently there are people in Rock with birth years before 1900. I've dealt with those temporarily by turning off that validation.
http://localhost:3000/profile/edit/main
The image at the top should not be there because it makes me have to scroll to do the primary action of the page:
https://www.dropbox.com/s/uam6bhbjgpy2umm/Screenshot%202015-07-28%2014.14.23.png?dl=0
Form validations are acting strange. It looks like the Apollos.profile.information
disabled variable is getting set to false incorrectly. This allows you to move through the forms without providing the correct information. I tried to track it down, but filing the issue so we can come back to it later.
Also need to ensure next payment date is saved in Rock
ResetUrl
, UserLogin
, and Person
as the data passed to the {{Lava}}
templatePer SparkDevNetwork/Rock@ea96dfd we should be able to remove the LavaJS implementation in Apollos currently. We need to verify this via a POST, then update the communication method to use the AdditionalMergeJSON
fields.
Should be setup in Rock. Will need the Person
and UserLogin
model passed into it and used in the {{Lava}}
template. Check with @jonhorton, he's got plans.
I'd like to loop moleman in on this. I think he would do a great job. Would he be open to doing it as a favor?
Lets reuses as many existing patterns as possible. This will be in modal (so mobile only UI needed)
@delianides there is an open PR on Heighliner for the application modifications for this. We need the cert installed (should be already on Rancher yes?)
This is the trigger Kristin has setup in Rock to alert finance. We need to verify this works for recovering a schedule
@samclaridge if we had a few stories to pull from that would be great.
@johnthepink can we pull from our content channel with a tag of giving? (Not needed for launch, these can be hardcoded)
@samclaridge we should be able to this 100% with css. I thought I had the code somewhere for this but I guess not. I think we could add it to the global template under <Modal />
this issue should act as an easy way to check off / view scope of the general apollos framework for 1.0 MVP
The initial scope of apollos is shared between my.newspring.cc (newwwwspring.cc repo) and the newspring-app. It handles communication with the GraphQL server and with Rock, and sets the base for future work done by the Systems team. This issue is a catch all for misc features needed by launch:
All in all we need to set a style guide for things in Apollos. At this point I think we have worked enough to see some pain points and what is helpful. Leh go!
In no order:
<top-level-segment>.group
(eg. give.group contains all pages that are found at /give)(more to come)
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.