Maximo inbox/assignments linking - maximo

I'm working on an existing workflow for work orders and there are two different applications that are receiving the information somehow: ICOM SR Work Order Tracking and ICOM Work Orders.
Since I'm not the one who developed these applications I'm not sure what is the reason/difference between the two.
My issue is that when an assignment arrives at a user's inbox and they click the description it takes them to the ICOM SR Work Order Tracking while I want it to take them to the ICOM Work Orders application instead. Where do I specify where the assignments link to?

You need to open the workflow process which creates those assignments in Workflow Designer application, create new process revision, open Properties of the desired Task Node and pick the ICOM Work Orders application from "Application" lookup instead of ICOM SR Work Order Tracking (which should be there now) at the place I marked on screenshot (not the one in the header). Then deactivate older revision and activate your new revision of the process.
That should do the job, hope this helps :-)

Related

Online collaboration on TFS

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.

Restrict what customers an employee can see (NetSuite)

I'm customizing some NetSuite objects (forms, etc) including the Employee Centre's Time Tracking form. We want the people recording time (external contractors) to be able to enter time only against the projects and project tasks they have been explicitly assigned to.
So far it's going well, the only major problem is how to restrict what Customers they can see.
Currently the Customer field is where the system expects them to enter the name of the project, however that field will try to be "helpful" by listing/searching across the names of our customers as well. I'm using a customized version of the OOTB Time Tracking form.
How can I restrict the system so that the user can only see the projects they have been assigned? Or in other words, not see the entire customer base.
It's ok if they can also see the customer to whom the project belongs, and I'm open to solutions that are based on user access in the back-end (member for a group/role whatever, or, changing the way the Customer field works on the custom Time Tracking form.

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