2017-06-23 06:07:04 +08:00
|
|
|
|
import {Actions, TaskQueue} from 'nylas-exports'
|
feat(usage): Add a FeatureUsageStore and move Identity to the DB
Summary:
This is a WIP
Depends on D3799 on billing.nylas.com
This adds a `FeatureUsageStore` which determines whether a feature can be
used or not. It also allows us to record "using" a feature.
Feature Usage is ultimately backed by the Nylas Identity and cached
locally in the Identity object. Since feature usage is attached to the
Nylas Identity, we move the whole Identity object (except for the ID) to
the database.
This includes a migration (with tests!) to move the Nylas Identity from
the config into the Database. We still, however, need the Nylas ID to stay
in the config so it can be synchronously accessed by the /browser process
on bootup when determining what windows to show. It's also convenient to
know what the Nylas ID is by looking at the config. There's logic (with
tests!) to make sure these stay in sync. If you delete the Nylas ID from
the config, it'll be the same as logging you out.
The schema for the feature usage can be found in more detail on D3799. By
the time it reaches Nylas Mail, the Nylas ID object has a `feature_usage`
attribute that has each feature (keyed by the feature name) and
information about the plans attached to it. The schema Nylas Mail sees
looks like:
```
"feature_usage": {
"snooze": {
quota: 10,
peroid: 'monthly',
used_in_period: 8,
feature_limit_name: 'Snooze Group A',
},
}
```
See D3799 for more info about how these are generated.
One final change that's in here is how Stores are loaded. Most of our
core stores are loaded at require time, but now things like the
IdentityStore need to do asynchronous things on activation. In reality
most of our stores do this and it's a miracle it hasn't caused more
problems! Now when stores activate we optionally look for an `activate`
method and `await` for it. This was necessary so downstream classes (like
the Onboarding Store), see a fully initialized IdentityStore by the time
it's time to use them
Test Plan: New tests!
Reviewers: khamidou, juan, halla
Reviewed By: juan
Differential Revision: https://phab.nylas.com/D3808
2017-02-04 07:31:31 +08:00
|
|
|
|
import FeatureUsageStore from '../../src/flux/stores/feature-usage-store'
|
|
|
|
|
import IdentityStore from '../../src/flux/stores/identity-store'
|
|
|
|
|
|
|
|
|
|
describe("FeatureUsageStore", function featureUsageStoreSpec() {
|
|
|
|
|
beforeEach(() => {
|
|
|
|
|
this.oldIdent = IdentityStore._identity;
|
|
|
|
|
IdentityStore._identity = {id: 'foo'}
|
2017-08-23 12:49:45 +08:00
|
|
|
|
IdentityStore._identity.featureUsage = {
|
feat(usage): Add a FeatureUsageStore and move Identity to the DB
Summary:
This is a WIP
Depends on D3799 on billing.nylas.com
This adds a `FeatureUsageStore` which determines whether a feature can be
used or not. It also allows us to record "using" a feature.
Feature Usage is ultimately backed by the Nylas Identity and cached
locally in the Identity object. Since feature usage is attached to the
Nylas Identity, we move the whole Identity object (except for the ID) to
the database.
This includes a migration (with tests!) to move the Nylas Identity from
the config into the Database. We still, however, need the Nylas ID to stay
in the config so it can be synchronously accessed by the /browser process
on bootup when determining what windows to show. It's also convenient to
know what the Nylas ID is by looking at the config. There's logic (with
tests!) to make sure these stay in sync. If you delete the Nylas ID from
the config, it'll be the same as logging you out.
The schema for the feature usage can be found in more detail on D3799. By
the time it reaches Nylas Mail, the Nylas ID object has a `feature_usage`
attribute that has each feature (keyed by the feature name) and
information about the plans attached to it. The schema Nylas Mail sees
looks like:
```
"feature_usage": {
"snooze": {
quota: 10,
peroid: 'monthly',
used_in_period: 8,
feature_limit_name: 'Snooze Group A',
},
}
```
See D3799 for more info about how these are generated.
One final change that's in here is how Stores are loaded. Most of our
core stores are loaded at require time, but now things like the
IdentityStore need to do asynchronous things on activation. In reality
most of our stores do this and it's a miracle it hasn't caused more
problems! Now when stores activate we optionally look for an `activate`
method and `await` for it. This was necessary so downstream classes (like
the Onboarding Store), see a fully initialized IdentityStore by the time
it's time to use them
Test Plan: New tests!
Reviewers: khamidou, juan, halla
Reviewed By: juan
Differential Revision: https://phab.nylas.com/D3808
2017-02-04 07:31:31 +08:00
|
|
|
|
"is-usable": {
|
|
|
|
|
quota: 10,
|
2017-03-07 03:45:55 +08:00
|
|
|
|
period: 'monthly',
|
2017-08-23 12:49:45 +08:00
|
|
|
|
usedInPeriod: 8,
|
|
|
|
|
featureLimitName: 'Usable Group A',
|
feat(usage): Add a FeatureUsageStore and move Identity to the DB
Summary:
This is a WIP
Depends on D3799 on billing.nylas.com
This adds a `FeatureUsageStore` which determines whether a feature can be
used or not. It also allows us to record "using" a feature.
Feature Usage is ultimately backed by the Nylas Identity and cached
locally in the Identity object. Since feature usage is attached to the
Nylas Identity, we move the whole Identity object (except for the ID) to
the database.
This includes a migration (with tests!) to move the Nylas Identity from
the config into the Database. We still, however, need the Nylas ID to stay
in the config so it can be synchronously accessed by the /browser process
on bootup when determining what windows to show. It's also convenient to
know what the Nylas ID is by looking at the config. There's logic (with
tests!) to make sure these stay in sync. If you delete the Nylas ID from
the config, it'll be the same as logging you out.
The schema for the feature usage can be found in more detail on D3799. By
the time it reaches Nylas Mail, the Nylas ID object has a `feature_usage`
attribute that has each feature (keyed by the feature name) and
information about the plans attached to it. The schema Nylas Mail sees
looks like:
```
"feature_usage": {
"snooze": {
quota: 10,
peroid: 'monthly',
used_in_period: 8,
feature_limit_name: 'Snooze Group A',
},
}
```
See D3799 for more info about how these are generated.
One final change that's in here is how Stores are loaded. Most of our
core stores are loaded at require time, but now things like the
IdentityStore need to do asynchronous things on activation. In reality
most of our stores do this and it's a miracle it hasn't caused more
problems! Now when stores activate we optionally look for an `activate`
method and `await` for it. This was necessary so downstream classes (like
the Onboarding Store), see a fully initialized IdentityStore by the time
it's time to use them
Test Plan: New tests!
Reviewers: khamidou, juan, halla
Reviewed By: juan
Differential Revision: https://phab.nylas.com/D3808
2017-02-04 07:31:31 +08:00
|
|
|
|
},
|
|
|
|
|
"not-usable": {
|
|
|
|
|
quota: 10,
|
2017-03-07 03:45:55 +08:00
|
|
|
|
period: 'monthly',
|
2017-08-23 12:49:45 +08:00
|
|
|
|
usedInPeriod: 10,
|
|
|
|
|
featureLimitName: 'Unusable Group A',
|
feat(usage): Add a FeatureUsageStore and move Identity to the DB
Summary:
This is a WIP
Depends on D3799 on billing.nylas.com
This adds a `FeatureUsageStore` which determines whether a feature can be
used or not. It also allows us to record "using" a feature.
Feature Usage is ultimately backed by the Nylas Identity and cached
locally in the Identity object. Since feature usage is attached to the
Nylas Identity, we move the whole Identity object (except for the ID) to
the database.
This includes a migration (with tests!) to move the Nylas Identity from
the config into the Database. We still, however, need the Nylas ID to stay
in the config so it can be synchronously accessed by the /browser process
on bootup when determining what windows to show. It's also convenient to
know what the Nylas ID is by looking at the config. There's logic (with
tests!) to make sure these stay in sync. If you delete the Nylas ID from
the config, it'll be the same as logging you out.
The schema for the feature usage can be found in more detail on D3799. By
the time it reaches Nylas Mail, the Nylas ID object has a `feature_usage`
attribute that has each feature (keyed by the feature name) and
information about the plans attached to it. The schema Nylas Mail sees
looks like:
```
"feature_usage": {
"snooze": {
quota: 10,
peroid: 'monthly',
used_in_period: 8,
feature_limit_name: 'Snooze Group A',
},
}
```
See D3799 for more info about how these are generated.
One final change that's in here is how Stores are loaded. Most of our
core stores are loaded at require time, but now things like the
IdentityStore need to do asynchronous things on activation. In reality
most of our stores do this and it's a miracle it hasn't caused more
problems! Now when stores activate we optionally look for an `activate`
method and `await` for it. This was necessary so downstream classes (like
the Onboarding Store), see a fully initialized IdentityStore by the time
it's time to use them
Test Plan: New tests!
Reviewers: khamidou, juan, halla
Reviewed By: juan
Differential Revision: https://phab.nylas.com/D3808
2017-02-04 07:31:31 +08:00
|
|
|
|
},
|
|
|
|
|
}
|
|
|
|
|
});
|
|
|
|
|
|
|
|
|
|
afterEach(() => {
|
|
|
|
|
IdentityStore._identity = this.oldIdent
|
|
|
|
|
});
|
|
|
|
|
|
2017-03-07 03:45:55 +08:00
|
|
|
|
describe("_isUsable", () => {
|
feat(usage): Add a FeatureUsageStore and move Identity to the DB
Summary:
This is a WIP
Depends on D3799 on billing.nylas.com
This adds a `FeatureUsageStore` which determines whether a feature can be
used or not. It also allows us to record "using" a feature.
Feature Usage is ultimately backed by the Nylas Identity and cached
locally in the Identity object. Since feature usage is attached to the
Nylas Identity, we move the whole Identity object (except for the ID) to
the database.
This includes a migration (with tests!) to move the Nylas Identity from
the config into the Database. We still, however, need the Nylas ID to stay
in the config so it can be synchronously accessed by the /browser process
on bootup when determining what windows to show. It's also convenient to
know what the Nylas ID is by looking at the config. There's logic (with
tests!) to make sure these stay in sync. If you delete the Nylas ID from
the config, it'll be the same as logging you out.
The schema for the feature usage can be found in more detail on D3799. By
the time it reaches Nylas Mail, the Nylas ID object has a `feature_usage`
attribute that has each feature (keyed by the feature name) and
information about the plans attached to it. The schema Nylas Mail sees
looks like:
```
"feature_usage": {
"snooze": {
quota: 10,
peroid: 'monthly',
used_in_period: 8,
feature_limit_name: 'Snooze Group A',
},
}
```
See D3799 for more info about how these are generated.
One final change that's in here is how Stores are loaded. Most of our
core stores are loaded at require time, but now things like the
IdentityStore need to do asynchronous things on activation. In reality
most of our stores do this and it's a miracle it hasn't caused more
problems! Now when stores activate we optionally look for an `activate`
method and `await` for it. This was necessary so downstream classes (like
the Onboarding Store), see a fully initialized IdentityStore by the time
it's time to use them
Test Plan: New tests!
Reviewers: khamidou, juan, halla
Reviewed By: juan
Differential Revision: https://phab.nylas.com/D3808
2017-02-04 07:31:31 +08:00
|
|
|
|
it("returns true if a feature hasn't met it's quota", () => {
|
2017-03-07 03:45:55 +08:00
|
|
|
|
expect(FeatureUsageStore._isUsable("is-usable")).toBe(true)
|
feat(usage): Add a FeatureUsageStore and move Identity to the DB
Summary:
This is a WIP
Depends on D3799 on billing.nylas.com
This adds a `FeatureUsageStore` which determines whether a feature can be
used or not. It also allows us to record "using" a feature.
Feature Usage is ultimately backed by the Nylas Identity and cached
locally in the Identity object. Since feature usage is attached to the
Nylas Identity, we move the whole Identity object (except for the ID) to
the database.
This includes a migration (with tests!) to move the Nylas Identity from
the config into the Database. We still, however, need the Nylas ID to stay
in the config so it can be synchronously accessed by the /browser process
on bootup when determining what windows to show. It's also convenient to
know what the Nylas ID is by looking at the config. There's logic (with
tests!) to make sure these stay in sync. If you delete the Nylas ID from
the config, it'll be the same as logging you out.
The schema for the feature usage can be found in more detail on D3799. By
the time it reaches Nylas Mail, the Nylas ID object has a `feature_usage`
attribute that has each feature (keyed by the feature name) and
information about the plans attached to it. The schema Nylas Mail sees
looks like:
```
"feature_usage": {
"snooze": {
quota: 10,
peroid: 'monthly',
used_in_period: 8,
feature_limit_name: 'Snooze Group A',
},
}
```
See D3799 for more info about how these are generated.
One final change that's in here is how Stores are loaded. Most of our
core stores are loaded at require time, but now things like the
IdentityStore need to do asynchronous things on activation. In reality
most of our stores do this and it's a miracle it hasn't caused more
problems! Now when stores activate we optionally look for an `activate`
method and `await` for it. This was necessary so downstream classes (like
the Onboarding Store), see a fully initialized IdentityStore by the time
it's time to use them
Test Plan: New tests!
Reviewers: khamidou, juan, halla
Reviewed By: juan
Differential Revision: https://phab.nylas.com/D3808
2017-02-04 07:31:31 +08:00
|
|
|
|
});
|
|
|
|
|
|
|
|
|
|
it("returns false if a feature is at its quota", () => {
|
2017-03-07 03:45:55 +08:00
|
|
|
|
expect(FeatureUsageStore._isUsable("not-usable")).toBe(false)
|
feat(usage): Add a FeatureUsageStore and move Identity to the DB
Summary:
This is a WIP
Depends on D3799 on billing.nylas.com
This adds a `FeatureUsageStore` which determines whether a feature can be
used or not. It also allows us to record "using" a feature.
Feature Usage is ultimately backed by the Nylas Identity and cached
locally in the Identity object. Since feature usage is attached to the
Nylas Identity, we move the whole Identity object (except for the ID) to
the database.
This includes a migration (with tests!) to move the Nylas Identity from
the config into the Database. We still, however, need the Nylas ID to stay
in the config so it can be synchronously accessed by the /browser process
on bootup when determining what windows to show. It's also convenient to
know what the Nylas ID is by looking at the config. There's logic (with
tests!) to make sure these stay in sync. If you delete the Nylas ID from
the config, it'll be the same as logging you out.
The schema for the feature usage can be found in more detail on D3799. By
the time it reaches Nylas Mail, the Nylas ID object has a `feature_usage`
attribute that has each feature (keyed by the feature name) and
information about the plans attached to it. The schema Nylas Mail sees
looks like:
```
"feature_usage": {
"snooze": {
quota: 10,
peroid: 'monthly',
used_in_period: 8,
feature_limit_name: 'Snooze Group A',
},
}
```
See D3799 for more info about how these are generated.
One final change that's in here is how Stores are loaded. Most of our
core stores are loaded at require time, but now things like the
IdentityStore need to do asynchronous things on activation. In reality
most of our stores do this and it's a miracle it hasn't caused more
problems! Now when stores activate we optionally look for an `activate`
method and `await` for it. This was necessary so downstream classes (like
the Onboarding Store), see a fully initialized IdentityStore by the time
it's time to use them
Test Plan: New tests!
Reviewers: khamidou, juan, halla
Reviewed By: juan
Differential Revision: https://phab.nylas.com/D3808
2017-02-04 07:31:31 +08:00
|
|
|
|
});
|
|
|
|
|
|
|
|
|
|
it("warns if asking for an unsupported feature", () => {
|
|
|
|
|
spyOn(NylasEnv, "reportError")
|
2017-03-07 03:45:55 +08:00
|
|
|
|
expect(FeatureUsageStore._isUsable("unsupported")).toBe(false)
|
feat(usage): Add a FeatureUsageStore and move Identity to the DB
Summary:
This is a WIP
Depends on D3799 on billing.nylas.com
This adds a `FeatureUsageStore` which determines whether a feature can be
used or not. It also allows us to record "using" a feature.
Feature Usage is ultimately backed by the Nylas Identity and cached
locally in the Identity object. Since feature usage is attached to the
Nylas Identity, we move the whole Identity object (except for the ID) to
the database.
This includes a migration (with tests!) to move the Nylas Identity from
the config into the Database. We still, however, need the Nylas ID to stay
in the config so it can be synchronously accessed by the /browser process
on bootup when determining what windows to show. It's also convenient to
know what the Nylas ID is by looking at the config. There's logic (with
tests!) to make sure these stay in sync. If you delete the Nylas ID from
the config, it'll be the same as logging you out.
The schema for the feature usage can be found in more detail on D3799. By
the time it reaches Nylas Mail, the Nylas ID object has a `feature_usage`
attribute that has each feature (keyed by the feature name) and
information about the plans attached to it. The schema Nylas Mail sees
looks like:
```
"feature_usage": {
"snooze": {
quota: 10,
peroid: 'monthly',
used_in_period: 8,
feature_limit_name: 'Snooze Group A',
},
}
```
See D3799 for more info about how these are generated.
One final change that's in here is how Stores are loaded. Most of our
core stores are loaded at require time, but now things like the
IdentityStore need to do asynchronous things on activation. In reality
most of our stores do this and it's a miracle it hasn't caused more
problems! Now when stores activate we optionally look for an `activate`
method and `await` for it. This was necessary so downstream classes (like
the Onboarding Store), see a fully initialized IdentityStore by the time
it's time to use them
Test Plan: New tests!
Reviewers: khamidou, juan, halla
Reviewed By: juan
Differential Revision: https://phab.nylas.com/D3808
2017-02-04 07:31:31 +08:00
|
|
|
|
expect(NylasEnv.reportError).toHaveBeenCalled()
|
|
|
|
|
});
|
|
|
|
|
});
|
|
|
|
|
|
2017-03-07 03:45:55 +08:00
|
|
|
|
describe("_markFeatureUsed", () => {
|
feat(usage): Add a FeatureUsageStore and move Identity to the DB
Summary:
This is a WIP
Depends on D3799 on billing.nylas.com
This adds a `FeatureUsageStore` which determines whether a feature can be
used or not. It also allows us to record "using" a feature.
Feature Usage is ultimately backed by the Nylas Identity and cached
locally in the Identity object. Since feature usage is attached to the
Nylas Identity, we move the whole Identity object (except for the ID) to
the database.
This includes a migration (with tests!) to move the Nylas Identity from
the config into the Database. We still, however, need the Nylas ID to stay
in the config so it can be synchronously accessed by the /browser process
on bootup when determining what windows to show. It's also convenient to
know what the Nylas ID is by looking at the config. There's logic (with
tests!) to make sure these stay in sync. If you delete the Nylas ID from
the config, it'll be the same as logging you out.
The schema for the feature usage can be found in more detail on D3799. By
the time it reaches Nylas Mail, the Nylas ID object has a `feature_usage`
attribute that has each feature (keyed by the feature name) and
information about the plans attached to it. The schema Nylas Mail sees
looks like:
```
"feature_usage": {
"snooze": {
quota: 10,
peroid: 'monthly',
used_in_period: 8,
feature_limit_name: 'Snooze Group A',
},
}
```
See D3799 for more info about how these are generated.
One final change that's in here is how Stores are loaded. Most of our
core stores are loaded at require time, but now things like the
IdentityStore need to do asynchronous things on activation. In reality
most of our stores do this and it's a miracle it hasn't caused more
problems! Now when stores activate we optionally look for an `activate`
method and `await` for it. This was necessary so downstream classes (like
the Onboarding Store), see a fully initialized IdentityStore by the time
it's time to use them
Test Plan: New tests!
Reviewers: khamidou, juan, halla
Reviewed By: juan
Differential Revision: https://phab.nylas.com/D3808
2017-02-04 07:31:31 +08:00
|
|
|
|
beforeEach(() => {
|
2017-08-23 12:49:45 +08:00
|
|
|
|
spyOn(Actions, 'queueTask');
|
feat(usage): Add a FeatureUsageStore and move Identity to the DB
Summary:
This is a WIP
Depends on D3799 on billing.nylas.com
This adds a `FeatureUsageStore` which determines whether a feature can be
used or not. It also allows us to record "using" a feature.
Feature Usage is ultimately backed by the Nylas Identity and cached
locally in the Identity object. Since feature usage is attached to the
Nylas Identity, we move the whole Identity object (except for the ID) to
the database.
This includes a migration (with tests!) to move the Nylas Identity from
the config into the Database. We still, however, need the Nylas ID to stay
in the config so it can be synchronously accessed by the /browser process
on bootup when determining what windows to show. It's also convenient to
know what the Nylas ID is by looking at the config. There's logic (with
tests!) to make sure these stay in sync. If you delete the Nylas ID from
the config, it'll be the same as logging you out.
The schema for the feature usage can be found in more detail on D3799. By
the time it reaches Nylas Mail, the Nylas ID object has a `feature_usage`
attribute that has each feature (keyed by the feature name) and
information about the plans attached to it. The schema Nylas Mail sees
looks like:
```
"feature_usage": {
"snooze": {
quota: 10,
peroid: 'monthly',
used_in_period: 8,
feature_limit_name: 'Snooze Group A',
},
}
```
See D3799 for more info about how these are generated.
One final change that's in here is how Stores are loaded. Most of our
core stores are loaded at require time, but now things like the
IdentityStore need to do asynchronous things on activation. In reality
most of our stores do this and it's a miracle it hasn't caused more
problems! Now when stores activate we optionally look for an `activate`
method and `await` for it. This was necessary so downstream classes (like
the Onboarding Store), see a fully initialized IdentityStore by the time
it's time to use them
Test Plan: New tests!
Reviewers: khamidou, juan, halla
Reviewed By: juan
Differential Revision: https://phab.nylas.com/D3808
2017-02-04 07:31:31 +08:00
|
|
|
|
spyOn(IdentityStore, "saveIdentity").andCallFake((ident) => {
|
|
|
|
|
IdentityStore._identity = ident
|
|
|
|
|
})
|
|
|
|
|
});
|
|
|
|
|
|
2017-02-11 05:49:40 +08:00
|
|
|
|
afterEach(() => {
|
2017-08-23 12:49:45 +08:00
|
|
|
|
TaskQueue._queue = [];
|
|
|
|
|
})
|
|
|
|
|
|
|
|
|
|
it("immediately increments the identity counter", () => {
|
|
|
|
|
const before = IdentityStore._identity.featureUsage['is-usable'].usedInPeriod;
|
|
|
|
|
FeatureUsageStore._markFeatureUsed('is-usable');
|
|
|
|
|
const after = IdentityStore._identity.featureUsage['is-usable'].usedInPeriod;
|
|
|
|
|
expect(after).toEqual(before + 1);
|
2017-02-11 05:49:40 +08:00
|
|
|
|
})
|
|
|
|
|
|
2017-08-23 12:49:45 +08:00
|
|
|
|
it("queues a task to sync the optimistic changes to the server", () => {
|
|
|
|
|
FeatureUsageStore._markFeatureUsed('is-usable');
|
|
|
|
|
expect(Actions.queueTask).toHaveBeenCalled();
|
feat(usage): Add a FeatureUsageStore and move Identity to the DB
Summary:
This is a WIP
Depends on D3799 on billing.nylas.com
This adds a `FeatureUsageStore` which determines whether a feature can be
used or not. It also allows us to record "using" a feature.
Feature Usage is ultimately backed by the Nylas Identity and cached
locally in the Identity object. Since feature usage is attached to the
Nylas Identity, we move the whole Identity object (except for the ID) to
the database.
This includes a migration (with tests!) to move the Nylas Identity from
the config into the Database. We still, however, need the Nylas ID to stay
in the config so it can be synchronously accessed by the /browser process
on bootup when determining what windows to show. It's also convenient to
know what the Nylas ID is by looking at the config. There's logic (with
tests!) to make sure these stay in sync. If you delete the Nylas ID from
the config, it'll be the same as logging you out.
The schema for the feature usage can be found in more detail on D3799. By
the time it reaches Nylas Mail, the Nylas ID object has a `feature_usage`
attribute that has each feature (keyed by the feature name) and
information about the plans attached to it. The schema Nylas Mail sees
looks like:
```
"feature_usage": {
"snooze": {
quota: 10,
peroid: 'monthly',
used_in_period: 8,
feature_limit_name: 'Snooze Group A',
},
}
```
See D3799 for more info about how these are generated.
One final change that's in here is how Stores are loaded. Most of our
core stores are loaded at require time, but now things like the
IdentityStore need to do asynchronous things on activation. In reality
most of our stores do this and it's a miracle it hasn't caused more
problems! Now when stores activate we optionally look for an `activate`
method and `await` for it. This was necessary so downstream classes (like
the Onboarding Store), see a fully initialized IdentityStore by the time
it's time to use them
Test Plan: New tests!
Reviewers: khamidou, juan, halla
Reviewed By: juan
Differential Revision: https://phab.nylas.com/D3808
2017-02-04 07:31:31 +08:00
|
|
|
|
});
|
2017-03-07 03:45:55 +08:00
|
|
|
|
});
|
feat(usage): Add a FeatureUsageStore and move Identity to the DB
Summary:
This is a WIP
Depends on D3799 on billing.nylas.com
This adds a `FeatureUsageStore` which determines whether a feature can be
used or not. It also allows us to record "using" a feature.
Feature Usage is ultimately backed by the Nylas Identity and cached
locally in the Identity object. Since feature usage is attached to the
Nylas Identity, we move the whole Identity object (except for the ID) to
the database.
This includes a migration (with tests!) to move the Nylas Identity from
the config into the Database. We still, however, need the Nylas ID to stay
in the config so it can be synchronously accessed by the /browser process
on bootup when determining what windows to show. It's also convenient to
know what the Nylas ID is by looking at the config. There's logic (with
tests!) to make sure these stay in sync. If you delete the Nylas ID from
the config, it'll be the same as logging you out.
The schema for the feature usage can be found in more detail on D3799. By
the time it reaches Nylas Mail, the Nylas ID object has a `feature_usage`
attribute that has each feature (keyed by the feature name) and
information about the plans attached to it. The schema Nylas Mail sees
looks like:
```
"feature_usage": {
"snooze": {
quota: 10,
peroid: 'monthly',
used_in_period: 8,
feature_limit_name: 'Snooze Group A',
},
}
```
See D3799 for more info about how these are generated.
One final change that's in here is how Stores are loaded. Most of our
core stores are loaded at require time, but now things like the
IdentityStore need to do asynchronous things on activation. In reality
most of our stores do this and it's a miracle it hasn't caused more
problems! Now when stores activate we optionally look for an `activate`
method and `await` for it. This was necessary so downstream classes (like
the Onboarding Store), see a fully initialized IdentityStore by the time
it's time to use them
Test Plan: New tests!
Reviewers: khamidou, juan, halla
Reviewed By: juan
Differential Revision: https://phab.nylas.com/D3808
2017-02-04 07:31:31 +08:00
|
|
|
|
|
2017-03-07 03:45:55 +08:00
|
|
|
|
describe("use feature", () => {
|
|
|
|
|
beforeEach(() => {
|
|
|
|
|
spyOn(FeatureUsageStore, "_markFeatureUsed").andReturn(Promise.resolve());
|
|
|
|
|
spyOn(Actions, "openModal")
|
feat(usage): Add a FeatureUsageStore and move Identity to the DB
Summary:
This is a WIP
Depends on D3799 on billing.nylas.com
This adds a `FeatureUsageStore` which determines whether a feature can be
used or not. It also allows us to record "using" a feature.
Feature Usage is ultimately backed by the Nylas Identity and cached
locally in the Identity object. Since feature usage is attached to the
Nylas Identity, we move the whole Identity object (except for the ID) to
the database.
This includes a migration (with tests!) to move the Nylas Identity from
the config into the Database. We still, however, need the Nylas ID to stay
in the config so it can be synchronously accessed by the /browser process
on bootup when determining what windows to show. It's also convenient to
know what the Nylas ID is by looking at the config. There's logic (with
tests!) to make sure these stay in sync. If you delete the Nylas ID from
the config, it'll be the same as logging you out.
The schema for the feature usage can be found in more detail on D3799. By
the time it reaches Nylas Mail, the Nylas ID object has a `feature_usage`
attribute that has each feature (keyed by the feature name) and
information about the plans attached to it. The schema Nylas Mail sees
looks like:
```
"feature_usage": {
"snooze": {
quota: 10,
peroid: 'monthly',
used_in_period: 8,
feature_limit_name: 'Snooze Group A',
},
}
```
See D3799 for more info about how these are generated.
One final change that's in here is how Stores are loaded. Most of our
core stores are loaded at require time, but now things like the
IdentityStore need to do asynchronous things on activation. In reality
most of our stores do this and it's a miracle it hasn't caused more
problems! Now when stores activate we optionally look for an `activate`
method and `await` for it. This was necessary so downstream classes (like
the Onboarding Store), see a fully initialized IdentityStore by the time
it's time to use them
Test Plan: New tests!
Reviewers: khamidou, juan, halla
Reviewed By: juan
Differential Revision: https://phab.nylas.com/D3808
2017-02-04 07:31:31 +08:00
|
|
|
|
});
|
|
|
|
|
|
2017-03-07 03:45:55 +08:00
|
|
|
|
it("marks the feature used if it's usable", async () => {
|
|
|
|
|
await FeatureUsageStore.asyncUseFeature('is-usable')
|
|
|
|
|
expect(FeatureUsageStore._markFeatureUsed).toHaveBeenCalled();
|
|
|
|
|
expect(FeatureUsageStore._markFeatureUsed.callCount).toBe(1);
|
|
|
|
|
});
|
|
|
|
|
|
|
|
|
|
describe("showing modal", () => {
|
|
|
|
|
beforeEach(() => {
|
|
|
|
|
this.lexicon = {
|
|
|
|
|
displayName: "Test Name",
|
|
|
|
|
rechargeCTA: "recharge me",
|
|
|
|
|
usedUpHeader: "all test used",
|
|
|
|
|
iconUrl: "icon url",
|
|
|
|
|
}
|
|
|
|
|
});
|
|
|
|
|
|
|
|
|
|
it("resolves the modal if you upgrade", async () => {
|
|
|
|
|
setImmediate(() => {
|
|
|
|
|
FeatureUsageStore._onModalClose()
|
|
|
|
|
})
|
|
|
|
|
await FeatureUsageStore.asyncUseFeature('not-usable', {lexicon: this.lexicon});
|
|
|
|
|
expect(Actions.openModal).toHaveBeenCalled();
|
|
|
|
|
expect(Actions.openModal.calls.length).toBe(1)
|
|
|
|
|
});
|
|
|
|
|
|
|
|
|
|
it("pops open a modal with the correct text", async () => {
|
|
|
|
|
setImmediate(() => {
|
|
|
|
|
FeatureUsageStore._onModalClose()
|
|
|
|
|
})
|
|
|
|
|
await FeatureUsageStore.asyncUseFeature('not-usable', {lexicon: this.lexicon});
|
|
|
|
|
expect(Actions.openModal).toHaveBeenCalled();
|
|
|
|
|
expect(Actions.openModal.calls.length).toBe(1)
|
|
|
|
|
const component = Actions.openModal.calls[0].args[0].component;
|
|
|
|
|
expect(component.props).toEqual({
|
|
|
|
|
modalClass: "not-usable",
|
|
|
|
|
featureName: "Test Name",
|
|
|
|
|
headerText: "all test used",
|
|
|
|
|
iconUrl: "icon url",
|
|
|
|
|
rechargeText: "You’ll have 10 more next month",
|
|
|
|
|
})
|
|
|
|
|
});
|
|
|
|
|
|
|
|
|
|
it("rejects if you don't upgrade", async () => {
|
|
|
|
|
let caughtError = false;
|
|
|
|
|
setImmediate(() => {
|
|
|
|
|
FeatureUsageStore._onModalClose()
|
|
|
|
|
})
|
|
|
|
|
try {
|
|
|
|
|
await FeatureUsageStore.asyncUseFeature('not-usable', {lexicon: this.lexicon});
|
|
|
|
|
} catch (err) {
|
2017-08-23 12:49:45 +08:00
|
|
|
|
expect(err instanceof FeatureUsageStore.NoProAccessError).toBe(true)
|
2017-03-07 03:45:55 +08:00
|
|
|
|
caughtError = true;
|
|
|
|
|
}
|
|
|
|
|
expect(caughtError).toBe(true)
|
|
|
|
|
});
|
feat(usage): Add a FeatureUsageStore and move Identity to the DB
Summary:
This is a WIP
Depends on D3799 on billing.nylas.com
This adds a `FeatureUsageStore` which determines whether a feature can be
used or not. It also allows us to record "using" a feature.
Feature Usage is ultimately backed by the Nylas Identity and cached
locally in the Identity object. Since feature usage is attached to the
Nylas Identity, we move the whole Identity object (except for the ID) to
the database.
This includes a migration (with tests!) to move the Nylas Identity from
the config into the Database. We still, however, need the Nylas ID to stay
in the config so it can be synchronously accessed by the /browser process
on bootup when determining what windows to show. It's also convenient to
know what the Nylas ID is by looking at the config. There's logic (with
tests!) to make sure these stay in sync. If you delete the Nylas ID from
the config, it'll be the same as logging you out.
The schema for the feature usage can be found in more detail on D3799. By
the time it reaches Nylas Mail, the Nylas ID object has a `feature_usage`
attribute that has each feature (keyed by the feature name) and
information about the plans attached to it. The schema Nylas Mail sees
looks like:
```
"feature_usage": {
"snooze": {
quota: 10,
peroid: 'monthly',
used_in_period: 8,
feature_limit_name: 'Snooze Group A',
},
}
```
See D3799 for more info about how these are generated.
One final change that's in here is how Stores are loaded. Most of our
core stores are loaded at require time, but now things like the
IdentityStore need to do asynchronous things on activation. In reality
most of our stores do this and it's a miracle it hasn't caused more
problems! Now when stores activate we optionally look for an `activate`
method and `await` for it. This was necessary so downstream classes (like
the Onboarding Store), see a fully initialized IdentityStore by the time
it's time to use them
Test Plan: New tests!
Reviewers: khamidou, juan, halla
Reviewed By: juan
Differential Revision: https://phab.nylas.com/D3808
2017-02-04 07:31:31 +08:00
|
|
|
|
});
|
|
|
|
|
});
|
|
|
|
|
});
|