I am using the TFS 2010 SCRUM template and was wondering if you can modify the task work item's workflow to not allow modifications in case a processor task is not yet done. Another option is to automatically set the state of a successor task to something so it cannot be changed until the processor tasks have been set to a specific state. Not sure if you can get this granular with the workflow.
While there is a parent/child relationship you can build in 2010- I don't see anything in WorkFlow that would allow you to modify the Scrum WI templates to support this.
An alternative solution would be to make the WI only editable by the person who it is assigned to. You can keep all your WIs assigned to a lead or PjM etc until the processor task is done and then assign it to the person in charge of the task.
<FieldDefinition reportable="dimension" refname="System.ChangedBy" name="Changed By" syncnamechanges="true" type="String">
<COPY from="currentuser" />
<FROZEN />
</FieldDefinition>
Aside from that, you may also consider a model where you cannot edit a WI until it is at a specific state. For example, when X WI turns Active make everything editable and if it is still Proposed then make everything read-only using the WHENNOT clause.
And finally, why not consider just discussing these things in the daily scrum? Team members should be on the same page about WIs. Impediments are always going to come up and sometimes what you think the order of tasking will be at the beginning of the sprint planning is not how it turns out during the sprint. A team task board can be very helpful to in order to discuss order etcetera.
Blocking devs or team members from modifying X item until Y item is complete where both X and Y are sprint backlog items assigned to a sprint may lead to more harm than good and ultimately detract from the ideals behind scrum (namely agility). All that to say, before making this type of a modification make sure you absolutely need to.
Related
I already check this however I would like to know what the common practice is for the next situation. I have several roles in a web I'm creating, only one role can create the others, now I wonder if for the others I can test in just 1 test function. Something like:
def test_cannot_create_user(self):
for role in ['role_1','role_2','role_3']: #roles that can't create
for user in ['role_1','role_2','role_3','role_4']: # all roles
# assign user to a role
# user with role fails on creating user
# do assertions
# remove user from group
Or should I create a function for each role and for each role to fail to be created?
Design is what we do to get more of what we want than we would get by just doing it.
When we are refactoring (as in red green refactor), the structure of our tests doesn't matter very much, because any test failure is always a consequence of the change that we just made - we don't need fine grain reporting, because we already know where the problem is.
But when we are doing a merge with someone else's code, having a clear report of a failure means that we can more clearly guess where we need to look for the problem that has been introduced.
When we are trying to inspect our test reports, then one of the things we care about in an audit is "what did we test" - having a clear enumeration of the cases in that report is better aligned with that goal than is expecting people to dig into the test details.
Horses for courses
What you can do in some frameworks is create a "parameterized" test, where you have a single test function, that accepts input arguments, with those arguments also being copied into the test report.
In your case, that might look something like
def test_cannot_create_user(self, role):
# your test code here
A good video to review would be Kevlin Henney's 2016 talk, where he discusses some test design considerations for a simple Gregorian leap year calculation; how should you design your tests if you want them to accurately describe your requirements.
Consider the following scenario:
Our Django database objects must rely on IDs that are provided by external service A (ESA) - this is because we use this ID to pull the information about objects that aren't created yet from the external directly. ESA might shut down soon, so we also pull information about the same objects from external service B (ESB), and save them as a fallback.
Because these IDs are relied on heavily in views and URLs, the ideal scenario would be to use a #property:
#property
dynamic_id = ESA_id
And then, if ESA shuts down, we can switch easily by changing dynamic_id to ESB_id. The problem with this though, is that properties cannot be used in queryset filters and various other scenarios, which is also a must in this case.
My current thought is to just save ESA_id, ESB_id, and dynamic_ID as regular fields separately and assign dynamic_ID = ESA_id, and then, in case ESA shuts down, simply go over the objects and do dynamic_ID = ESB_id.
But I feel there must be a better way?
Having ESA_id and ESB_id fields in the same table is a good solution, then you have some kind of setting (DEFAULT_SERVICE_ID='ESA_id'|'ESB_id') and your code change the lookup based on this option.
Here you can see an aproach to create filters dynamicly
https://stackoverflow.com/a/310785/1448667
In our build , we use to delete our view and create new view before build.
It was working without any issue in base clearcase.
But in UCM we face issues while check-out and check-in due to activity name has to be assigned every time.
Is it a good practice to create new activity whenever i build? [ But number of activities will be soon increased to enormous]
Is there any easy way to setup default activity automatically in UCM?
Has any body automated this in their build process? If so can you share link or something useful resource..
#Samselvaprabu , agreeing with VonC on other things and that activities are,at best, logical groupings of code/development tasks. For example 5 source code + 1 property files for resolving a QA defect.
Though when you ask how many activities ? there is no specific guideline which IBM provides (AFAIK) on this, but in my experience
A typical activity may not have too few, meaning 1,2 files or too many (say 15+) files.
An activity naming convention (though inconsistent when manual) would help. For example username_ShortDescreption/DefectID_date might help in organizing, sorting of activites when the need arises. And trust me, it will.
Obsoleting activities based on some criteria such as age (more than 1 month) is good for housekeeping.
An activity per build ?? - I would say this is subjective to how many times you build, how many artifacts go per build , how many view/developers you have and so on. You could have a build<>activity relationship which is 1<>n or n<>1 which is completely case-specific to your environment. That's the beauty and also the curse of UCM.
These suggestions are not exactly would you asked for but I feel this a a good time to give them as you are just starting with this complex, messy world called UCM :)
Use cleartool setact to set your activity.
setact/ivity [ –c/omment comment | –cfi/le pname | –cq/uery | –nc/omment ]
[ –vie/w view-tag ] { –none | activity-selector }
You might need to unset the current activity first from your view:
Cleared current activity from view java_int.
cleartool setactivity -none
Then, Set an activity to be the current activity.
cleartool setactivity create_directories
Set activity "create_directories" in view "webo_integ".
See "Setting UCM activities" for more:
You can set only one activity per view at a time, and all checkouts in your view are associated with the currently set activity until you unset the activity or set another one.
cleartool setact -view <myViewTag> <anActiviyName>
(-view set before the activity name)
Note that if you are changing the activity while you have pending checkouts, you will have a warning.
You usually associate activities to a development task instead of a build number.
Since you don't version what you are building (the executables), you don't have to make a new activity per build.
I am using mTurk for surveys, and I need a way of making sure that people who have participated in a previous survey / HIT do not participate in certain future surveys / HITs. I am not sure whether I should do this as a qualification or in some other way.
I know there is some way to do this, but I have no idea how. I have very limited programming experience and would greatly, greatly appreciate specific instructions on how I might do this. My understanding is that I might need to use AWS? Many thanks!
Mass rejections as suggested above are a really, really bad idea in terms of your reputation as a requester. You are much better off creating a Qualification for the new HIT, which automatically grants a score of 100 (or whatever) to anyone who takes it, and assigning scores of zero to everyone who has done the previous surveys. This prevents repeats but doesn't annoy any of your workers.
The easiest way to create a Qualification is at https://requester.mturk.com/qualification_types.
If you download the csv of workers from here https://requester.mturk.com/workers, you can assign scores to workers who have done the previous HIT(s).
To make the qualification grant scores to new workers automatically requires the API, though.
Here's a hacky way to do it:
When you accept HITs for surveys, save every participating worker's ID.
In the writeup, note that "if you've done previous surveys w/ us, then you can't do this one (IE, you can, but we won't approve it)".
When you approve HITs, cross-reference the worker ids with anybody who participated in a previous survey, and reject the hits of any that match.
If you're doing enough surveys, then yes, you probably want to use AWS API for at least the approval part. otherwise, most things appear to be do-able from the requester interface.
Amazon Mechanical Turk service has this option for requesters to grant their workers by Qualification_Type. In this way by connecting your HITs to a qualification_type naming "A", then granting workers exactly the same qualification_type, only workers who have that qualification can see and work on HITs.
First, creating desired qualification types through mturk web UI.(it is only name and description) requester.mturk.com > manage > QualificationTypes. It will give you a qualification id after generating it. (you will need it soon)
Second, in HIT creation loop, you have to use QualificationRequirement class. (I am using java code and it looks like the below-mentioned code):
QualificationRequirement[] qualReq = new QualificationRequirement[1];
qualReq[0] = new QualificationRequirement();
qualReq[0].setQualificationTypeId(qualID);
qualReq[0].setComparator(Comparator.EqualTo);
qualReq[0].setIntegerValue(100);
qualReq[0].setRequiredToPreview(false);
then in HIT creation loop, I will use this:
try {
hit = this.service.createHIT(null,
props.getTitle(),
props.getDescription(),
props.getKeywords(),
question.getQuestion(),
new Double(props.getRewardAmount()),
new Long(props.getAssignmentDuration()),
new Long(props.getAutoApprovalDelay()),
new Long(props.getLifetime()),
new Integer(props.getMaxAssignments()),
props.getAnnotation(),
qualReq,
null);
Third is assigning the qualification type to the workers that you want them to work on your HITs. It is very straightforward, I usually use mturk UI to do it. https://requester.mturk.com/ > manage tab > Workers. You should download the CSV file if you want to assign this qualification to a bunch of workers.
(Workers are who worked with you in the past)
you could notify workers by sending them an email after qualifying them
Notice: Some workers are very slow in answering your new HITs after qualifying them; so keep in mind that you should have some backup plan and time if you will not receive enough response in a certain amount of time.
If there a way to protect against concurrent modifications of the same data base entry by two or more users?
It would be acceptable to show an error message to the user performing the second commit/save operation, but data should not be silently overwritten.
I think locking the entry is not an option, as a user might use the "Back" button or simply close his browser, leaving the lock for ever.
This is how I do optimistic locking in Django:
updated = Entry.objects.filter(Q(id=e.id) && Q(version=e.version))\
.update(updated_field=new_value, version=e.version+1)
if not updated:
raise ConcurrentModificationException()
The code listed above can be implemented as a method in Custom Manager.
I am making the following assumptions:
filter().update() will result in a single database query because filter is lazy
a database query is atomic
These assumptions are enough to ensure that no one else has updated the entry before. If multiple rows are updated this way you should use transactions.
WARNING Django Doc:
Be aware that the update() method is
converted directly to an SQL
statement. It is a bulk operation for
direct updates. It doesn't run any
save() methods on your models, or emit
the pre_save or post_save signals
This question is a bit old and my answer a bit late, but after what I understand this has been fixed in Django 1.4 using:
select_for_update(nowait=True)
see the docs
Returns a queryset that will lock rows until the end of the transaction, generating a SELECT ... FOR UPDATE SQL statement on supported databases.
Usually, if another transaction has already acquired a lock on one of the selected rows, the query will block until the lock is released. If this is not the behavior you want, call select_for_update(nowait=True). This will make the call non-blocking. If a conflicting lock is already acquired by another transaction, DatabaseError will be raised when the queryset is evaluated.
Of course this will only work if the back-end support the "select for update" feature, which for example sqlite doesn't. Unfortunately: nowait=True is not supported by MySql, there you have to use: nowait=False, which will only block until the lock is released.
Actually, transactions don't help you much here ... unless you want to have transactions running over multiple HTTP requests (which you most probably don't want).
What we usually use in those cases is "Optimistic Locking". The Django ORM doesn't support that as far as I know. But there has been some discussion about adding this feature.
So you are on your own. Basically, what you should do is add a "version" field to your model and pass it to the user as a hidden field. The normal cycle for an update is :
read the data and show it to the user
user modify data
user post the data
the app saves it back in the database.
To implement optimistic locking, when you save the data, you check if the version that you got back from the user is the same as the one in the database, and then update the database and increment the version. If they are not, it means that there has been a change since the data was loaded.
You can do that with a single SQL call with something like :
UPDATE ... WHERE version = 'version_from_user';
This call will update the database only if the version is still the same.
Django 1.11 has three convenient options to handle this situation depending on your business logic requirements:
Something.objects.select_for_update() will block until the model become free
Something.objects.select_for_update(nowait=True) and catch DatabaseError if the model is currently locked for update
Something.objects.select_for_update(skip_locked=True) will not return the objects that are currently locked
In my application, which has both interactive and batch workflows on various models, I found these three options to solve most of my concurrent processing scenarios.
The "waiting" select_for_update is very convenient in sequential batch processes - I want them all to execute, but let them take their time. The nowait is used when an user wants to modify an object that is currently locked for update - I will just tell them it's being modified at this moment.
The skip_locked is useful for another type of update, when users can trigger a rescan of an object - and I don't care who triggers it, as long as it's triggered, so skip_locked allows me to silently skip the duplicated triggers.
For future reference, check out https://github.com/RobCombs/django-locking. It does locking in a way that doesn't leave everlasting locks, by a mixture of javascript unlocking when the user leaves the page, and lock timeouts (e.g. in case the user's browser crashes). The documentation is pretty complete.
You should probably use the django transaction middleware at least, even regardless of this problem.
As to your actual problem of having multiple users editing the same data... yes, use locking. OR:
Check what version a user is updating against (do this securely, so users can't simply hack the system to say they were updating the latest copy!), and only update if that version is current. Otherwise, send the user back a new page with the original version they were editing, their submitted version, and the new version(s) written by others. Ask them to merge the changes into one, completely up-to-date version. You might try to auto-merge these using a toolset like diff+patch, but you'll need to have the manual merge method working for failure cases anyway, so start with that. Also, you'll need to preserve version history, and allow admins to revert changes, in case someone unintentionally or intentionally messes up the merge. But you should probably have that anyway.
There's very likely a django app/library that does most of this for you.
Another thing to look for is the word "atomic". An atomic operation means that your database change will either happen successfully, or fail obviously. A quick search shows this question asking about atomic operations in Django.
The idea above
updated = Entry.objects.filter(Q(id=e.id) && Q(version=e.version))\
.update(updated_field=new_value, version=e.version+1)
if not updated:
raise ConcurrentModificationException()
looks great and should work fine even without serializable transactions.
The problem is how to augment the deafult .save() behavior as to not have to do manual plumbing to call the .update() method.
I looked at the Custom Manager idea.
My plan is to override the Manager _update method that is called by Model.save_base() to perform the update.
This is the current code in Django 1.3
def _update(self, values, **kwargs):
return self.get_query_set()._update(values, **kwargs)
What needs to be done IMHO is something like:
def _update(self, values, **kwargs):
#TODO Get version field value
v = self.get_version_field_value(values[0])
return self.get_query_set().filter(Q(version=v))._update(values, **kwargs)
Similar thing needs to happen on delete. However delete is a bit more difficult as Django is implementing quite some voodoo in this area through django.db.models.deletion.Collector.
It is weird that modren tool like Django lacks guidance for Optimictic Concurency Control.
I will update this post when I solve the riddle. Hopefully solution will be in a nice pythonic way that does not involve tons of coding, weird views, skipping essential pieces of Django etc.
To be safe the database needs to support transactions.
If the fields is "free-form" e.g. text etc. and you need to allow several users to be able to edit the same fields (you can't have single user ownership to the data), you could store the original data in a variable.
When the user committs, check if the input data has changed from the original data (if not, you don't need to bother the DB by rewriting old data),
if the original data compared to the current data in the db is the same you can save, if it has changed you can show the user the difference and ask the user what to do.
If the fields is numbers e.g. account balance, number of items in a store etc., you can handle it more automatically if you calculate the difference between the original value (stored when the user started filling out the form) and the new value you can start a transaction read the current value and add the difference, then end transaction. If you can't have negative values, you should abort the transaction if the result is negative, and tell the user.
I don't know django, so I can't give you teh cod3s.. ;)
From here:
How to prevent overwriting an object someone else has modified
I'm assuming that the timestamp will be held as a hidden field in the form you're trying to save the details of.
def save(self):
if(self.id):
foo = Foo.objects.get(pk=self.id)
if(foo.timestamp > self.timestamp):
raise Exception, "trying to save outdated Foo"
super(Foo, self).save()