Is there a field that exposes WHEN a work item is assigned to its current iteration?
Seems like a pretty basic thing one might like to know, but I can't seem to find it anywhere. Can someone point me in the right direction?
There is No field that exposes when a work item is assigned to its iteration.
If you want to see this value, you can go to the page of the work item.
And then click "History". What you need to find is the record of the latest iteration update.
Of course, you can also get this value through the REST API:
GET https://dev.azure.com/{organization}/{project}/_apis/wit/workItems/{id}/updates
But just like getting it by website, you need to spend some time looking for this value, and you can't apply it to queries.
If you really need a field that exposes when a work item is assigned to its iteration. You can create a new process that inherits from your current process and change the process of your project. Click this document for detailed steps.
And then, add a new field to show the latest updates of iteration. Click this document for detailed steps.
This way you can treat the iteration change time as a real field. However, the defect is that when you make changes to an iteration, you need to manually change the value of this field.
Related
Sorry this isn't a specific coding question, it is more of a design concept.
What is the usage case for programmatically adding and removing fields to Notes Forms e.g. NotesDocument.RemoveItem(), ie why would you add and remove fields in the background?
For many years I have designed my forms with the fields layed out on the form which are required and then hide and show as required.
By adding dynamically you can't position them and frustratingly removing them or deleting they still appear the Database Fields in Domino Designer, getting rid of them is a bit a a black art, but that's another story.
I must be missing a trick or a basic design concept. Any thoughts on best practice would be appreciated.
Many thanks.
Yes, you are missing the difference between "Fields" and "Items". A field is a design element that you can place anywhere on your form. You define how it looks, what content it contains, what datatype it is, etc.
When creating a document with the form the value of the FIELD is stored in an ITEM in the resulting NotesDocument.
This item is totally decoupled from the field that created it. If you were to change the field in the form from text to number or move it around or make a names- field of it, the item in the existing documents would never change unless you open the documents and save them in frontend or use any LotusScript or Formula Code to recalculate the document in backend.
Very often items are added programmatically to documents to fulfill different purposes: Calculate values to be displayed in views, calculate values that are import for the workflow but not for the user, etc.
Complex applications often consist of a lot more items than there are fields in the several forms.
Back to your question: Removing an item from a document simply removes the value that was created by the field in the form. When reopening the document, the item will be repopulated, either by default value or whatever....
Usually you would use this to remove items that you no longer need (and probably already removed from the form).
As soon as you removed all references to a field / item everywhere in design and documents, you can finally get rid of it completely by compacting the database.
An item is distinct from a field in Notes. The form is purely a UI concept, the item is what the data is stored in.
Manipulating data in the backend can be used for a number of reasons. One such use case is the setting of a flag when a date on the form has expired.
Say you want a view showing all documents that have expired. Your rules dictate that documents are considered as "Expired" after 7 days. You could create a view with a formula that shows all document whose date is 7 days older than today:
SELECT Date < #Adjust(#Today; 0; 0; -7; 0; 0; 0);
This view will ALWAYS be out of date and will constantly be updated by the server as it re-evaluates #Today.
Now, a better way would be to create an agent that runs daily that sets an item on the document to indicate that it has expired e.g.
#SetField("Expired"; 1);
The view formula would then be
SELECT Expired = 1
The view would only need to update daily and you have a much faster view because of it.
RemoveItem is used to get rid of data no longer needed e.g. FaxNumber.
There are many use cases for RemoveItem. Here's one that comes up frequently.
You have a database and an agent that processes documents in that database. Every time it runs, the agent replaces the value of a bunch of items. There are a variety of error conditions that can cause it to abort processing a document early, but you're a smart programmer and you've accounted for that with on error traps. When you hit one, you log an error message, save your document, and then either abort your agent or go on to processing the next document.
But at this point, some of the items that the agent normally updates have values saved from this run, and some of them have values saved from a previous run. This might be bad. This might be confusing for someone who is looking at the item values and trying to figure out what's going on. This might even cause validation errors on the form.
So how do you avoid this? At the very beginning of your agent, you call a cleanup sub that finds and removes all the items that the agent is going to update. Now you have a clean slate, and if your agent hits that error condition, it can save whatever it can save without any concern about whether it is leaving things in an inconsistent state. Of course, in cases where you are doing this to avoid validation errors, your validation formulas will have to be smart enough to be checking #IsAvailable for dependent items, but that's a good practice anyhow.
Where does the code that makes a PX Formula work exist? I at first assumed it was a SQL Trigger, but I can't seem to find it there. This is why I ask....
I've added a custom field to the SO, called usrSpeedyTotalExt2. I'm trying to get that to sum the SOLine.CuryLineAmt. I added attributes to the SOLine DAC to append the follwing:
[PXFormula(null, typeof(SumCalc<SOOrderExt.usrSpeedyTotalExt2>))]
This seemed to work, but know I'm fining that the value is consistently twice as high as it should be. I've got a second field that's doing the exact same thing.
What's increasingly odd is that I had the same problem with the field, and I thought I had done something wrong so I deleted the PXFormula, created a new field and then added the PX Formula to populate the new field. As such, there shouldn't be any code populating the old field, but strangely it's populated, so there must b e some business logic that's stuck and somehow still populating it.
Any thoughts on how I track this down?
I believe that I figured out the problem...I think that the code may have been imported and published on more than one company, then published from the proper company to multiple tenants.
My fix was to go to the live company, un-publish all, then go back to the company the customizations live in and publish to the appropriate tenants. It would appear that now I'm only getting the proper totals. IDK how that might have happened, but at least it appears to be fixed.
I'm trying to understand how to design this using Tabris.
My current design updates the tableview by setting a new list:
viewer.setInput(list);
This is not what I want as this refreshes always the entire table with a nasty refresh view behavior.
What I want is just to apply a single change to the table, so remove a tree item, change or insert. Just spend some time to get viewer.insert(...), remove(...) working.
The TreePath required for this call is what confuses me. Tried to create one I'm pretty sure it is not correct.
Does anyone has a good example or any other suggestions to get me in the right direction?
Thanks,
Vincent
I recommend looking at the TreeViewer.replace method. With this method you can change a single item.
I have a SPD workflow that is set to run when an item changes but it keeps getting triggered on new items, which is pretty annoying. I'm looking into why this is happening but I'm also looking for a way to terminate the workflow if the item is new as a temporary workaround.
I tried to compare the Created field to the Modified field i.e. if Created and Modified are the same then don't run. This didn't work, either as a date or string comparison.
Any suggestions would be much appreciated.
Store a flag in a hidden field the first time the workflow is run. Check if the flag is present, if not then it is the first time (created), otherwise it is updated.
I have faced this same issue and I solved with the workaround like this
Take created date and add 1 minute with it and assign it to a variable
Check this variable less than current time.
It done with the following assumption
a. No one try t edit the item within one minute, it created
b. Workflow will execute within one minete
In my case it was success
The comparison between the created time and modified time works on SharePoint 2010 (it is used here). Perhaps the comparison is done incorrectly or the wrong object is used to get the data from?
If said approach does not work on 2007, perhaps it may be possible to use the owshiddenversion field (directly access as property if not correctly exposed). It should be 1 for a newly created item, and > 1 otherwise. It may only be available on versioned lists, I do not recall.
Try adding a condition which compares the create date with the modified date.
i.e.: if current item:created not equals current item:modified
We need to fetch the items added/updated after the user's last visit.
We need this information from 3 separate lists under the same web.
Pointers on how to accomplish this would be very helpful (and does SharePoint provide any API for this).
Kind regards,
Filtering by modified date is straightforward enough, though the method will depend on the type of view - the tricky part is getting the last login time - you're probably going to need a bit of custom code to save that.
Brute force would be to run a foreach on every version until you reach a version before the users last login date, and do this on every list item, and then again on every list. You can see which fields changed this way by seeing what changed between versions. You can narrow down the the set of items to do this on by only querying for ones with a modified date since the users last login
As for finding the users last login, sorry I can suggest anything for that. I've not looked for it before.