I am preparing a data deposit for Zenodo, in which most contributors fulfilled multiple roles.
Do I really have to add each contributor multiple times, or is there a different way of adding multiple roles to a single contributor?
It really seems that at the moment specifying each contributor once for each role is the only way of doing this.
Related
I have multiple AWS accounts, for example, app-dev, app-prod, app-it, etc. There's also the management account, app-root.
There are also multiple groups already present, for example, developers, developers-prod, administrators, etc.
I also have multiple permission sets, for example, DeveloperAccess, AWSAdministratorAccess, DeveloperITAccess, etc. Opening, for example, the DeveloperAccess permission set, I can see an inline policy that includes things like s3, dynamo, rds, etc. Going to the "Accounts" tab, I see all my development accounts (app-dev, app-prod, app-stg), but I also see the app-root account.
Now, I don't want my developers to have access to the management account. I tried removing the management account from there, but that changed nothing on their end. I guess I just don't understand the underlying connection between accounts, groups and permission sets. Documentation wasn't clear enough for me. What I'm trying to do is to make sure my management account isn't accessible to anyone, basically, I want a special group/permission set for it, and I also want to remove app-root from every other group/permission set. I don't know how to do that.
Is it possible to have a different BigQuery quota for different users within the same project?
I know that I can set a limit on the 'Query usage per day per user' for a given project via the IAM and admin section of GCP (following these instructions).
I'd like to know if it were possible to have a different per user limit. i.e. say set a limit of 2 TB per day for John but only 1 TB per day for Jane?
I am working for Google Cloud and a coworker opened on November 15 a Feature request to do what you need.
There is actually a workaround for this, which would consist on creating a different project for each user you want to grant the custom quota. Depending on the amount of different users you want to do this for it will maybe not be that feasible.
The app is installed at several customers and each installation has several groups and a lot of users.
In the past every user was allowed to use the basic feature BasicFeature.
A small new group ("RestrictedUsage") of users should not have the permission to have this BasicFeature.
Our current automated update idea looks like this:
Create new permission UseBasicFeature
Give all existing groups the new permission.
Create the new group "RestrictedUsage"
Since we have several customers, we need an automated way to handle this.
The above solution does should work, but I don't like it.
I don't like it because installations which don't have a "RestrictedUsage" group need to be modified. Otherwise the users would not be allowed to use BasicFeature (which they use since ages).
Has anybody see better way?
We're starting to use DynamoDB, and want separate environments for dev/staging/production. We can't figure out a natural way to do this---do we just create separate AWS accounts? Or do we use the same account, but add silly prefixes to our tables ("dev-products", "staging-products", "prod-products")?
The standard way to manage this with any amazon products is to create separate accounts and then use consolidated billing so that it doesn't complicate the billing aspect. The thing i like about this is that you don't risk breaking the production code by accidentally running the wrong command. Obviously it doesn't help you if you're logged into the wrong instance but it still helps quite a bit.
Other uses for multiple accounts could be to manage permissions and better testing. Having the accounts separate helps testing because you can reproduce the production account 100% and turn it on and off when you need to test new features. I've talked with amazon premium support about this issue and they've said that this seems to be standard practice for the larger companies. Some of the larger companies have many accounts. At my work here we just have 3 and I find it more useful every day.
Don't forget Amazon's greatly enhanced IAM for access control. It largely gives you the same benefits of separate accounts. (Separate accounts are still an option if you have want to have different levels of paid support.)
Naming wise, my preference is name.environment.whatever.
I can't understand why there is'nt a AWS solution for handling DB-versions like production and test in DynamoDB!? Having multiple AWS accounts is a hassle.
It also becomes a big problem to prefix the table names if you get the items by using the c# class attribute [DynamoDBTable("Users")] and fetching the data with DynamoDBContext.Load<User>(userId);
As attributes values can't change during runtime I ended up with this soluting using conditonal compilation symbols and setting constants that can be used as the class attribute value.
public static class DynamoDbTablesConfiguration
{
#if Debug
public const string UserTable = "Users_Dev";
#endif
#if Release
public const string UserTable = "Users_Production";
#endif
}
[DynamoDBTable(DynamoDbTablesConfiguration.UserTable)]
public class User
{
}
Make sure you set the "conditonal compilation symbols" value by right click on project > Properties > Build > "conditonal compilation symbols".
Not a perfect solution but I don't see any other options here if I don't want to create another AWS account.
I don't see anything that's "above" the tables that can be created for each instance (dev/staging/prod) you have (like a relational database, which have all tables under one DB).
At the application I'm working on, we're using prefixes to the tables.
Amazon now provide a server that you can run locally. You can download it here.
I am developing a Django web application with a suite of steel design tools for structural engineers. There will be a database table of inputs for each design tool, and each row of each table will correspond to a particular design condition to be "solved." The users may work solely or in groups. Each user needs to have ongoing access to his own work so that designs can be refined, copied and adapted, and so that reports can be created whenever convenient, usually at the end of a project when hard copy documentation will be needed. The database contents must then be available over any number of sessions occurring over periods measured in months or even years for a given design project.
When there is a group of users, typically all associated with a given design office, it will probably be acceptable for them all to have joint and mutual access to each other's work. The application supports routine engineering production activities, not innovative intellectual property work, and in-house privacy is not the norm in the industry anyway. However, the work absolutely must be shielded from prying eyes outside of the group. Ideally, each group would have one or more superusers authorized to police the membership of the group. Probably the main tool they would need would be the ability to remove a member from the group, discontinuing his access privileges. This would be a user group superuser and would not be the same as a superuser on the site side.
For convenient access, each row of each database table will be associated with a project number/project name pair that will be unique for a given company deploying a user or user group. A different company could easily choose to use a duplicate project number, and even could choose a duplicate project name, so discriminating exactly which database rows belong to a given user (or group) will probably have to be tracked in a separate related "ownership list" table for each user (or group).
It is anticipated (hoped) that, eventually, several hundred users (or user groups) associated with different (and often competing) companies will solve tens of thousands of design conditions for thousands of projects using these tools.
So, here are my questions:
First, is there any point in trying to salvage much of anything from the Django contrib.auth code? As I perceive it, contrib.auth is designed for authentication and access control that is suitable for the blogosphere and web journalism, but that doesn't support fine-grained control of access to "content."
Second, is there any available template, pattern, example, strategy or design advice I could apply to this problem?
django-authority: Documentation, code on GitHub