Online collaboration on TFS - azure

is it possible to collaborate online with TFS? I mean, when I move a task, others can see it in real time without sharing screen or updating the page. Thank you!

Azure DevOps Server 2020 Update 1 RC1 and higher has live updates on work items. If you change a work item someone else has open in view mode, it will update in their client.
Alternatively
You can enable notifications using ../DefaultCollection/_usersSettings/notifications
You can use the Follow icon to follow a work item. Any changes will result in an e-mail to you saying the item has changed, and what has changed.
If you move a story out of an iteration, the Taskboard (../_sprints/taskboard/..) view updates automatically for all users viewing that iteration
Similarly, if you add/edit/move/change state on a task in an iteration the Taskboard will update.

Related

Azure devops 2019.1 - Activity logs

I look for a way to collect and save activity and security logs from the Azure devops server(onprem 2019.1).
Logs include - user logins, build events, work item events, security changes etc.
I'm aware about this option https://server_name/tfs/_oi/_diagnostics/activityLog. But it's not an api interface.
Any Idea how it's can be implemented that?
Thanks.
TFS keeps track of an activity log of all recent activities. This information is stored in 2 tables inside Tfs_Configuration and Tfs_collectionname called tbl_Command and tbl_Parameter. These tables keep a record of every single command that every single user has executed against TFS for the last 14 days.
If you don’t want to get activity log through tbl_Command table and hidden activity log page (http://server:port/tfs/_oi), I’m afraid there is no other way at present.
You could add your request for this feature on our UserVoice site, which is our main forum for product suggestions. After suggest raised, you can vote and add your comments for this feedback. The product team would provide the updates if they view it.

transfer to another location retention not working sharepoint 2013

I have a configured a retention policy on a document library, the document should be moved to another location (Drop Off library) after certain amount of time. This doesnt seem to be working.
Please note that I have configured the Content organizer feature and "Send To" connections in Central Admin. I also have changed the trigger time for Information Policy and expiration policy job to run every 2 mins and 5 mins respectively.
Am i missing anything, because the functionality is not working and there is no error being thrown. All i can see is that the retention action is displayed as completed in "Compliance details" tab after sometime, but documents havent moved to drop off library. Also other retention action such as move to recycle bin work perfectly fine.
Please help.
Thanks in advance
If Move to recycle bin is working but Transfer isn't, I'm assuming your destination site is the same as the source. If so, this is not going to work because according to Microsoft support
It was as per design. If you try to move documents to a different location using Retention policy, you have to move it a library in a different site collection. Preferably ‘Records center‘ site collection. Main idea of Microsoft is to have one Archival or Records center site collection for the whole organization.
So, if you are trying to move documents after expiration to a library in same site or site collection, you can use a workaround to start a workflow on expiration date which moves the document to archival library.
Hope this helps. Source
To start with for investigation
1.There are two timer job services in Sharepoint 2010 ( it looks the same on 2013 as well) so ... "Information management policy" and "Expiration policy". check if these Job are working as desired for the web application. I understand it works partially on some instances. But I don't know if it is on the same webapp level.
Next can you check if these documents are checked-out to some one on the team or to a person who has left the firm which is very common sometime User Profile service may give you tickle by not syncing as desired.
If you have custom content type for which the the document is saved. then if the same content type exist on the destination folder ( drop off lib) where document to be moved.
I had a situation when the documents where located inside a folder (leaf) inside document library. Move of document expected a same folder on destination which was weird. But after changing folder name which had '(' symbol it worked.
I have also seen some instances of permissions to the folder for the timer job but, I did not have that experience.
Without actual settings on the retention policy I can only give only pointers. Therefore, please give bit more information about the retention policy setup if it is not confidential.
I have similar problem, and after lots of try and error I found up that I have a required column in the destination content type which wasn't required in the source content type. Just check it!

Sharepoint Calendar: Block a Day Off

Does anyone know of a way to prevent access to, or highlight, a specific day in a Sharepoint calendar? The intent is to show which day(s) are not available for a given task.
I have already fashioned a Workflow that would email a user, but it needs to be visual as well - people need to see at a glance what days are avaiable.
Any have any ideas? I'm running on SBS 2008 with WSS 3.0 .. I also have Sharepoint Designer 2007 installed, if it can be leveraged.
Personally, I would do this by creating a new event receiver to run on the calendar. This event receiver should run on new / updates, and should configure item level permissions for any event on that specific day. If you break the item's permission inheritance, and remove read access to all items on that day, no one would be able to see the task.
Obviously, always be very careful when working with item level permissions.

Sharepoint Workflow doesn't trigger after created/edited tickets

I have a workflow created in Sharepoint designer that works fine when manually triggered. I want it to trigger when a new ticket is created and when an existing ticket is edited. I have tried everything, but it makes no sense that it works when manually triggered, but does not appear to trigger when tickets are created/modified. Any help would be appreciated.
While creating a work flow (first screen) you can see three check boxes
Allow this workflow to be manually started from an item.
Automatically start this workflow when a new item is created.
Automatically start this workflow when ever an item is changed.
You might have choosen the first option only. So that you need to start it manually. You have to opt the three options
also what do you mean "I have tried everything".

Sharepoint Workflow Fails When First Run But Succeeds When Run Manually

We are using an infopath form that when submitted is supposed to fire off a custom .NET workflow. Basically, the information within the form is used to create a new sharepoint site. What I am seeing happen is that the first time the workflow runs (which is automatic after the form is submitted), the workflow errors out. When I run the workflow manually immediately after it fails, the workflow runs fine.
this.workflowProperties.Item["Client Name"]
I've debugged the issue down to the above line where workflowProperties is of type Microsoft.SharePoint.Workflow.SPWorkflowActivationProperties. The first time the workflow runs, the property listed above (and all others) are null. The second time it is run the client name property is as it should be (populated from the infopath form).
Another important piece of information is that this workflow was working fine for over a year and suddenly started not working correctly a few weeks ago for no particular reason. We were having some permissions issues the past month but I cannot see how that could be related to the workflow issue. The user I am logged in as is a site collection administrator. I use the same user to kick the workflow off manually (which succeeds). I do not think that the workflow runs as the user that is logged in though (when it is run automatically on form submission).
Another interesting wrinkle to the whole situation: there are a total of 3 custom workflows that the application uses. 2 were made in visual studio - one of these works fine and other is displaying the behavior described above. The last was made in sharepoint designer and is failing.
I'm willing to try just about anything at this point. I am on a dev server (which displays the exact symptoms as production) so I can try just about anything.
I'm guessing this has to do with the workflow being fired asynchronously from the commit operation that sets the fields values. Can you try and fetch the item explictly from the list instead of using the Item from the workflow properties. something like the following:
SPListItem l_item =
workflowProperties.Item.List.Items.GetItemById(
workflowProperties.Item.Id
);
i'm not certain, but it may be worth a try.
The other thing to keep in mind is the SPContext.Current object will be null if being called from an EventReceiver, but will be valid if called manually. It doesn't sound like this is the issue, but its something to be aware of nonetheless.
If the InfoPath forms are submitted from a Vista or Win 7 machine, you might face this issue of getting a NULL value for the fields in the InfoPath form. Try adding a delay activity with around 10seconds and see if your are able to get the value of the fields from InfoPath.
Refer to this link for more details: Why does my SharePoint workflow fail when the client is running Vista or Windows 7?
Try looking in your SharePoint Logs.
They are located under the 12-Hive in the LOGS folder - open up the latest and look for something with 'Workflow infrastructure' in it, maybe that can point you in the right direction.
The "solution" was to do an export and transfer to a new server. Basically just use STSADM to do the export operation and then import the same file on the new server.
SEE:
http://sharepointdogs.wordpress.com/2008/07/30/content-migration-or-backuprestore-in-moss-2007/
I was on the phone with Microsoft Support for hours on this issue - transferring to a new server would be my recommendation for anyone else that might encounter this problem.

Resources