I have a checkbox that on toggle sets a filter, noticed it was creating duplicates with the same name. So, I tried different combinations of these examples but every every hit they cause the table to refresh. Is there a way to let the filter work happen then let the ajaxFiltering kick in after it's complete for a single hit to the API?
table.clearFilter();
table.removeFilter("showSomething", "=", !this.checked);
table.addFilter("showSomething", "=", this.checked);
The answer is to use setFilter table.setFilter("showclosed", "=", this.checked);, for some reason it was just not clear in the documentation that it was available. Went from Adding to Removing but nothing about editing an existing. Once you dig a bit deeper you see examples being used and can put 2-2 together.
Related
I have created a bunch of short flows that act on a single SharePoint list item to reduce complexity, but I've run into a problem with the order in which they execute. I think I could best explain this with an example, so please see below:
Let's say there are three flows, SetTitle, SetPermissions, and SendEmail (sends an email based on the new value after a column changes). Ideally, SetPermissions would run first, then SendEmail, and finally SetTitle since it modifies the item. That modification is a problem because it adds a version to Version History, which I am checking in the SendEmail flow to see if the value of a column changed.
Currently, however, SetTitle sometimes runs first, which breaks SendEmail because now the most recently displaced version does not contain a record of the column change that happened two versions ago.
I would like to avoid creating additional columns in the item to track column changes or emails sent, because we're creating these flows to avoid that messy complexity.
I'm hoping that there is some hidden execution order option somewhere, because as I said, I don't really want to create extra columns or trigger flows based on HTTP calls. Of course, what I'm doing now isn't working, so I understand that I may have to compromise.
I do not think what you are looking for is possible tbh.
I know you said you do not want to create more columns, but the only solution that I can think of requires only 1 extra column to be created. Use that to run the flows in the right order.
For example, if there are two flows: f1 and f2, set the default value of the new column(let's call it 'stage') to 0. Then, add a condition to f1 so it only runs when the stage is 0 and also updates the column to 1. Then f2 also has an initial condition check and runs only when 'Stage' is '1' and also sets 'Stage' to '2'.
Hope this helps.
In maximo, can we delete a work order? The select action menu gives me
BMXAA4612E - Cannot delete because it is, or had at one time been approved.
I have created numerous test work orders and it is getting difficult to track new work orders.
Short Answer: You can't.
Standard Maximo will not let you delete it past a certain point. It keeps this data around for a sort of auditing (and because there could be a lot of dependencies to undo).
Bad Answer: With some database queries. You can of course delete about anything if you start modifying Maximo's underlying database directly. The Work Order object has a number of related tables though, so make sure you delete all referenced data from those as well. And there might be other places you need to update too, like a PM due date, depending on the situation.
In a normal Maximo environment, it is very common to have a lot of open work orders at any given time. You are going to need to develop ways to handle the fluff. Closing your old test work orders helps, because Maximo filters out closed work orders by default. Standard filters with some specialized data and saved queries are some other options.
Clear attribute: FIRSTAPPRSTATUS
update woactivity set FIRSTAPPRSTATUS = null
where ;
Then deleting should be possible
--> However it is not (in maximo 7.6)
For Maximo 7.6, change the workorder status to WAPPR from the backend or through MIF and then use MIF to delete the record(s)
I created an action that executes set FIRSAPPRSTATUS null and created an escalation with the condition of selecting a work order. After the escalation is completed, deletion will be available if the remaining conditions for deleting the work order are met.
I've set up an ExtLib REST service as "xe:viewJsonService" and connected it to a domino view. Currently the view contains 63 entries. The documents behind those entries have read access restrictions.
The Json returned by the service is consumed by a Dojo Data Grid (taken from the ExtLib libraries).
The page is accessed by a test user having read access to only one of the 64 entries. This user however sees a data grid containing a single data element, followed by 63 empty entries, like this:
Looking at the raw Json data I see that the service indeed is only returning a single entry, but it knows that there are 63 siblings:
[
{
"#entryid":"1-6C5763E4A122F1D3C1257EC700355386",
"#unid":"6C5763E4A122F1D3C1257EC700355386",
"#noteid":"3FD2E",
"#position":"1",
"#read":true,
"#siblings":63,
"#form":"fInvoice",
"colIconStatus":"imgInvExported.gif",
"colIconLock":"blank.gif",
"invInvoiceDate":"2015-09-21T09:44:27Z",
"invJobInvNumbers":"111\/5152\/52567\/ 001",
"invSupplierNameShort":"My Test Company GmbH",
"invAmount":121.5
}
]
Technically speaking this is correct as the service has access to all 64 entries. Problem is that the data grid is making space for 64 entries instead of only one.
Question is: how can I tell the data grid the correct amount of data to be displayed? Or do I need to manipulate the REST service instead?
EDIT: continuing my search for a possible solution in meanwhile found a few other related questions this one by Eric McCormick (including a very good approach by Stephan Wissel), or this one by Steve Zavocki. So my question would be a duplicate, really... (sorry for that)
Caveat: please read down to the bottom of this answer as you might run into unexpected ussues!
Finally after some playing around I just stumbled upon an obscure property that seems to help, for whatever reason (I'll be making this a new question):
the property globalValues appears to be available for service types xe:documentJsonService, xe:viewItemFileService, xe:viewJsonLegacyService, xe:viewJsonService and xe:viewXmlLegacyService. this property has three fixed options called Entries (= 0x0001), Top Level (= 0x0002) and Timestamp (= 0x0004). Just by playing the goold old "trial-and-error" game I found that setting this property to 1 (= Entries) modifies / filters the resulting data:
by default the raw JSON returned by xe:viewItemFileService looks like this:
{
"#timestamp":"2015-10-14T12:57:59Z",
"#toplevelentries":63,
"items":
[
{
...
}
]
}
Setting globalValues to "1" removes the #timestamp and #toplevelentries fields from the output:
{
"items":
[
{
...
}
]
}
And, more importantly, this also removes the empty rows from my data grid!
There's only one thing that's making me nervous and that is that I can't find any explanation at all in regards to that property. So I really don't have a clue whether there are any unwanted side effects...
Update: thanks to Knut Herrmann I did some more testing on this (see comments below this answer). In my test case there are over 13,000 documents in my view; as long as my test user can only read a small amount of those everything seems to be fine. Then I added 200 more documents to the read-enabled list. Result is a data-grid that constantly has to recalculate its scroll bar: the further down I'm scrolling the smaller the scroll handle gets. As soon as I reach the bottom line however the grid goes berzerk and decides to only display the first 13 (?!?) rows, and also the scroll bar is removed alltogether. Performance isn't as bad as I expected, though.
So I have to agree with Knut that this isn't such a good solution for the combination of large views with a large subset of accessible entries!
Lothar,
I have experienced this before as you pointed out. I believe the answer is to use the 'keys' property to filter out the invalid entries.
I am not sure about how your application is structured, but if the user can only see certain entries in the view, I would consider categorizing by user, and then use the keys to show them only the rows in which they have access.
You asked if you can change the dojo grid to exclude the entries. I think the answer there is no. Your options are to filter via the REST service or via the Notes view.
Here is a related blog post that I wrote on the issues I was having. http://notesspeak.blogspot.com/2013/07/creating-updatable-rest-service-for-use.html
EDIT 2 Additional Things to Try
1) Did you see the comment on my blog post? I haven't tried it myself. Credit goes to blog comment-er "Goo Goo".
"I use this code in onstyleRow event of the grid to solve the blank rows issue "
which using viewJsonService:
var row = arguments[0];
var rowItem = djxDataGrid1.getItem(row.index);
var rowCount = Object.keys(restService1._index).length - 1; //-1 for omit the onUpdate event
if(row.index >= rowCount){
row.customStyles += 'display:none;';
}
2) What I personally did to fix the issue is in this SO answer: How to configure an xe:viewFileItemService on an XPage to filter the data in a categorized view?
Given what you said about your view structure, I am not sure that this will apply to you.
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'm not a Notes programmer, however, for my sins, have been working on some Notes features for an in-house project recently. I need to enable/disable editing of a field depending on circumstances. It seems to me to be a fairly standard feature, I need, but I can't find any information on how to do this anywhere.
In form setup (and other field's onchange) code, something like the following:
if some requirement = true then
textField.enable = true
else
textField.enable = false
end if
I've seen other places where there's a workaround of conditionally hiding paragraphs based on some code, having 2 paragraphs with opposite hiding conditions, one with an editable field, the other with a computed field. However, I don't know enough about Notes to see how this is implemented (I can see it done on other forms, but there seem to be some 'magic' steps within Notes which I either can't see or don't get).
[EDIT]
The reply from Kerr seems to be what I'm looking for, but I still can't find out where the InputEnabled property is located. Should have said in the initial question, I'm using Notes 7.0.3.
In fairness, it doesn't matter what the circumstances are for when to enable/disable the field, it's just some boolean condition that is set, in my case only on form loading so I don't even have to worry about this changing dynamically while the form is displayed.
I've got a few issues with Notes, my largest bugbear being that it's so tied so tightly to the Designer UI, which is utter shite. I can do this sort of thing programmatically in most GUI languages (C#, Java, Delphi, even VB), but I need to open property boxes in Notes and set them correctly.
This would be OK as an optional method, but forcing you to go this way means you can only work as well as the IDE lets you in this case, and the IDE here seems to actively work against you. You can't open multiple functions/scripts, you can't swap from one script to another without going back to the menus on the left, you can't easily search the codebase for occurrences of variables/fields (and believe me, this is a major failing for me because either Notes or the internal codebase in my case seems to make a lot of use of global variables!), you can only work with fields through the property boxes that get displayed, you can't edit code in Designer while debugging through the main Notes client.
While the Java side of the coding is better than LotusScript, it's still fairly crappy (why can't you debug INTO Java code?? Why do you need to re-import JAR files for each Java class, does each class have a different CLASSPATH???). Possibly this was improved in Notes 8, I hear it's based on Eclipse. Does anyone know whether this is true or not?
It would help to hear more specifics about the 'circumstances', but the most common way to handle this is to use a hide when formula on the field you want to enable/disable.
Technically you are not enabling or disabling the field, just hiding it, but usually that works just as well.
Since there are few events to work with in Notes, developers commonly use the document refresh as the 'event' to cause the field to hide or show.
Let's assume you have two fields called TriggerField and Subject. Say also you want to disable the Subject based on a value in the TriggerField. The easiest way to do so is to set the TriggerField as a Dialog List type and check the "Refresh fields on keyword change" option. This means when the value of the dialog list changes, the entire document will get refreshed.
Then in your hide when formula for the Subject field, you specify your criteria for when to show or hide that field. Anytime field values change, followed by a refresh of the document (i.e. form), that hide when formula will be re-evaluated.
There are other ways, depending on your circumstances, to solve this problem. If you want to let the user refresh the form themselves, put a button on the form that calls the #Command([ViewRefreshFields]) command. You can add any other formulas to that button before the refresh command if you want to make other changes to the form at the same time.
Another option is to make a certain field display-only. Then create a button that runs LotusScript to allow users to change that display-only field. In the script you can propmt the user for a value, set the display-only field, and then call for a document refresh.
In ND7 and up if you want to just disable the field for input, write an appropriate formula in the InputEnabled section of the field you want to disable.
So I have two fields one called Trigger, a checkbox with the value "On" and another Subject that is a text field. When Trigger is checked I want the value Subject to be enabled.
I simply put the following formula in the Input Enabled element of the field Subject:
Trigger = "On"
I also want this to be recalculated whenever the value of Trigger changes so I select the "Refresh fields on keyword change" option on the Trigger field.
If you're stuck in an older version you need to to hide paragraphs appropriately.