I want to add decision to JIRA just like I can add comments.
But the decisions have context. This includes options, consequences etc.
Is there anyway I can do this?
You could create a custom issue type for technical decisions.
The custom issue type would have the fields you require (options, consequences, etc.) as custom fields.
If you make the custom issue of type sub-task then you can add as many technical decisions as you want to a task/story.
Related
i'm very new to jira and the abilities of customizing and setting up a project/role/group and so on are very confusing to me.
do you know if there is something like an overview how everything acts together, like an UML diagram?
I'd suggest to go to the admin workflow editor and have a look at those used in your projects (or the default workflow at first) in the graphical representation. There you can look at the transitions between the status and check their details.
You will notice conditions, validators and post-functions, if you want that level of detail you can check those in the standard workflow and see which fields are manipulated and/or checked.
This would be the closest to an UML diagram I could think of.
Other than that I suggest to simply create a test project, create test issues and use those like your company/department works. It will all fall together very quickly, especially if you do that together with people from all roles involved.
Lot's (if not most) of the current Web frameworks provide an admin module for basic CRUD operations, but I find the ones I know usually very limited...
So, my question is, which Web framework out there provide the best administration backend?
By the best, I mean namely:
Domain objects that can be heavily polymorphic. Attributes/relations defined in a class appear when editing a record/instance of any of it's subclasses (and sub-subclasses, and sub-sub-subclasses, etc).
Abstract classes. It's ok to have abstract classes anywhere in the domain classes' hierarchy. Their attributes and relations also show in the records/instances of all descending classes.
Relations. Allow to edit (out-of-the-box) the records/instances that have many-to-many relations, and relations with associative classes (e.g., django calls these intermediate models)
Extension. Allow to extend the admin so that we can use our own "UI controls" for specific domain objects. Some information is just too "exquisite" for an out-of-the-box form-based control to work in a suitable way.
UI Components. Instead of having to choose between using all of it or none of it, it'd be nice to have generic "UI controls" that one could reuse from within any page of the website, to edit specific domain objects.
Programming language is not an issue at this point, although I lean towards the languages (or frameworks) that allow me to express the most information at the domain model level (and that the admin module can then use to give me a richer UI).
I've been playing with Active Admin and Rails Admin for a couple of Rails 3.1 projects I am working on. While both are nice, I've migrated more and more to Rails Admin. I've found it easy to customize, it does a very nice job with associated models, and has a great default UI.
Rails Admin
Definitely good old WebObjects with it rule system called DirectToWeb. It generates everything at runtime based on rules. By default it can display all your entity's properties and relationships.
I guess that every current web framework will offer something like scaffolding, but often times, the work begins as soon as you change your model.
Check out this post and this teaser about the latest DirectToWeb-based framework, ERModern. You use nearly zero code for what you see in the video and you can build entire applications around it. It was sponsored by the iTunes team.
Edit for your bullet points:
Abstract classes and domain objects that can be heavily polymorphic - You handle these using rules.
Editing relations - No problem, it only depends on the design of your components. If you use ERModern, you get this for free.
Generic UI components - This is exactly how DirectToWeb works. You use (or define your own) generic components that display themselves according to the current entity (an object inheriting from EOEnterpriseObject) and the rules that fired for the current state (the D2WContext, essentially a big dictionary).
You can see all of this in action in the 45 minutes long ERModern Intro Video.
This isn't an easy question to answer.
You never specify what language you want to use, and you named some features, but how much of these features do you want.
I mean I could suggest a number of frameworks and tools for ASP.Net MVC or Web Forms but what if you're a PHP developer or a Java developer?
I could suggest SharePoint (and I generally dislike sharepoint, but everything you want is in SharePoint), but then the question to ask is.
How much flexibility and freedom do you want to customize or how much do you want the framework to do and you just be a code monkey.
So I will give you just my opinion.
I use ASP.Net MVC for my custom apps. It does all of what you want and allows me the most freedom to create and extend with tools if I so to do so. Plus out of the box there's a user databse with roles I can easily create out of the boss once I run the app for the first time.
Also CRUD is completely easy and straight forward out of the box. just check it out http://www.asp.net/mvc there's a tutorial section that goes through what you're wanting that you could complete in half a day.
Then there are some OR/M like NHibernate, Entity Framework, Subsonic use www.google.com to find tutorials for these if you're not familiar with them.
Then there's SharePoint it has a learning curve but once you get past it it's pretty straight forward as it's easy to pinpoint bugs, focus on the business logic and not worry aobut data base schema (as you don't even need to touch a database).
I love WebObjects.
WebObjects -> EntityModeler -> Wonder -> ERD2WModernLook -> ERAttachment --> ERRest
Bam. Done.
I am writing features with the same verbiage for some scenarios.
Feature: User Management
Scenario: Edit an existing user's details
Given a user exists
and
Feature: Group Management
Scenario: Add a user to a group's membership
Given a user exists
And a group exists
In SpecFlow is there a good way to define what step each feature calls? Am I going about this the wrong way with my scenario writing? Should I just bite the bullet and change my given statements to denote what feature they apply to? I'm new to BDD and SpecFlow so any help is appreciated.
The Gherkin format (that the tools in the Cucumber-family, like SpecFlow uses) does not have any structure for sharing steps between features (inside a feature, you can use backgrounds).
The meaning behind this is that the features should be self-describing and complete in their own. With using the Background section, you can avoid having too long scenarios, but still having all information together in the file. You have to repeat the shared steps for each feature, though.
As an alternative, you can also create event bindings (that is like "hooks" in cucumber), where you can implement some shard logic. But this shared logic has to be implemented in .NET then.
I am looking for examples of configuration based validation using Validation Application Block. I've found this
I want to ask if someone has an alternative solution to using EL VAB 5.0 to achieve configuration based validation. I've started with DataAnnotations but soon found out that some properties will need different types of validation depending on who is using the application.
Also if anyone has more examples for configuration with VAB and any advice as to what I might run into, please share.
There are several paths you can walk to achieve this. First of all you can (ab)use rulesets for this. You can create a 'base' ruleset with rules that hold for everybody and you can make a ruleset per role in the system and perhaps even a ruleset per user, but of course that would be cumbersome.
Another option would be to create an IConfigurationSource implementation that is able to return a ValidationSettings instance, based on the logged in user. Now there are several ways that you can build a ValidationSettings object. Here are a few examples:
You can load multiple configuration files from disk using the FileConfigurationSource based on the role. Something like: return (new FileConfigurationSource('validation_' + role + '.config')).GetSection(sectionName);
You can build up the ValidationSettings instances dynamically (and cache them). You can store this definition in the database and load them (this would be a lot of work) or define them in code (perhaps separated by assembly). Here is an example of a code based configuration.
Also to prevent having to duplicate parts of your configuration, you can do the following:
Merge multiple configurations together. You can for instance merge the base line validation with the role specific validation. This saves you from having to manually validate according to the base line and do a second validation for the role specific validation. While this is not supported out of the box, I wrote about how to do this on my blog here.
You can merge rules based on type inheritance. While VAB only supports validator inheritance for attribute based validation out of the box, I've wrote about this on my blog, here.
I hope this helps.
I'm working on an application in which we are trying hard to keep Separation of Concerns as strongly as possible. We're finding that the cross-cutting concern of security creates a number of complications.
However, it looks like these can be mitigated using attributes and Aspect-Oriented Programming.
I understand it as far as applying aspects to domain layer code, but what if you want to apply it to UI elements? For instance, what if I don't want to display a button when a user does not have permission to execute that functionality?
In our MVC application, at this point we'd have to write (pseudo-code follows):
<% if (user.CanSeeSomeData) { <%=Html.TextBox("MyTextBox") } %>
But we'd like to control the display with attributes a la AOP if possible.
Any ideas?
Also, if there are 3rd party, open-source tools that would be useful, those suggestions are welcome.
I'd say that a view shouldn't contain much programming (or nothing at all). The idea of using AOP (or a la AOP) in a place where the P is forbidden doesn't look nice.
Let's design it in a different way. Usually views have some control keywords to do the basic stuff: conditions and loops. More intelligence and I'd say that you're mixing the controller role there.
So the if (user.CanSeeSomeData) you put there, if it is in fact a simple flag. It's the way views should be.
When you were building the modelview object (the container where you put the information for the view). You could have used AOP to initialize/set that information with a nice attribute in that property for example.
You could ask for attributes instead of "ifs"
[UserCanSeeData]
<%=Html.TextBox("MyTextBox") %>
This looks like syntactic sugar, not real AOP. Any attempt to say that UserCanSeeData should have more than an if (like a database access to check user priviledges), is an attempt to move controller code into the view.