Maximo 7.6.1.1:
It would be great if there were a way to make mass updates to a field in a table from within Maximo applications.
For example, in other software such as GIS software, it is possible to open the attribute table of a table, filter the rows, and perform mass updates with a tool called the Field Calculator.
So in Maximo terms, I might:
Open the Assets application --> List view.
Do a filter or advanced query on the assets.
Click an action.
The action would open a dialog that would allow me to select a field name.
I would enter text or a number as a constant. Or use JavaScript to write an expression.
Hit Run.
The filtered rows would be updated.
I'm aware that there is a homegrown method for doing this in Maximo where a user can export to Excel, update the values in Excel, and import the updated Excel sheet back into Maximo. However, that seems unnecessarily clunky to me.
Is there a way to make mass updates to filtered rows from within Maximo applications?
Edit:
An answer can be found here:
Maximo bulk update from List view
Prior to 7.6.1, you would have needed to develop a custom bean class in order to be read the filtered records in the list-view.
In the past, I have developed a generic bean class that called an automation script (referenced in the application's XML), where all of the business logic is implemented (in the script only). Hence, I was able to use this class in many places with different automation scripts.
I have written some articles on LinkedIn about this: https://www.linkedin.com/in/amir-samir-1ba73725/
Now, with the release of 7.6.1, it seems that IBM has added support for the UI in automation scripts, and hence, you don't need the bean class.
More information here:
Access the UI via an automation script (using getWebClientSession)
Note: I believe formulas are of no use in your case.
Perhaps you are referring to this? https://www.ibm.com/support/pages/maximo-application-importexport
I would recommend MxLoader because it is easier to use. Other than what #Dex said to use custom java or Automation Script, I don't see a way to do this from within Maximo.
Asset YTD costs can be updated using BIRT, but I personally using a reporting tool is bad practice. If you want, that's another option (although I warn against it).
Related
We want to "Categorize" our work orders more systematically. So far, we've been using Description, but we feel it is not a reliable way. We were hoping to use Failure Class as a starting point, but we find that having on a different tab discourages technicians and the help desk from classifying the work order.
Is it possible to add/duplicate the Failure Class field to Work Order Tracking screen?
Normally, I wouldn't ask, but was not clear if this was possible because Failure Class, Codes, and Tracking are different tables in Maximo. So, I wasn't sure how this would work exactly...
The simple answer is to use Application Designer's copy / paste functionality to duplicate the field. The specific field in question is on the top level of the Work Order Tracking application and facilitates interaction with the FAILURECODE attribute of the Main Object of the application, which is WORKORDER. Therefore, a copy / paste operation should be all you need. (Note: Application Designer's copy / paste functionality is used via that application's toolbar buttons, not Ctrl+C / Ctrl+V.) And if using Application Designer's copy / paste functionality doesn't work to your satisfaction, I would recommend exporting the XML for the application, copying the line of XML as desired and giving it a unique id, and importing the updated XML back in to Maximo. (Application Designer has toolbar buttons for exporting and importing an application's XML.)
You mentioned difficulty getting users to fill it in as a driver for asking the question. Another solution, which you can do as well as or instead of copying the field, is to specify the Failure Class on each Asset. Then, when an Asset is put on a Work Order, its Failure Class will be copied over, saving the users work and risk of not choosing correctly. And another idea is to highlight the Failure tab until a Failure Class is supplied.
And you also mentioned that the driver behind getting them to fill in the Failure Class, and etc, was to help categorize work. To that point, you should know that Failure Classes, in specific, and Failure Codes, in general, are intended to be used to help you determine what's going wrong with your assets, how often, and how the problems are being fixed. So, using them to categorize work is a bad idea. Instead, you should be using the Work Type field and Classifications, because categorizing work is what these are meant to be used for. The Work Type field is already on the Work Order tab, and Classifications fields are on the Specifications tab. You could copy the Classifications fields the same as I directed above for the Failure Class field.
I've got a tricky situation I'm trying to determine the best way to solve. I'm a VS developer who is learning SharePoint so it's a little frustrating to me when what I am trying to accomplish could easily be done with code and a db.
I have three lists, a parent and two children list that are linked through lookup columns. The client actually wanted everything in one list but due to SharePoint column type limitations I had to split the data into the three lists, there are over 300 fields. The client wants to see all the lists together in one view and be able to filter and edit groups of items.
I have successfully created a new data source linking the lists and can display that on one of my pages to view. After some research however I have learned that I can't create a datasheet view from this linked view due to limitations in the Office componets that SP uses. Which makes sense.
The business need is for the client to filter the three lists based on criteria they select from either list A AND list B and list C to get a group of items, they make the updates and save the changes back to the 3 lists. They prefer to do this in datasheet view because this mimics the excel spreadsheet that they are currently using that this website will replace. They will potentially be updating between 1-30 items at a time using this, which is why they prefer the drag and copy functionality.
I was thinking of two options: trying to create some kind of custom web part that has a gridview of all the columns in edit mode that they can filter down to their items and make their changes. Then I would have to loop through the fields and make updates programmatically. I also saw on this site jQuery.sheet, that looks like it may be a good solution if I go this route instead of gridview.
Or have a modal window with the columns listed, have the user select what they want to filter to, then redirect to a page that shows the three lists in their own DSVs. The user would have to make updates in the three separate views. Then I would use workflows to synchronize the lists after they had made their changes.
I always end up trying to do things programmatically since I am still largely unfamiliar with SP and only seem to hit its limitations instead of its strengths. Has anyone tried to do something similar to this? Or do you have any suggestions as to the best way to accomplish this? Best practices? I appreciate all thoughts and comments! FYI I've also posted this on the MS SP forums as well to cast a wider net...
Thanks,
Sabrina
In this case, you are better off going with a custom solution. A webpart would be an excellent choice for delivering your custom interface.
A dataview webpart will do the job, but if you feel comfortable with the jQuery solution it would make for a nicer interface.
In your code, treat the lists as you would a database and isolate it from the logic and interface code within the webpart.
I noticed that sitecore has the option of exporting users in an Excel format.
I need to have similar functionality for exporting 'participations', (a users can enlist to take part in an 'event', and if their entry is approved via a sitecore workflow, a 'participation' item is created in the content tree)
Since mostly everything in Sitecore is in essence based on items, and I want to export items to Excel, my question is - what are some of the best ways of doing this?
Questions:
Is there a way to re-use this functionality for regular items?
Would it be a good idea to create a custom admin page (any tips on doing this?) which has some custom code that reads the items from the database using the API?
are there sitecore plugins/shared source projects that can help me achieve this?
Or does anyone have a better idea? - would it be better to just store the participations in SQL? I'm mostly doing it this way because I want to make use of the 'free' functionality offers, for example workflow, but if that leads to me using anti-patterns please shoot me ;)
Link is different now: https://marketplace.sitecore.net/en/Modules/Advanced_System_Reporter.aspx
P.S. Couldn't leave a comment to original answer as I don't have enough reputation. Oh well :)
Found a most excellent shared source module which does exactly this (and much more)!
Basically it allows you to configure (and easily extend, if you need to) any kind of table based report on 'items'.
The report module shows up as an application in the sitecore menu (like the user manager tool) and comes with features such as xml,csv, xls export. It's also really easy to set up, once you get the hang of it.
http://trac.sitecore.net/AdvancedSystemReporter
I am trying to split out what I originally wanted in a single form. The downside was that I wanted to keep multiple lists and I found that I could not use a single form with multiple lists.
What I am trying to do is to keep my customer information in a separate list/form so I can re-use it in a different application as well.
What I would like to do is give a picker to pick the customer from a list, and if the customer is not listed to allow the creation of a new one.
What I am wondering is how I can leave the main form, create the new customer, and then return to the main form but with the new customer information passed to the new form as selected. In ASP.NET one of the ways I would do this is through the querystring, but I am not sure if that is doable or preferred in Sharepoint.
Any thoughts or links to tutorials would be great.
Please keep in mind that due to access/security limitations I am trying to do this strictly through the browser and Sharepoint Designer.
Thanks!
With your access limitations, I don't see a solution that will allow the refresh of the original form to get the new data. You may be able to hack in some JQuery stuff to do this, but I just don't see it being an easy/value-for-time thing to do.
You may just have to allow the form user to save the form without customer info and come back to it.
A list view can then highlight forms with no customer info. This all depends on the usage scenario.
You can use the Source query string parameter to get you back to the original form after completing the new customer form. However, unless you add some code (either javascript or server side) you won't get the id of the new customer.
The best option is probably using jquery and the sharepoint web services. It's quite easy if you start with the right scripts, and you can do something like your original plan - make a simple form in a jquery ui popup.
You can also use javascript to manage linking between multiple forms, but you need to be careful about clearing out already entered form data.
Another option would be to edit dispform.aspx and add dataviews for other lists, along with appropriate add buttons, and add javascript to the new customer form that sets the value of a connecting lookup field. However, that tends to require quite a bit of messing about with list guids and other undocumented bits.
Is there a way to extend the SPGridView control in a webpart such that a user can select the columns that they want to display? Kinda like when creating/modifying a view for a list?
Thanks
SPGridView is not sealed so certainly it can be extended with this functionality. You would need to build your own data store of what users have chosen (a SharePoint list should suffice), make the UI modifications, etc.
One thing I've found when trying to extend the provided SharePoint controls is that even though most aren't sealed, often they aren't designed to be extended either. In some cases the members are obfuscated as well which in some cases can put an end to extension plans.
Make sure you research this as much as possible with some quick proof of concepts before devoting to this development. You may find it's necessary to write your own control from scratch (or find another standard ASP.NET control that provides this functionality and hook it up to a SharePoint data source).