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.
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.
How can we rotate CUSTOMER NUMBER values in CICS?
For eg. If customer number is c52063
How can i get onto next value ie, c52064(say) in CICS?
This is a very broad question, essentially you're asking what persistence mechanisms are available in CICS.
Please understand there is a big difference between...
what is technically possible
what is allowed in your shop
what is likely to provide a robust and maintainable solution given your requirements
These are three very different things. Some of us answering questions here on StackOverflow have life experiences that make us reticent about answering questions regarding what is technically possible absent any mention of what is allowed in your shop or what the actual business requirement that is being solved.
Mainframes have been around for over half a century, and many shops have standard solutions to technical problems. Sometimes the solution is "don't do that, and here's what we do instead." Working against the recommendations of your technical staff, or your shop standards, is career limiting.
A couple of options, not intended to be an exhaustive list...
SELECT and UPDATE the value in a DBMS (such as DB2). You must code your SELECT SQL with FOR UPDATE.
READ and REWRITE the value in a VSAM file. You must code your READ with the UPDATE option.
In either case you are holding a lock on the resource until you hit either an explicit (EXEC CICS SYNCPOINT) or implicit (end of transaction) syncpoint or rollback (EXEC CICS SYNCPOINT ROLLBACK or abend condition). Holding such a lock means all other instances of your transaction will wait until the syncpoint or rollback has occurred.
If you know for certain your application will be limited to a single CICS region... Other options would include having a transaction initiated as part of region initialization processing that would obtain and populate a shared resource such as a temporary storage queue with a name known to your application with the last known customer number. This initialization transaction would have to obtain the highest used customer number from somewhere, probably a DBMS or a VSAM file. Applications would have to be coded to ENQ and DEQ their access to the temporary storage queue. You could do this without using a temporary storage queue but with shared memory and storing the address of that memory in the CICS CWA for your region. Again, ENQ and DEQ logic would have to be coded in the applications.
You could use a named counter as defined by your CICS Systems Programmer. Be certain to read and understand the recovery requirements for your application as documented in the IBM Knowledge Center.
Again, this is not an exhaustive list, it is just to give an overview of some of the options available. Talk to your technical staff, they likely have either a standard solution as employed by your shop or a preference based on their experience and your requirements.
As my ubiquitous language I have some phrases like :
Feature : Display A Post
In order to be able to check mistakes in a post
As an admin or customer
I want to be able to view the post
Scenario : Display Post
When : I select a post
Then : the post should be viewed
Is that a right user story? Such scenarios may have some minimal differences at UI level. Should I violate the DRY principle and repeat the feature for another role?
Different users may need different requirements over time, and I think this is the reason we usually write user stories per the user role.So should I be worry about how the requirements may change over time for different roles or I can leave a single user story (and the same test code,production code, databse ...) with multiple roles and refactor when their requirements forced me to separate them ?
I am not sure what your problem here and will try to guess. So first, your first three lines is just a description and not real steps. This enables adding custom text that will not run.
As to your other 2 steps, it is very hard to say whether they are good or not. As you might have already noticed, you are not bound by Cucumber to have a specific scenario flow. Cucumber gives you the freedom to design and write your code the way it makes more sense to YOU and YOUR business logic.
Saying that, I see no issue in repeating similar steps to test another role. In order to make the feature file a bit more DRY you can use the Scenario Outline option. It might look something like this:
Scenario Outline: Display Post as <role>
When I select a post as <role>
Then the post should be viewed
Examples:
|role |
|role1|
|role2|
In this case, two scenarios run one after another while rolevalue changes according to the Examples list.
Now, in regards to your possible changes in future. You can't always predict what will happen in future and unless continuously changing current requirements is a normal practice for you or your team, I wouldn't worry too much about this. If sometime in future current scenarios will become obsolete, you will review them and rewrite them or add new ones accordingly.
If multiple roles are required in a feature, then that means it is an epic, not a feature. It is a must to break down each feature so it only has one role, and it can deliver a single value to a single group of users.
I think the problem here is your language which needs refinement to clarify what you want to do here and why its important.
It seems to me that as an admin looking to fix mistakes in a post that what I need to is to be able to change a post.
A similar thing applies for the customer (should that be author?). If you explore what they will do when a post has been authored with a mistake then you will probably find that different roles interact in different ways. You'll start to ask questions about what happens if the customer and the admin make fixes, and how the customer responds when the admin makes a fix that the customer doesn't like and all sorts of other scenarios.
If you do this you'll probably find that most of your duplication goes away, and you'll learn lots about the differences between customer and admin behaviour in this particular context.
When defining scenarios in Gherkin sometimes there is no clear distinction between Given and When steps, i.e. there is no active interaction with the system from the user and the purpose of the validation is to verify how the system should look under certain circumstances.
Consider the following:
Scenario: Show current balance
Given user is on account page
Then user should see his balance
vs
Scenario: Show current balance
When user goes to account page
Then user should see his balance
I am not sure I would always use the second variant. If I have multiple scenarios sharing the context "user is on account page" and some of them have additional user actions while others don't, then it seems to me it should be valid to keep "user in account page" as a Given step even though it may lack "When" for some scenarios. Is this a valid approach?
Formally and technically Cucumber/SpecFlow doesn't require you to write a When-step or rather Given/When/Then's are just executed in the order they are written in the scenario. In that regard you don't need a When-step.
But, as Andy Waite wrote about, the When-step shows on the action or event that your system takes from the "Setup" to get to the new state that you verifies in the Then-step. In that regard a When-step should be present in every test (as you wrote: what are we testing otherwise).
That leaves your final comment; what about verifying just the setup (Given the system is started, Then the database is clean as a naïve example). In such scenarios the When-step could be skipped.
So, as always, it comes down to readability and understanding. Scenarios are written to make our thoughts about the systems behavior concrete and clear. Use the form that optimize for understanding and learning about the behavior in question.
Without thinking too hard on this I would probably guess that the general advice is to always use a When-step that makes the event or behavior very apparent and clear. I would shy away from implicit and hidden behavior when possible.
I hope this helps.
Generally a scenario consists of 3 parts:
Setup (the Given)
Action (the When)
Verification (the Then)
Sometimes the setup isn't required (or it's implicit). But I can't think of any situations in which you wouldn't need an action and verification.
Agree with Andy + Marcus here but I've a few comments that may be of use.
Gherkin feature files should act as living documentation for the behaviour of your system.
For this reason scenarios should provide enough detail to convey to a developer and other project stakeholders (product owner, testers etc) the business rules that embody that feature.
I think your question may have arisen from not considering this business rule end to end when articulating the scenario. I'd have to ask someone the question , what is a balance? Therefore I feel you may need a step to at least convey the concept - that before a user can look at their balance, they have to have one.
Scenario: Show current balance
Given I have a balance
When I go to my account page
Then I should see my balance
It's important to set system state (i.e. any 'Given' step) to allow you to clearly test that the system is working correctly - otherwise how are you going to determine that the balance is actually correct? You may wish to make this more explicit by specifying some arguments:
Scenario: Show current balance
Given my balance is £10
When I go to my account page
Then I should see my balance as £10
I'm not sure which BDD framework you are using but I use Behat which allows you to map more than one Gherkin step to a step definition. I.e
user is on account page
user goes to account page
can both map to a step definition which navigates a user to a page. The system behaviour is the same, the only reason to distinguish between the two, as you have, would be to make your scenarios more readable.
To my understanding when you write a scenario the are 3 steps that are needed.
A state that your application should be in at the begining.
What the user has to do to reach a certain state.
The outcome/input of the user's action i.e the end point of your scenario.
So the scenario will be something like :
Given the user is on the profile page
When the user goes to the balance page
Then the user should see their balance
The profile page will be where the user can click a button or link to acess their balance.
Then have a background :
Given the user is logged in
And the user has a balance
I have a set of User Stories and I have a set of business rules (primarily laws binding my requirements to be compliant). In Agile SDLC I'm not sure where these "rules" are attached to my user stories.
For example, a user story like:
As a doctor I want to add patient information in order to create a new patient file.
And a rule like:
The following information must be entered in the record of each patient:
(a) patient:
(i) name and given name;
(ii) address;
(iii) date of birth; and
(iv) sex;
These two clearly come together, but how can I link them? As test acceptance definitions in my user story? Another user story?
There are a few different ways I've seen this handled:
An artifact is created to hold the business rule and is stored in some central repository of all the rules so this is known throughout the development team and a storehouse of knowledge is maintained. This can get ugly as there can be hundreds of rules within just a few years of building out an application.
The rules may be put onto separate cards within the user story. Thus, while the user story is that one line, there may be 6-8 cards that make up all the tasks for that story to be completed. For example, there has to be a new patient form created, validation on the form, etc. Thus, it isn't hard to see this crop up down the line on a card as a way to track the requirement that way. This is the most natural to my mind though this isn't where the specific list is going to be 100% written down either as the card could be "ensure some fields on the form are mandatory."
There isn't an explicit link but rather the rule is something for QA or a BA to note for the user to verify that the form does enforce this rule. This is similar to one but the question is what is the responsibility of the developer in this. In this case, it is something for QA to track rather than developers possibly.
The user story is intended to start a discussion, not be a comprehensive list of the requirements. The rule is something that should come up when the developer discusses with the user what does it take to create a new patient file to my mind.
I like the idea of hanging on to cards for a few sprints after the story was done, but I do see the point that the cards will ultimately be destroyed. At the same time, there should be code somewhere that implements the rules in its proper area. To use the example you posted, it may be that in a few places the list of required fields would be noticed as there is the UI layer that has to show the fields and probably an error message but also there should be some Business Logic Layer that has this logic to see that some fields were specifically completed before trying to create a new patient file. The system being built will also house the rules in some form or other, too.
As acceptance criteria. After all these are rules that can be executed as tests. Definitely not new stories, that would just be wrong as there is no deliverable goal.