I am pretty new to Contentful and am using the company's contentful account.
This profile has administrator access and I cannot create a content-type.
The 'Add Content type' button appears disabled.
I checked if there is a limit on the number of Content Types that can be added,
On Demand Tier can have 500 content types and Committed Tier can have 1000 content types.
I have a lot of different spaces and I checked, that we have only 99 content types created combining all of the spaces in this account.
Is this somehow related to roles and permissions?
If thats the case shouldn't I have the ability to create a new content type since I have administrator privileges?
The limits you mention are the technical limits of the maximum possible for any space type. Most likely what's happening is related to the size of space you have. Contentful's pricing model allows you to choose the size of the space you need for your project and, for example, perhaps your space is a Small space which includes a maximum of 24 content types. You can see your space usage and limits from inside the Contentful webapp under Settings->Usage.
Related
Disclaimer: Please forgive me if this is a silly thing to ask but I work in a small company and our sharepoint build was outsourced and not done very well, and I'm the closest thing we have to an admin, and I'm just trying to understand what is/isn't possible when it comes to controlling access to our sharepoint content so we can have a clear idea of what we want to do when the time comes to rebuild.
So, my question: we have a set of documents that are stored in a series of libraries. We have several different types of users, who are bound by different levels of contract/NDA.
Some users need access to all our documentation, some need access to most of our documentation and some need access to only some of it.
At the moment, we have them divided into 3 separate user groups, who each have access to only their own library. and we populate each with all of the documents that each group needs access to, which means that a large sub-set of the documents are duplicated across multiple libraries.
EG: user group 1 has access to folder 1 only. User group 2 has access to folder 2 only, etc etc.
This is problematic as we end up with version control issues as people may update a doc in one location and forget that it is also in the one or more of the others.
What I would like is to find a way to maintain only 1 set of documents and be able to control who has access to it at the document level.
Now, I can see how it could be managed by splitting the documents up into separate folders by access level, and it would look something like below:
However, this just doesn't make any sense in terms of our actual content; it's not that user group 1 needs all the legal content and user group 2 needs all the commercial content, and UG3 needs technical. It's that UG1 needs all the legal, commercial and technical content, UG2 needs most of the above, and UG3 is only allowed access to a smaller amount of high level documentation on each.
In real life, it looks something more like this:
So ideally, I'd like a solution for permissions that looks something like this:
In my head, this involves creating permission levels and applying them to the individual documents, for eg: Document #123 can be access by permission level Y, which means user groups 1 & 2 can access it, but not user group 3.
Is this even something that is possible to do? Does it make sense? If I'm way off base, I'd love any suggestions on how else we could/should manage this.
NB: I'm not asking for anyone to tell me the detail of how to achieve this, as that's well beyond my capability and we'd definitely be outsourcing the doing, I'm more just looking to understand what it is we should be getting done when we do get it done, so we don't end up with a substandard solution again.
Huge thanks in advance!
L
Based on your description, I understand that you want to set unique permissions for documents. And you don’t want to put a document in different places to cause a version error.
In my opinion, you first divide users into three separated user groups. Then set unique permissions for individual documents. For example, document1 can be accessed by group1, document2 can be accessed by group1 and group2, etc. Using folders to classify documents cannot meet your requirement.
Update:
1.Select the file -> Manage access -> Advanced.
2.Stop Inheriting Permissions -> Remove permissions of users you do not want, grant permissions for users you want.
We currently have a small number of Acumatica locations set up which are largely functional rather than physical. (Inbound Testing, Stockroom, RMA Review, etc).
We use these to set default issue/receipt locations and other such things.
We are also interested in tracking physical locations for our serialized parts. (We would use a rack/tray/position system, with each rack holding multiple trays and position on a tray being specific to a single serial number.)
Does Acumatica have any built-in functionality to support this kind of thing, or to get us further along the path? We don't want to end up with 40,000 individual locations. If we need to add customizations, are there suggestions for how and where to do this?
Per discussion with Acumatica (thanks, Ruslan!) we have confirmed that there is no default functionality for what we're trying to do, and customization is required.
He suggested if each serialized item has its own location, we could extend the INItemLotSerial table to track this.
I have a SSAS cube where some users only should be able to see some of the values. It is based on a dimension Country. How do I setup restrictions so that this filtering on countries is always done, even if I done use that dimension. For the moment only restriction is setup on that dimension. And if All is choosen all countries would be included in calculations.
You need to create roles, assign users (preferably user groups) to roles, and configure the dimension members to allow or exclude when the role members browse the cube. You can use Enable Visual Totals to change the All member to display only the aggregate of the members they're allowed to see. If you leave it disabled (the default), then users see the true value for the All member (i.e. the All member includes the total of every member, even the ones the users cannot see).
Basic information is at http://technet.microsoft.com/en-us/library/ms174840.aspx.
Here's a video walkthrough: http://channel9.msdn.com/blogs/philo589/dimension-security-in-sql-server-analysis-services.
And a readable walkthrough with sample download and screenshots: http://www.mssqltips.com/sqlservertip/1834/introduction-to-dimension-security-in-sql-server-analysis-services-ssas-2005/
I have an application which contains different kinds of permissions. As mentioned in (Role Bases Security) RBC ,I grouped users into roles and assigning different permissions to roles. (and permissions are in this style :
public enum Permission {
View = 1,
Create =2,
Edit =4,
Delete =8,
Print = 16
}
everything is ok in simple systems but when the system becomes a little complex , specific permissions come to the system such as :
View Just His Issued Invoices
View All Invoices
Edit Just His Issued Invoices
Edit All Invoices
Create Sale Invoice
Create Purchase Invoice
Create Proforma
Create Sale Report On His Own Invoices
Create Daily Sale Report
Create Monthly Sale Report
-....
As you see different kind of permissions arises in system (it can grows to about 200 different permissions). So the problems are :
I cannot put them all in one enum . then using binary pattern (1,2,4,8,..) cannot be used because in its best case(int64) it supports up to 64 different permissions.
a big enum (with about 200 items) is not so good in coding
what are your ideas in this case?
thanks in advance :-)
I'm not sure why you feel that you need to try to shove all the permissions into a single flags (or so I'm inferring from the vales) enum. Permission requests and grants can be represented using lists as opposed to a single ORed value. If you use a list approach, you become free to create whatever permission representation you like. For example, you could use a non-flags enum or even multiple enums to represent your permissions.
It sounds like you need a level of indirection...
For example, you need a category (represented by an object, say) that represents "His Issued Invoices". You need a way to grant a role any of your basic permissions on that object. You need a way to test whether something is a member of that category.
Suppose "Jane" tries to view an invoice. Then you just need to check: Does Jane have a role which has View access to some category of which this invoice is a member?
This check might be slow, since you have to check all of Jane's roles against all of the invoice's categories. But presumably you can cache the result... Or your can use a "capability based" approach, where Jane asks the security manager for a handle (pointer) to the invoice with View access. The security manager does the check and hands Jane the handle, after which she can use that handle to do whatever Viewing operations the handle supports with no additional security checks.
I agree with Nicole it does seem like you are performing what may have seemed like a good optimization but you are encountering issues with scale.
Many RBC systems deal with a large number of permissions, which is one reason roles exist - regular users need only know what role they are in - leave it to the developers to figure the role-permission mapping out. Larger systems might provide a GUI for superusers to do the role-permission mapping, or even create permissions, but only to provide the power user ultimate flexibility.
However, because of J2EE, at the code level it all boils down to checking 'roles' programmatically. That tends to confuse things when what you actually want to test for is the permission to perform an operation. Just keep that semantic gap in mind.
In terms of optimization, consider not the method of assignment of permissions, but when and how you perform the check. In a web application, you may only need to check when the call from the front-end comes in, and perhaps network latency will dwarf any optimizations you perform here.
If you decide you do still want to optimize, you'll probably find simply caching the permissions at login is enough. The actual search for a permission will be all in memory, so will be tiny after the initial load from the database.
To avoid the combinatorial explosion of permissions, establish some strong logic up front - write it down - and make sure you're covering all your bases. If you see the need for new dynamic permissions to be created, such as when new entities are added in to your system, then watch out - this is better done in a mediator or manager pattern that can check your business rules before handing out the protected entity. Here you are stepping into the realm of libraries like Drools which serve to expose business logic from your application so that it can be updated based on changing business requirements.
i have created a workflow activity that do give the item creater of a specific list full control on the item and set everyone else to read only access (permission)
someone told me that doing it this way (if i have a lot of users) the performance will go down dramatically
is that correct ?!!
if yes what is the best solution to create a list where any one can create new items but after the item is created only the creater can edit it and the rest of the users can read it only
The accepted answer is not actually answering the question correctly...
You should not use a workflow to do this, if you want people to be able to edit items they create and only read ones they did not, use "List->Settings->Advanced Settings->Item-level Permissions", and this is available for document libraries (since they inherit from SPLIST) it just does not show up in their "Advanced Settings" in the UI. You can set the ReadSecurity property to 1 and the WriteSecurity property to 2 on the Document Library.
http://msdn.microsoft.com/en-us/library/microsoft.sharepoint.splist.writesecurity.aspx
Performance degradation will happen when you use large ACLs for each list item. Just make sure that item-level permissions basically have the minimum entries. For example:
The user that has permissions to edit that item
A single security group that contains all the users with only Reader permissions.
So, can Sharepoint offer these default permissions OOB? Not that I'm aware of. The only option that I can think of is using workflows that set these permissions dinamycally when the document is uploaded.
If you want to avoid performance degradation just make sure that you never display (or iterate using the object model) more than 2000 of those items in a Fine Grained Permissions list. THAT would definitely cause major performance issues.
Yes, you might solve this with workflows but that might be a bit clumsy and it might slow your server.
The better option is to use List Settings > Advanced Settings > Item-level Permissions.
This feature is not available for Document and Form Libraries.
It is true that a list that contains a large number of items with custom permissions applied, will slown down your server. This is document in the official Microsoft paper Plan for software boundaries.
The recommended/magic number is 2000. Going further won't break anything, but it could be that you will run into performance issues.