When a user is in the free tier and attempts to add STORJ from billing screen, open the "upgrade" modal instead of the simpler "add STORJ tokens" modal.
The simpler modal is still used for Pro users.
Issue:
https://github.com/storj/storj/issues/6165
Change-Id: I261d67e1c4d569f7058da828bcb145a64136c231
Universal "large file notification" removed.
Threshold for user-triggered large file notification is 5gb instead of 1gb.
Large file notification appears as "info" instead of "warning".
Display large file notification on failed uploads >1gb.
Issue:
https://github.com/storj/storj/issues/6149
Change-Id: I6ae6ba50e45c65f058cbb91a5f0fbda79a49a812
This change modifies delete bucket requests to optin for force delete
using the x-minio-force-delete header. This solves an issue where
buckets deletes will be slow for buckets that have many objects. This
change is to make the UI emulate uplink rb --force since it has better
performance.
Issue: https://github.com/storj/customer-issues/issues/930
Change-Id: I0a74c1a201e74b07eb30b917adf78ef865ce2003
This change uses the new /delete-by-ids endpoint in place of the GraphQL query.
Issue:
https://github.com/storj/storj/issues/6140
Change-Id: Ia78016e68fca296367e650b7a919130e662ee8f6
This change uses the update project HTTP endpoint in place of the
GraphQL alternative.
Issue: https://github.com/storj/storj/issues/6134
Change-Id: I7d8203c20d8c0c1dcdddb7d1aaf472fc66568a3d
This change adds an endpoint update projects, to be used in place of
the graphql alternative.
Issue: https://github.com/storj/storj/issues/6134
Change-Id: I26c04f4400f71721cbddb7f64405e6c9b78edb4d
This change removes the project description from the subtitle of the
topmost item in the project navigation area, replacing it with the
project name and inserting "Project" where the name used to be.
References #6170
Change-Id: I07a04ebba54828df41f4d241aa69ec6b3d9e0cef
The message area beneath input components has been hidden by default so
that it doesn't occupy space when it isn't needed.
References #6170
Change-Id: I16b078cddb07708169b96e53db283aedb290f9f4
This change fixes the position of the close button in dialogs where
there was no spacing between the button and the edges of the dialog
header.
References #6170
Change-Id: Id3f798953319c1703d7bb6868757aecd02ec09f5
This change causes the satellite frontend to use the HTTP endpoint for
retrieving bucket usage totals rather than its GraphQL counterpart.
Resolves#6141
Change-Id: I9a42080c8344aa617a910a8782dc61101a6734c8
This change introduces an HTTP endpoint for retrieving bucket usage
totals. In the future, this will replace its GraphQL counterpart.
References #6141
Change-Id: Ic6a0069a7e58b90dc2b6c55f164393f036c6acf4
This commit adds a new endpoint on the satellite console api to get
project members and invitations.
issue: https://github.com/storj/storj/issues/6137
Change-Id: I66cb064eeaffb1c34878462b3e6b3be8f3629f4e
This change uses the new /projects/paged endpoint to get user's owned
projects in place of the OwnedProjects graphQL query.
Issue: https://github.com/storj/storj/issues/6135
Change-Id: I1e8dfdefdc7de51595637577f7d8bdce8e969652
This change adds an endpoint to get a user's projects, similar to
the OwnedProjects GraphQL query.
The console.ProjectInfo struct has been renamed to UpsertProjectInfo
to more accurately reflect its use.
Issue: https://github.com/storj/storj/issues/6135
Change-Id: I802fe4694a5cc75a9df2b565476f6e6f473431d4
With this change we are removing code responsible for deleting objects
and supporting server side copies created with references. In practice
we are restoring delete queries that we had before server side copy
implementation (with small exception, see bellow).
From deletion queries we are also removing parts with segment metadata
as result because we are not longer sending explicit delete requests to
storage nodes.
https://github.com/storj/storj/issues/5891
Change-Id: Iee4e7a9688cff27a60fb95d60dd233d996f41c85
We don't need to support segment copies with references anymore.
We migrated to copies where all metadata are copied from original
segment to copy.
https://github.com/storj/storj/issues/5891
Change-Id: Ic91dc21b0386ddf5c51aea45530024cd463e8ba9
This change adds an endpoint to delete API keys, similar to GraphQL mutation.
Issue:
https://github.com/storj/storj/issues/6140
Change-Id: Ia4a808222a057a199d803d8ea6b944c411a4dc8d
This change uses the new /create endpoint in place of the GraphQL query.
Issue:
https://github.com/storj/storj/issues/6139
Change-Id: Ic7db9407377b742ab87c887a74a37eaec6a8dbb6
With this change we are removing code responsible to handle deleting
bucket and supporting server side copies created with references. In practice we are restoring delete queries that we had before server side copy implementation (with small exception, see bellow).
From deletion queries we are also removing parts with segment metadata
as result because we are not longer sending explicit delete requests to
storage nodes.
https://github.com/storj/storj/issues/5891
Change-Id: If866d9f3a1b01e9ebd9b49c4740a6425ba06dd43
This change adds an endpoint to create new API key, similar to GraphQL mutation.
Issue:
https://github.com/storj/storj/issues/6139
Change-Id: I2b35d680fa8e019666c811ad3bdf16201e3b8946
This change uses the new /list-paged endpoint in place of the GraphQL query.
Issue:
https://github.com/storj/storj/issues/6138
Change-Id: I68c35437f3f2e18898783e2fd523cfdfb3f10de3
This change adds an endpoint to get paged project API keys, similar to GraphQL query.
Issue:
https://github.com/storj/storj/issues/6138
Change-Id: I5dea9e4ac61e798cc8a2e56a2755d722c1b66bfa
Start using analytics pinia module instead of making direct API requests from components.
We do this to not mix transport layer logic with view logic.
Issue:
https://github.com/storj/storj/issues/6122
Change-Id: Idb1902aec0635df4f0e682ba50bcc97b240ac4a9
This change uses the new /projects endpoint in place of the GraphQL
MyProjects query.
Issue: https://github.com/storj/storj/issues/6132
Change-Id: Ie4ae69dd6def75c4b8c627aaf55c31914cf69ce5
This change adds an endpoint to get a user's projects, similar to
the MyProjects GraphQL query.
Issue: https://github.com/storj/storj/issues/6132
Change-Id: I91feb5a1ee8c1231a8a5e6de9b8dc5b256f857c5
Added update session timeout dialog for vuetify app and wired it up with the backend
Issue:
https://github.com/storj/storj/issues/6090
Change-Id: Icfd981c8d24a87b199e5e1eeb599f6369e6ee5c4
In the repair subsystem, it is necessary to acquire several extra
properties of nodes that are holding pieces of things or may be
selected to hold pieces. We need to know if a node is 'online' (the
definition of "online" may change somewhat depending on the situation),
if a node is in the process of graceful exit, and whether a node is
suspended. We can't just filter out nodes with all of these properties,
because sometimes we need to know properties about nodes even when the
nodes are suspended or gracefully exiting.
I thought the best way to do this was to add fields to SelectedNode,
and (to avoid any confusion) arrange for the added fields to be
populated wherever SelectedNode is returned, whether or not the new
fields are necessarily going to be used.
If people would rather I use a separate type from SelectedNode, I can do
that instead.
Change-Id: I7804a0e0a15cfe34c8ff47a227175ea5862a4ebc
Current node selection logic (in case of using SelectBySubnet):
1. selects one subnet randomly
2. selects one node randomly from the subnet
3. applies the placement NodeFilters to the node and ignore it, if doesn't match
This logic is wrong:
1. Imagine that we have a subnet with two DE and one GB nodes.
2. We would like to select DE nodes
2. In case of GB node is selected (randomly) in step2, step3 will ignore the subnet, even if there are good (DE) nodes in there.
Change-Id: I7673f52c89b46e0cc7b20a9b74137dc689d6c17e
Change is adjusting CommitObject to use `pending_objects` table to
commit object.
Satellite stream id is used to determine if we need to use
`pending_objects` or `objects` table during commit.
General goal is to support both tables until `objects` table will be
free from pending objects.
Part of https://github.com/storj/storj/issues/6046
Change-Id: I2ebe0cd6b446727c98c8e210d4d00504dd0dacb6
Change is adjusting CommitSegment to check pending object existence in
`pending_objects` or `objects` table.
Satellite stream id is used to determine if we need to use
`pending_objects` or `objects` table.
General goal is to support both tables until `objects` table will be
free from pending objects. Whenever it will be needed code will be
supporting both tables at once.
Part of https://github.com/storj/storj/issues/6046
Change-Id: I954444a53b4733ae6fc909420573242b02746787
Change is adjusting BeginSegment to check pending object existence in
`pending_objects` or `objects` table.
Satellite stream id is used to determine if we need to use
`pending_objects` or `objects` table.
General goal is to support both tables until `objects` table will be
free from pending objects. Whenever it will be needed code will be
supporting both tables at once.
Part of https://github.com/storj/storj/issues/6046
Change-Id: I08aaa605c23d82695fde352fdbd0a7fd11f46bb5
Change is adjusting BeginObjectNextVersion to create pending object in
`pending_objects` or `objects` table depends on configuration. This is
first change to move pending objects from objects table.
General goal is to support both tables until `objects` table will be
free from pending objects. Whenever it will be needed code will be
supporting both tables at once.
To be able to decide if we need to use `pending_objects` table or
`objects` table we extend satellite stream id to keep that information
for later use.
BeginObjectExactVersion will be not adjusted because at the moment it's
used only in tests.
Part of https://github.com/storj/storj/issues/6046
Change-Id: Ibf21965f63cca5e1775469994a29f1fd1261af4e
