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
Made UI updates to reflect pending token payments during upgrade account flow.
So pending transactions with confirmations count are displayed on Add STORJ Tokens step of upgrade flow.
While this modal is open we make a request to storjscan once in 20 seconds to get recent confirmations count.
When all transactions become confirmed we show success view where a sum of STORJ tokens received is displayed.
Issue:
https://github.com/storj/storj/issues/5978
Change-Id: Icfdc1e5080ed58cea1822cb7d85551ba8064c636
We don't need it any more, as CountryCode uses location.Set, which supports exclusion (`Without`).
Change-Id: Ie311ae19fefa0bc9a0161496af1233ef4a6607df
stats/size/count is not used by any production code, and it's not required, as we can assert the state with other checks.
real motivation: next commits will make the Selector of the State configurable, therefore we won't have one single Stat, it depends on the request parameters.
(we plan to support both network and id based randomization)
Change-Id: I631828fc0046d2fef5b7a674fc0268a0446e9655
This change extends the autofreeze chore to go through users who have
been warned/frozen to check if they have no failed invoices. If they do
not, this extension unwarns/unfreezes them.
Issue: https://github.com/storj/storj/issues/6077
Change-Id: I570b1d4b2e29574bd8b9ae37eb2d4fb41d178336
