Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Trial period when enterprise is enabled should count from the moment enterprise was enabled, not when Grist was installed #1140

Closed
jordigh opened this issue Jul 30, 2024 · 0 comments
Closed

Trial period when enterprise is enabled should count from the moment enterprise was enabled, not when Grist was installed #1140

jordigh opened this issue Jul 30, 2024 · 0 comments
Labels
self-hosting Self-hosting setup that needs some love

Comments

@jordigh
Copy link
Contributor

jordigh commented Jul 30, 2024

When Grist is first installed, an activation entity is created in the database with the current timestamp:

https://github.com/gristlabs/grist-core/blob/main/app/server/lib/FlexServer.ts#L767

This is the timestamp that is used to count the number of days in the trial period when enterprised is enabled.

It should instead be counting from the moment that the Enterprise toggle was hit.
@jordigh jordigh added the self-hosting Self-hosting setup that needs some love label Jul 30, 2024
jordigh added a commit that referenced this issue Aug 1, 2024
@jordigh
Activations: add an enabled_at column
d087298 
For #1140, I considered trying to use the existing fields in a better
way, but because we already use the activations table to store
preferences, we need to keep all of the existing data and its usage
as-is.

The enterprise code will use this new column to decide how long the
trial period should be.
@jordigh jordigh mentioned this issue Aug 1, 2024
Merged
jordigh added a commit that referenced this issue Aug 1, 2024
@jordigh
Activations: add an enabled_at column
ec46233 
For #1140, I considered trying to use the existing fields in a better
way, but because we already use the activations table to store
preferences, we need to keep all of the existing data and its usage
as-is.

The enterprise code will use this new column to decide how long the
trial period should be.
jordigh added a commit that referenced this issue Aug 1, 2024
@jordigh
Activations: add an enabled_at column
07c43d9 
For #1140, I considered trying to use the existing fields in a better
way, but because we already use the activations table to store
preferences, we need to keep all of the existing data and its usage
as-is.

The enterprise code will use this new column to decide how long the
trial period should be.
jordigh added a commit that referenced this issue Aug 1, 2024
@jordigh
Activations: add an enabled_at column
2469c49 
For #1140, I considered trying to use the existing fields in a better
way, but because we already use the activations table to store
preferences, we need to keep all of the existing data and its usage
as-is.

The enterprise code will use this new column to decide how long the
trial period should be.
jordigh added a commit that referenced this issue Aug 1, 2024
@jordigh
Activations: add an enabled_at column
fd45e56 
For #1140, I considered trying to use the existing fields in a better
way, but because we already use the activations table to store
preferences, we need to keep all of the existing data and its usage
as-is.

The enterprise code will use this new column to decide how long the
trial period should be.
jordigh added a commit that referenced this issue Aug 1, 2024
@jordigh
Activations: add an enabled_at column
17558f0 
For #1140, I considered trying to use the existing fields in a better
way, but because we already use the activations table to store
preferences, we need to keep all of the existing data and its usage
as-is.

The enterprise code will use this new column to decide how long the
trial period should be.
jordigh added a commit that referenced this issue Aug 5, 2024
@jordigh
Activations: add an enabled_at column
953b4a6 
For #1140, I considered trying to use the existing fields in a better
way, but because we already use the activations table to store
preferences, we need to keep all of the existing data and its usage
as-is.

The enterprise code will use this new column to decide how long the
trial period should be.
jordigh added a commit that referenced this issue Aug 5, 2024
@jordigh
Activations: add an enabled_at column
e20cddd 
For #1140, I considered trying to use the existing fields in a better
way, but because we already use the activations table to store
preferences, we need to keep all of the existing data and its usage
as-is.

The enterprise code will use this new column to decide how long the
trial period should be.
jordigh added a commit that referenced this issue Aug 6, 2024
@jordigh
Activations: add an enabled_at column
4dfbda6 
For #1140, I considered trying to use the existing fields in a better
way, but because we already use the activations table to store
preferences, we need to keep all of the existing data and its usage
as-is.

The enterprise code will use this new column to decide how long the
trial period should be.
jordigh added a commit that referenced this issue Aug 6, 2024
@jordigh
Activations: add an enabled_at column
ba7b72b 
For #1140, I considered trying to use the existing fields in a better
way, but because we already use the activations table to store
preferences, we need to keep all of the existing data and its usage
as-is.

The enterprise code will use this new column to decide how long the
trial period should be.
@jordigh jordigh closed this as completed Aug 20, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
self-hosting Self-hosting setup that needs some love
Projects
Improvements for self-hosting
Status: Done
Milestone
No milestone
Development

No branches or pull requests
1 participant
@jordigh