I was recently looking at access rights for attributes and seeing if certain attribute properties are controlled by M and others by C, but it seems like I have access to all attribute properties with the M access rights. Does anyone know what Create access rights gives for attributes?
With DOORS' concept of hierarchy and inheritance and with the general concept that everything may have its own access rights, not every single access right makes sense.
C on "something" allows you to create "something else" that is one hierarchy level below the "something". If you have an Object in your Module and remove C on this Object's properties for a group of users these users may not create Objects below this Object (example: Object containing the heading of chapter 2.3. The users will not be allowed to add any Objects in Chapter 2.3).
There is nothing in the DOORS hierarchy below Attribute definitions and Attribute values, so setting or removing C here has no effect.
In the hierarchy, Attribute definitions are directly below the Module. So, in order to prevent that a user creates Attributes on their own, you will have to remove C for this user on the Module, i.e. in the module properties. Unfortunately, this will also disallow that user to create any Object on Level 1, leaving them to being next to unable to edit the module content.
Also, removing C on the module properties will disallow the users to create Views, as View definitions are also placed directly below the Module in the hierarchy.
Related
In a rails 3 app, I have a model with a boolean attribute called "archived". This attribute is accessible in the cms, where I can go in and edit individual objects, and a checkbox where I can check if an object is archived or not. However, if this object is archived, I don't want this object to be accessible on the api level. That includes the object itself, and its associated objects. At the same time I would like the object to be accessible in the cms, to edit other details and set the archived value back to false, so that I can access the object again in the api and change its behaviour back to default.
I would really appreciate suggestions on how to approach this from a design/high level perspective. Thank you for your help.
When you say "api" do you mean:
Public RESTful API
Access to those models in your own code. Like finder methods on your model?
For the first case, simply get only objects in required state (Model.where(archived: false)).
In the second case, taking into account that Ruby is very "open" language, it would be impossible to limit access to any of object property or method. However, to build a public API for other team members to use, you can add methods that correctly filter out your models (look into scope).
As a second alternative to Model.where(archived: false)
If you used a status enumerator instead of a boolean, you would be able to restrict the list using Model.archived, or Model.published... All you need is an integer field for the model's db table, and something like this in the model:
enum status: { dev:0, published: 1, archived: 2}
Then in your API, you define what status segment you want to restrict it to as shown above. The enumerator system in RoR is a little tricky to get the hang of at first, but very powerful once you get it.
I have 2 domain classes. One of them is User and the other is SuperUser. The super user contains some extra fields, and SuperUser inherits from User. (Also to note: User has the mapping to set inheritTableHeirachy set to false).
How can I cast the existing User instance object to a SuperUser? Is there a way that I can pass it in the SuperUser constructor?
I want to keep the reference to the original user, and I want to add the extra properties of SuperUser to the SuperUser table.
There is the way via properties. You maybe want to eradicate the ID afterwards or filter already before, what you don't need (it's a map). E.g.
new SuperUser(theUser.properties)
Since this only "copies" the same property names, there is no protection against setting "stupid" things. Both objects don't have to be of the same class hierarchy etc. It is just calling the c'tor for maps with a map.
A more structured way would be the introduction of an adaptor for this case.
I'm attempting to solve a domain modelling problem in a Rails application via composition.
I have a generic active record User class (which has some attributes in the users table), but we have a few different flavours of user. Some of these different user types have data stored in different places (for legacy reasons).
For example: BlueUser objects have their email attribute stored in the DB.blue_users table, and RedUser objects have their email stored in DB.red_users. Note that blue_users and red_users do not have the same table structure, they just both happen to have an email.
My intention is to have the generic User class be the only to interact with, and use composition to "create" the User objects out of their own properties and methods, in addition to the properties and methods of the composite object (Let's call it the User_Record object).
So the User class would have its own methods, but then at runtime as the User is being instantiated (perhaps via after_initialize), a RedUser or BlueUser object may be instantiated within User as the User_Record object. Each of the User_Record objects/implementations would be Active Record models themselves. I'm then hoping that something can be done so if I ask for the property User.email, it can be pulled from the User_Record object (without having to call it like User.record.email).
I've looked a little bit at composed_of in Rails, but am unsure how I might go about unifying the properties / methods of the two objects (so that I wouldn't have to do User.record.email elsewhere in the codebase).
I hope my explanation is clear, but if not I'd be happy to take another stab at it.
I am working on a project where we have requirement to provide field level access to users.
Example:
Suppose there is an entity named employee with several fields
The application should allow secure access at the field level of the entity.
According to the access user is allowed to edit / read the fields.
We have thought of an implementation using spring acl but it provides instance level security.
Could someone please let know an elegant way to implement it?
Thanks in advance.
Take a look at the fields plugin.
It allows you to control how individual fields are rendered.
You could implement a security check within each field's _field.gsp fragment, or you could override the plugin's taglib's f:all method and add a security check there if you prefer.
You could use the plugin for that, but you'd need to do some extra work. The ACL support in Spring Security basically lets you say "grant permission x on object instance y (of type "foo") with id z to person p". There is an example permissions class with standard instances like Read, Write, Admin, etc., but the underlying infrastructure only works with the numbers 1, 2, 4, 8, etc. so you can easily define your own permission types - they're really just mappings of human-readable names to numbers. You typically grant permissions on domain object instances, but under the hood the names of the domain classes are just strings, so you could store any type name there. And the ids can be any value, e.g. a number or a string.
You wouldn't be able to use the #PreAuthorize and #PostFilter annotations on service methods, but you can still query the ACL beans to see if, given a field or whatever you want, the currently authenticated user is allowed to perform some action.
The environment is JSF 2, GlassFish, PrimeFaces.
I am working on an application for editing the data in a very complex model.
All classes in the model have relations to other classes, which in turn have relations to other classes, and so on. In many cases, for a given class, the "cluster" of relations (the whole expanded tree for the class) contains the same class at many places in the tree.
For example :
Class A has relations to class B, C and D.
Class B has no relations.
Class C has relations to class B.
Class D has relations to class E.
Class E has relations to class B.
Now that I have summarized the context, here's what troubles me.
A design decision has been made to put all the data of a given instance of a class in the same page. The current architecture for doing this is the following for a given "root" class :
The "root" class is displayed in a PrimeFaces TabView. The tabs are :
"Main" : contains the simple attributes (String, Integer, ...) of the class.
There is one tab for each relation.
In each tab, there is an include pointing to the appropriate XHTML file.
If the relation points to a single class, the XHTML file pointed to is similar to the "root" form described here. The adequate object is passed as a parameter to the XHTML file in the include directive. There are at most 3 nested TabViews.
If the relation points to a list, the XHTML file pointed to displays a list, with "add", "edit" and "delete" buttons. The adequate list is passed as a parameter to the XHTML file in the include directive.
There are additional complexities concerning lists, but I won't go there for the moment. Just with the single elements, we can see that there is a problem.
At first, I used the same parameter name for all XHTML files to be included. This does not work, because the parameter is "global" to the view. It seems to work for the initial display, but as soon as there is an update in one tab, I get an javax.el.PropertyNotFoundException because the form points to another object.
To mitigate the problem, I changed the parameter name to be unique for each class. Before, all parameters were called "element". After the modification, the parameter for class A is called "aElement", for class B it's "bElement", etc.
This works if all classes in a cluster are different. If a collision occurs, we are back to the same problem as before : in two different inclusions, we use the same parameter names, with different values.
I have thought about a very convoluted way to do it, but it uses Javascript :
I pass an additional parameter to the XHTML forms, which is a unique identifier for the passed object.
I get the identifier in the XHTML form, and put it in a hidden field, which is separated from the rest of the form.
I make sure that the hidden field is never updated, read its value when the form gets focus, and retrieve the right object by an AJAX request using the value.
So my question is : is there a "pure" Java/JSF way to handle this ?
TL;DR : Thanks for reading !
For very complex natures CDI has a lot more to offer then plain JSF2. You could use producers and during runtime you can evaluate and modify objects freely.
You can keep track on what's already been produced and adapt the naming accordingly. For example save every occupied name in a map. Good luck.