deleteGeofenceForProject wasn't able to work correctly, because
Console().Projects().Update() declines to update default_placement when
the input value is 0.
This introduces a Console().Projects().UpdateDefaultPlacement() method,
congruent to the method of the same name on Console().Users().
deleteGeofenceForProject now uses this new method, so that specifying a
new placement of 0 will work correctly.
Change-Id: I4589b36707f7e4f1cfdc66543520b0d4205c1a84
The satellite admin API endpoint responsible for returning project
limits now includes the burst limit in its responses.
Resolves#6276
Change-Id: Ibb3f1fdebf2f9ffd62de2d7e7a60d978c25bb22a
This change does two things:
* allow using either public ID or private ID to do project-related
requests in admin UI
* allow passing a UUID string not containing dashes (i.e. a pure hex
string) in order to do project-related requests in admin UI
Change-Id: I4807a5d7252a48f4a09e3966c406645d55c856e2
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
Currently we have a bug in which we would require that a project of
a paid tier user needs to be two months unused before we can delete it.
This change fixes it and reduces it back to the normal next billing cycle.
Change-Id: I28610b6c45c68943fd4f2621233bccc06cab28a0
This change adds some more checks to the deletion process for projects and
users, since we ran into a race condition during invoicing, where projects
have been deleted before the invoicing was finished, leading to missing
references.
This PR changes the logic to block user deletion if we are in exactly that period,
while also allowing the deletion of projects/users on free tier during the month.
Change-Id: Ic0735205e6633762fb7e3c2fa13e744cdfa5ec32
The main motivation is to wrap the bucket DB and metainfo DB, so we
could check if a bucket is empty before applying geofencing config.
Change-Id: I8bac21555e01d51a663fb557bc1acfc8106bc2e1
* Add test cases to verify that all the endpoint that target a specific
entity respond 404 status code when the entity isn't found.
* Fix the endpoints that target a specific entity which responded a 500
status code response when the entity didn't exist to respond with 404
status code.
Additionally:
* Simplify some tests using an existing test helper function.
* Rename test functions to start with the entity name (e.g. Project,
User, etc.) for easing to run a set of test with the `-run` Go test
flag.
Change-Id: I82aad92e429207b72932ad4b79c08db6b486a19a
A previous commit added a helper function for sending JSON data back to
the client.
This commit makes use of it for homogenizing the current implementation.
It also renames the existing helper message to send JSON errors to
starts with "send" because the new helper starts with it and they
helpers are clearer with their name starting with it.
Change-Id: I53ee0b4ca33d677a8ccd366c9ba6d73f4f472247
This PR utilize the new burst limit column from projects table to allow
control on the limit for request per seconds and token bucket size
When no burst limit is explicitly set, rate limit is applied to both so
we don't limit how quickly request can be made in a second.
Change-Id: I883235c60c5d6416aeadd1c80ed2ebd193aa4d9f
Don't update the project description if the request body has the
description field set to an empty string.
This follows the same convention used for updating an user's account.
Change-Id: I027047e609760e033cf4b233b1be352c6bf0ec8f
the month
The Stripe API had a bug before that it wasn't calcualting the input
timestamp based on correct timezone. We had a workaround to not include
the last day of the month in our code when submitting to Stripe.
Now, Stripe has fixed the issue. We need to remove the workaround and
include the last day of the month into our invoice generation
Change-Id: Ic6364ed071be73a19f0b0b46f274a02fb2489db5
This is one step for implementing the free tier:
* Change the default project limit from 10 to 3
* Move storage and bandwidth project usage limits from the metainfo
package to the console package (otherwise there is a cyclical
dependency, and metainfo doesn't use these values anyway)
* Change the default storage usage limit per project from 500gb to 50gb
* Change the default bandwidth usage limit per project from 500gb to 50gb
* Migrate the database so that old users and projects continue to have
the old defaults (10 projects/500gb usage)
Change-Id: Ice9ee6a738bc6410da18c336c672d3fcd0cab1b9
Currently we have no way to actually set one
of the following limits to 0 (meaning not usable):
- maxBuckets
- usageLimit
- bandwidthLimit
With having the field nullable,
NULL corresponds to the global default,
0 now actually 0 and
a set value determines a custom limit.
Change-Id: I92bb77529dcbd0881ae8368921be9d246eb0919e
This adds new endpoint /api/user/{user-email} which allows to get the
projects where the user is a member.
It also moves existing endpoint:
/project/{projectid}/limit -> /api/project/{projectid}/limit
To avoid future conflicts for displaying pages.
Change-Id: I5efe3e1c8f79894c136f92ed815f635a34ba6f98
