is there any way to accomplish the following?
I would like for each object in Plone would be associated with one more security classifications (e.g. 'alpha', 'bravo', 'zulu'). These classifications would be part of the content type's schema. At runtime, the user's security credentials would be compared against the object, and if and only if the user had all the credentials of the object would the object be viewable. I can't see any way of doing this in workflow.
Open to suggestions. Thanks!
Stan
You need a localrole adapter that can examine the user's credentials (presumably you already have some one to give them such credentials, as - beyond the basic concept of roles - they don't exist in base Plone), and grant a local_role based on the result.
See: http://plone.org/products/plone/roadmap/208.
It might be as simple as providing an __ac_local_roles() method, but if not, borg.localrole is now part of Plone and that link should get you started.
Bear in mind that CMFWorkflow allows for an object to have more than one workflow associated with it. It might be possible for you to implement the various levels of your scheme as individual workflows and then attach them to your objects.
Here is also how you could do it with workflow. Note I am not saying you should do it with workflow, just that you can ;)
You would need a (large) number of states. How large depends on the combinations (!=permutations) of your security states. The combinations of choosing m things among n things is given by:
n!/(m!(n-m)!),
where ! is the factorial.
For instance for the example you give you have 3 security states alpha, bravo and zulu. This gives:
3!/(1!2!) + 3!/(2!1!) + 3!/(3!0!) = 3 + 3 + 1 = 7
The sum is the combinations of having 1, 2, or 3 of them together.
So there you go, seven states all in all;)
The transitions are a different beast. If you do need to be able to go from any of these combined states to any other then you would have to calculate permutations as going from a to b is different to going from b to a. Permutations are given by:
n!/(n-m)!
i.e. for the 7 states above you would have 7!/(7-2)!=7*6=42 (!!!) transitions. You could of course simplify the transitions by only allowing adding/removing one security state each time.
There you go, I hope you have as much fun reading this as I had writing it :)
Related
I have some scenarios with too many parameters and most of the parameters causes the variation of scenarios. Therefore, I need to include parameter details in scenario name to give insight about the scenario. However, this causes too long Scenario lines.
For Example:
Scenario: Create list for Today's unique stuff of 'X' item with multiple string attribute values and 'distinct count' aggregation
Given I create a 'Create List' request and name as 'New List'
When I add 'X' item to 'Create List' request
And I add item attribute to current list query on list preview request
| attribute | operator | values |
| id | EXMATCH | id1,id2 |
And I add list aggregation to current list query on 'Create List' request
| aggField | aggType |
| stuff | DISTINCT_COUNT |
And I send request to 'Create List' request date as 'TODAY'
Then 'success' parameter in response should be true
And received list name should be equal to created list name
And received list queries in 'Create List' response should be equal to created list queries
Another Scenario:
Scenario: Create list for Today's unique stuff of 'X' item with multiple integer attribute values and 'sum' aggregation
Or:
Scenario: Create list for Today's unique stuff of 'X' item with multiple integer attribute values, 'sum' aggregation and <some other parameter related conditions which causes too long scenario name>
This can go on and on according to the number of different parameters who effects the scenario.
I have a feeling like there must be best practices writing clearer and shorter scenario names. Are there any?
How should I handle these long scenario names? Or, can I find easer/shorter way of express the content of scenario?
Cucumber allows you to use natural language (as opposed to a programming language) to write your scenarios. You can use all the tools of natural language to simplify your scenarios.
The two most powerful tools to simplify are
abstraction
naming
These tools work hand in hand. With abstraction you take something with alot of details and abstract it into something simpler that removes the details. You use naming to give this new thing a name. If your name is good you can know talk about your complex thing using your new simple term and no longer have to talk about the details.
To make you scenarios simpler you need to abstract, remove the details, and give things good names. The way to do this is to read your scenario and differentiate between WHAT you are doing and HOW you are doing it. Then have your scenarios focus on only saying WHAT they are doing and not saying anything about HOW they are doing it.
One additional tool when thinking about WHAT something is doing is to also think about WHY someone is doing the thing. So lets have a look at your scenario and formulate a few questions.
We do this all the time in computing. Every time we write a method/function we are abstracting and naming. We do this even more often in real life. When you order a coffee you don't say
"I'd like a double expresso in a warmed cup with 3oz of milk wet
foamed at 60C poured with a swan pattern"
You say
"I'd like a flat white"
And of course a double expresso is just another abstraction for a set of instructions that talks about water temperature, number of grammes of coffee, grind settings (extra fine), pressure of water etc. etc.
By using abstraction and naming we can talk eloquently about coffee with all its complexity without mentioning any of the details.
So what is the 'flat white' or 'double expresso' for your scenario?
Your scenario seems to be about creating some sort of a list.
WHAT sort of list is this?
WHY are you creating it?
WHAT will people use this list for?
WHY will people find this list useful?
Once you have asked and answered these questions you can start thinking about how to simplify. When you answer these questions, use the answers to
name your feature
describe your feature
write a preamble for your feature (the bit between Feature and the first Scenario)
write you Scenario titles
You shouldn't start writing a scenario until you have all of this done, and have a Feature that tells you WHAT your scenarios are going to be about and WHY its important for you to do these things.
You also talk about the parameters you are adding causing a variation in the scenarios. So for each parameter you are adding you should be asking
WHAT sort of variation does this parameter cause?
WHY is this variation important? Is it important enough to have its own scenario?
Again think about sets of parameters creating named things like a mocha, cortado or latte.
When you have answered these questions you can remove the parameters from your scenarios. Each set of parameters that creates a variation. For each variation you can remove the parameters by abstracting and giving a name to the variation
If you apply this approach and answer these questions then you transform your scenarios into something much simpler
I'm quite new to DDD so apologies if this is well writ but I have struggled to find an answer.
In our domain we have a representation of a 'Normal Shift', e.g. Afternoon: 15.00 - 18.00. It is possible however for shifts to be modified either on specific days of the week (Mon - Sun) or for specific 'Locations'. The end result should be the same shift (Afternoon for example) but with a new time on a specific day / at a specific location.
How should we model these updated shifts? So far we've come to.
A common 'Shift' object which can be applied as a Normal Shift and also associated to a day or location.
A model to denote the change 'Shift Adjustment'.
Unique models for each shift, with some kind of relationship so they can be applied. E.g. 'Location Shift'.
We keep toggling between 1 & 3. 1 seems like a more natural language fit yet 3 feels more complete in that the business logic isn't hiding real facets of the model.
Any help would be greatly appreciated!
First, I think this initially has nothing to do with DDD. Rather it is about how you represent these concepts in your domain model.
You don't state explicitly the behavior you require. So, I'm guessing you may want to be able to send a message to an appropriate object in your model to get you a shift ... FindShift(name,[day,location]). FindShift would return either a default shift, or a custom one if it exists. Providing the day and location might be optional.
One simple way to represent this is as follows:-
A Shift has an optional day and location. This solution requires a business rule (a constraint) preventing applicable duplicates.
There are other ways to model this, especially in regards to making "default" shifts explicit. But it's hard to do so if you don't state the behavior required, rather than just a structural description.
I have a requirement in which I need to import data from excel (CSV) to Dynamics CRM regularly.
Instead of using some simple Data Duplication Rules, I need to implement a point system to determine whether a data is considered duplicate or not.
Let me give an example. For example these are the particular rules for Import:
First Name, exact match, 10 pts
Last Name, exact match, 15 pts
Email, exact match, 20 pts
Mobile Phone, exact match, 5 pts
And then the Threshold value => 19 pts
Now, if a record have First Name and Last Name matched with an old record in the entity, the points will be 25 pts, which is higher than the threshold (19 pts), therefore the data is considered as Duplicate
If, for example, the particular record only have same First Name and Mobile Phone, the points will be 15 pts, which is lower than the threshold and thus considered as Non-Duplicate
What is the best approach to achieve this requirement? Is it possible to utilize the default functionality of Import Data in the MS CRM? Is there any 3rd party Add-on that answer my requirement above?
Thank you for all the help.
Updated
Hi Konrad, thank you for your suggestions, let me elaborate here:
Excel. You could filter out the data using Excel and then, once you've obtained a unique list, import it.
Nice one but I don't think it is really workable in my case, the data will be coming regularly from client in moderate numbers (hundreds to thousands). Typically client won't check about the duplication on the data.
Workflow. Run a process removing any instance calculated as a duplicate.
Workflow is a good idea, however since it is being processed asynchronously, my concern is the user in some cases may already do some update/changes to the data inserted, before the workflow finish working.. therefore creating some data inconsistency or at the very least confusing user experience
Plugin. On every creation of a new record, you'd check if it's to be regarded as duplicate-ish and cancel it's creation (or mark for removal).
I like this approach. So I just import like usual (for example, to contact entity), but I already have a plugin in place that getting triggered every time a record is created, the plugin will check whether the record is duplicat-ish or not and took necessary action.
I haven't been fiddling a lot with duplicate detection but looking at your criteria you might be able to make rules that match those, pretty much three rules to cover your cases, full name match, last name and mobile phone match and email match.
If you want to do the points system I haven't seen any out of the box components that solve this, however CRM Extensions have a product called Import Manager that might have that kind of duplicate detection. They claim to have customized duplicate checking. Might be worth asking them about this.
Otherwise it's custom coding that will solve this problem.
I can think of the following approaches to the task (depending on the number of records, repetitiveness of the import, automatization requirement etc.) they may be all good somehow. Would you care to elaborate on the current conditions?
Excel. You could filter out the data using Excel and then, once you've obtained a unique list, import it.
Plugin. On every creation of a new record, you'd check if it's to be regarded as duplicate-ish and cancel it's creation (or mark for removal).
Workflow. Run a process removing any instance calculated as a duplicate.
You also need to consider the implication of such elimination of data. There's a mathematical issue. Suppose that the uniqueness' radius (i.e. the threshold in this 1D case) is 3. Consider the following set of numbers (it's listed twice, just in different order).
1 3 5 7 -> 1 _ 5 _
3 1 5 7 -> _ 3 _ 7
Are you sure that's the intended result? Under some circumstances, you can even end up with sets of records of different sizes (only depending on the order). I'm a bit curious on why and how the setup came up.
Personally, I'd go with plugin, if the above is OK by you. If you need to make sure that some of the unique-ish elements never get omitted, you'd probably best of applying a test algorithm to a backup of the data. However, that may defeat it's purpose.
In fact, it sounds so interesting that I might create the solution for you (just to show it can be done) and blog about it. What's the dead-line?
I think I thoroughly understand the concepts and ideas behind SpecFlow, but even after reading the Secret Ninja Cucumber Scrolls, The Cucumber Book, and going through the various forums I'm still unsure about the path to reusability.
Our scenarios already comply to various guidelines
Self explanatory
Must have a understandable purpose (what makes it different from the other scenarios)
Are unique
Represent vertical functional slices
Uses Ubiquitous Language
Written from the stakeholder perspective
About business functionality, not about software design
Grouped by Epics
ARE NOT TEST SCRIPTS
Let somebody else read them to see if the scenario is correct
Doesn't refer to UI elements
Represent key examples
Non-technical
Precise and testable
As repeatable as possible
'Given' represent state, not actions
'When' represent actions
'Then' should represent a visible change, not some internal event
Our steps have to comply to the following guidelines (some are specific to SpecFlow):
Uses Ubiquitous Language
Doesn't refer to UI elements
Should not be combined
Should be reusable and global over all features
Should not be linked to a specific feature
Grouped by entities, entity groups or domain concepts
Don't create steps to reuse logic in a step definitions file
Think thoroughly in what Steps file a step belongs
Don't reuse steps between phases
Literal strings in steps must be avoided, but if required use single quotes
Never apply multiple [Given], [When] or [Then] attributes to the step
method
Order the steps according to the phase they represent
If it is not important for the scenario, it is very important not to mention it
But we still end up with lots of variations of the same steps, even if we use regex placeholders. Especially the rule that if something is not important, you shouldn't mention it results in those variations. And yes, internally these steps do a lot of reusing, but not in the scenario.
Consider for example the following scenario:
Feature: Signing where both persons are physically available
#Smoke
Scenario: Show remaining time to sign based on previous signature
Given a draft proposal
And the first signature has been set
When I try to set the second signature
Then the remaining time to sign should be shown
#Smoke
Scenario: Re-signing of the first proposal
Given a signature that has not been set within the configured time
And the first signature has just been re-signed
When I try to set the second signature
Then the remaining time should start over
Would it be better to combine the two 'given' steps into one and loose some reusability?
Some other examples:
Feature: Conditionally show signatures to be signed
#Smoke
Scenario: Show the correct signature for a proposal with a night shift
Given I have a proposal for the day shift
When I change it to the night shift
Then I should only be able to sign for the night shift
#Smoke
Scenario: Show additional signature when extending the shift
Given I have a suspended proposal for the night shift
When I extend the period to the day shift
Then I should confirm extening the period over the shift
Am I missing a fundamental concept here?
This is not an answer, but some hints:
you can put multiple Given/When/Then attributes on the same method. If the parameters are the same and the difference is only in phrasing, this can be useful
in many project we use driver/page object pattern, so the step definitions are usually quite short (2-3 lines), so we bother less about the number of them
I like your scenarios, I would not change them. On the other hand try to focus on the readability and not the reusability. If your language is consistent, the reusability will come.
For increasing the reusability especially when there are a lot of "variations" of the entity you are talking about, you can consider using the step argument transformations. Here is an example:
you need a class to represent a permit in the tests with decorations:
class PermitDescription{
bool suspended;
bool draft;
}
create converter methods:
[StepArgumentTransformation("permit")]
public PermitDescription CreateSimple(){
return new PermitDescription();
}
[StepArgumentTransformation("draft permit")]
public PermitDescription CreateDraft(){
return new PermitDescription() { draft = true; }
}
[StepArgumentTransformation("suspended permit")]
public PermitDescription CreateSuspended(){
return new PermitDescription() { suspended = true; }
}
you can have now more flexible step definitions that require permits:
[Given(#"I have a (.*) for the day shift")]
public void Something(PermitDescription p)
{ ... }
that matches to:
Given I have a permit for the day shift
Given I have a draft permit for the day shift
Given I have a suspended permit for the day shift
of course this is tool that can be also abused, but in some cases it can help.
Adding onto the answer from #gaspar-nagy
It follows the pattern of class design in C programming. Anywhere a common group of classes share common properties/methods, those properties/methods can be refactored into a base class.
What it looks like in our SpecFlow tests is that common browser operations are in the base classes:
Login()
Logout()
NavigateToUrl(string url)
UserHasPermission(string permission)
WaitForElementToAppearById(string id)
WaitForElementToAppearByClass(string class)
And each of those methods could have 1 or more Given/When/Then attributes like #gasper-nagy stated.
Another technique which proves invaluable is to share variables between .features and their respective C# step files is to use the ScenarioContext.
For example, whenever Login() is called to initiate our browser based tests, we do this:
ScenarioContext.Current.Set<IWebDriver>(driver, "driver")
Then anywhere else that needs the driver, can get it by:
var driver = ScenarioContext.Current.Get<IWebDriver>("driver")
This makes steps re-usable, such as user input tests for validation you may decide to pass the element being validated around like this:
ScenarioContext.Current.Set<IWebElement>(element, "validation-element")
Suppose that a group wants to encrypt some information, then share the encryption key among the group members in a way that requires the consensus of the group to decrypt the information. I'm interested in a variety of scenarios where the breadth of consensus ranges from unanimity to an absolute majority. A useful technique can apply to symmetric keys, private keys, or both.
I could take a crack at rolling my own method, as I'm sure many SO members could. But for the purposes of this question, I am interested only in methods that have been widely published and have withstood scrutiny by expert cryptanalysts. Journal citations are good, but interpretation of academic sources are very useful too.
I have always been fascinated by this secret sharing technique. I've seen code implementing it on the internet, but have never seen actual applications. Shamir's secret sharing The wikipedia article links to some actual code, as well as the original academic article.
What you describe sounds a lot like "secret splitting" (Section 12.1. Introduction to Cyptography. Trappe & Washington. 2nd ed) The basic idea is you can come up with a polynomial that includes your "secret" (a key) as a point on the line. You can give out "shares" by picking other points on this polynomial. Two points define a line of the form f(x) = ax + b, three points define a polynomial of the form f(x) = ax^2 + bx + c, and four points define something of the form f(x) = ax^3 + bx^2 + cx + d, and so on. You can choose a polynomial that includes your secret as a point, and a degree for the polynomial sufficient so that any N people can reconstruct it.
This is the basic idea that is known as the "Shamir threshold scheme."
See wikipedia on Secret Splitting and Shamir's Secret Sharing
The wikipedia page has some links to implementations of this idea, including GPL'd code for Windows and UNIX.
This is easy to implement with error-correcting codes. You could use a command-line tool such as par2 (which is not exactly appropriate for this specific purpose btw, as it generates recovery blocks of varying size). Let's say you have (n+m) voters, and want a quorum of n votes. You generate n private keys K₁∘, K₂, ... Kn, and generate m additionnal ECC blocks Pₓ of the same size. That way any n blocks suffice to reconstitute the cipher K₁∘K₂∘...∘Kn
Go here for a discussion of the mathematical basis to Shamir's secret sharing and brief discussion of the type of practical applications that it has. Scroll down the page to the lecture notes on Polynomials and Secret Sharing. It's probably a v. basic overview of the area, but should be quite interesting for you.
Discrete Mathematics Notes
Lotus Notes provides a practcal implementation of 'Silo passwords' whereby access to some resource (data/info/document) is locked to a 'shared-id' - The ID (part of a certfied PKI system I think based on RSA) is setup with 2 or more (I think up to 16) individual user passwords. The certifier/administrator sets up a scheme whereby any number of passwords from those available or all passwords are necessary to 'open' the id for active use. This process is commonly used to lock-down Org or OU certificates to 2 of 5 or 3 of 5 administrators/corporate officer grant access and so ensure that high-level certificate usage/access can be controlled and absentee admin personnel are avoided.