This change adds a new column to the user table, which will hold a
random code for account activation. And another to hold the signup
request ID as another layer of verification.
Issue: #6428
Change-Id: Icd46cb5d8fc76102264d599aca27686cd8b2e84e
Currently we have large set of nodes that are already disqualified and
we are not sending bloom filters to them. The issue is that we are still
generating filters for them while garbage collection process. Even if
we have only segment with one piece which was stored on this node. This
consumes additional memory and processing powers.
This change is changing logic behind `AllPieceCounts` (renamed to
ActiveNodesPieceCounts) to return piece count for all nodes except disqualified one (even with piece count = 0). With this change we can
modify GC observer to skip nodes that where not returned by
ActiveNodesPieceCounts.
Change-Id: Ic75159135abe535084d8aeee560bb801a4a03e17
This reverts commit 2b4f347c33.
Reason for revert: not a zero-downtime migration. We need to deploy the dbx changes before completely dropping the column.
Change-Id: Ic9215650242b7848d54f8a5f863a13bc18b60149
This change extends the account freeze functionality account for legal
freezes as well. This is a freeze event for accounts to be put on hold
for legal review. It also sets the LegalHold status on the affected
user.
Issue: storj/storj-private#492
Change-Id: I8c733269b5cfb647c840379a6bb033da120c8280
This change adds an endpoint to the admin API and UI to get a list of
users pending deletion and have no unpaid invoice.
Issue: #6410
Change-Id: I906dbf9eee9e7469e45f0c622a891867bf0cc201
Add the DB schema changes and basic implementation methods to support
bucket level configuration of object versioning.
See bucket-level-versioning-configuration design doc for more details.
Change-Id: I4e920a20a403b3157970a34eb619d827a4007845
Since we no longer need the type column and hopefully,
there are no queries using it, we recreate all indices
that reference the nodes.type column.
Updates https://github.com/storj/storj/issues/5426
Change-Id: I610ccaf474a6f4031e166b79a6d649c4b138e338
This change adds a new column to the account_freeze_events table,
days_till_escalation, which is the number of days till the freeze event
is escalated. E.g.: 30 days from billing warning event to billing
freeze event.
Issue: #6382
Change-Id: I15cfd6f1208e641d8c380bef61717031befdad73
This column is no longer used, but it is referenced in dbx. This change
removes those references and adds an exception to the migration test to
disregard this column in schema comparison.
After this change is deployed, we will need to follow up with a
migration to remove the column in a later release, and remove the
exception in the migration test.
Related to https://github.com/storj/storj/issues/5432
Change-Id: I168fb57244b347901d1ed9c7813c1338554ee644
Currently, pending invoice payments that are made using a users token
balance can get stuck in a pending state if the invoice is not able
to be paid appropriately in stripe. This change addresses these stuck
token invoice payments by attempting to transition them to failed
if the invoice cannot be paid.
Change-Id: I2b70a11c97ae5c733d05c918a1082e85bb7f73f3
Current bucket_metainfos table schema was far from optimal. All
operations are using project_id and name to find bucket but primary key
was on id field which is completely not used. Turns out that secondary
index was not as fast as it could be because each select was also joining
primary index which was slowing down whole query.
Primary key is changed to project_id/name. Other indexes are dropped
and id column is now nullable which gives us space for dropping it
completely from schema and code later.
Change-Id: I477056a4243d39e39489f1473de01ded1ed24bbb
The SQL transaction that inserted project invitations relied on the
error result of one of its statements in order to determine whether an
invitation should be updated. This was inappropriate since any errors
returned from a transaction statement should end the transaction
immediately. This change resolves that issue.
Change-Id: I354e430df293054d8583fb4faa5dc1bcf9053836
This change removes instances of project invitation deletion due to
expiration because we now want such invitations to be accessible beyond
their expiration date. In the future, project members will be able to
view and resend expired invitations within the Team page in the
satellite frontend.
References #5752
Change-Id: If24a9637945874d719b894a66c06f6e0e9805dfa
Added backend (for now) implementation for updating user's and projects's user_agent using admin API.
Updating both user and project also updates bucket_metainfo and value_attribution tables.
Issue:
https://github.com/storj/storj-private/issues/297
Change-Id: I40244bbaa08b46834c1b1d0720e7d84d0c2a0330
An index has been added on the project_id column of the project_members
satellite database table so that we can retrieve members of a project
without performing a full table scan.
References #5855
Change-Id: I1cc30686f836c8fd1aa319247ce857a2392e7a52
There were some dbx-generated queries on the old satellite version that
still reference this column, so we need to add it back until the next
version.
Change-Id: I78b19336d9ca0384936d6cc11f5c50e579b4f2ab
This change includes STORJ bonuses to the list of transactions returned
by the /wallet/payments endpoint.
Issue: https://github.com/storj/storj/issues/5755
Change-Id: Icc95c2cb9dd9fc5ee7a373e68c1cf8a991e1aa58
The last code referencing these columns was removed as of satellite
release v1.79, so it is safe to remove them now.
Resolves https://github.com/storj/storj/issues/5432
Change-Id: I2e9d641b2511a61e0b9482ef0f4955a73c290709
The project member invitations table has been modified to contain a
column for the ID of the user who sent the invitation. This ID is
required for us to return information about the inviter to the
satellite frontend.
References #5855
Change-Id: I928d987a8db2340f731ca65ce30173d4f90a9837
This change updates the replacer in satellite/satellitedb/dbx/gen/main.go
to work with an updated dbx.
Change-Id: I08e89d6d27e6f1d435416105fe5f622009add7ad
Stripe invoice project records while listing are causing full table scan
because of OFFSET caluse. This change is refactoring query to list using
cursor.
Change-Id: I6b73b9b2815173d7ef02cf615408778476eb3b7b
We have method which is getting projects owned by specific user but it's
causing full table scan because we don't have index on owner_id column.
Change-Id: Icb71c9ac5b73104a52241ed8ba126c995c10811f
There is still a reference to partner_id in a query, which we cannot
move until dropping the "not null" constraint for it. This change adds
that migration.
Related to https://github.com/storj/storj/issues/5432
Change-Id: I98802a6e1bd59f3d9214de3db6688d9daf664a70
A table for storing pending project member invitations has been added.
This table is required to satisfy our new project invitation UX revamp.
References #5766
Change-Id: I6f948de66ed5b4dc81532564958ff7f48533cad2
Query to list (with pages) stripe customers were doing full table scan
because Offset clause was used. This refactoring changed listing to
use cursor instead Offset.
Change-Id: I14688e6c533bc932ba0d209a061562f080b4cf54
Add columns package_plan and purchased_package_at to stripe_customers
table and add methods to update and select these values from console
service and payments accounts.
Change-Id: I1e89909055cc3054bfb7baa33c9dca3dfdc7336e
FileWalker implements methods to walk over pieces in
in a storage directory.
This is just a refactor to separate filewalker functions
from pieces.Store. This is needed to simplify the work
to create a separate filewalker subprocess and reduce the
number of config flags passed to the subprocess.
You might want to check https://review.dev.storj.io/c/storj/storj/+/9773
Change-Id: I4e9567024e54fc7c0bb21a7c27182ef745839fff
This handles cases where a user is warned and triggers payment for their
account. Previously, only a frozen account will trigger this payment,
and will be unfrozen on successful payment. Now, accounts in warning
state trigger payments and are removed from that state on successful payment.
Issue: https://github.com/storj/storj/issues/5691
Change-Id: Icc2107f5d256657d176d8b0dd0a43a470eb01277
This change adds onboarding_start, onboarding_end and onboarding_step
columns to the user_settings table. the first two are used to determine
if a user should go through onboarding, the last will be used to as the
step a user got to before exiting onboarding without finishing.
Issue: https://github.com/storj/storj/issues/5660
Change-Id: I8070c880d0d2fc22086f24087c962f57c695cc50
Add a combined index on normalized_email,status to improve performance of
common "get user" query used for the satellite UI.
Change-Id: I24a20d7826e0a68a68c2f95b5847eb819921e7c0
Metainfo needs to know rate and burst limit to be able to limit users
requests. We made cache for per project limiter but to make single
instance we need to know about limits. So far we were doing direct DB
call to get rate/burst limit for project but it's generating lots of
DB requests and can be easily cached as we even have project limit cache.
This change extends project limit cache with rate/burst limit and starts
using this change while creating project limiter instance for metainfo.
Because data size kept in project limit cache is quite small this change
also bumps a bit default capacity of the cache.
Fixes https://github.com/storj/storj/issues/5663
Change-Id: Icb42ec1632bfa0c9f74857b559083dcbd054d071
In the past we set incorrect primary key for bucket_bandwidth_rollups
table and bucket name was first column of key instead of project id.
This change fixes this problem.
We will alter primary key manually for production satellites. That's
why migration code is checking if change was already applied.
https://github.com/storj/storj/issues/5332
Change-Id: I7dd555eb0c2f6fda1c90eaed08fa847b7f273bc7
Add passphrase_prompt column to user_settings table to store a boolean
whether a user would like to be prompted to enter a passphrase when
entering a new project.
Issue https://github.com/storj/storj/issues/5613
Change-Id: I5d086df277aff458453343c7c38a379e7b1b8bf9
