Has anyone figured out a way to delete a time entry record from a time sheet record, without actually deleting the time sheet? My use case is that I have been syncing work time from JIRA to NetSuite for over a year now. When there is an error or they need to update their time, my integration just deletes it and recreates everything. Never an issue, since the time sheets are not submitted or approved yet, at that point.
Now, we have installed this SuitePeople bundle (sadly, the project managers working on that did not test anything...:/ ), which has completely changed time tracking. Aside from custom fields no longer showing up in the columns (a whole different issue), they are now generating generic timesheets for people to show time off. Those time sheets are not able to be deleted, and their time entries are not able to even be edited (presumably since they were created by the system - at least that's what NetSuite says).
My last hope is to add/edit/delete time entry records when the additional system generated time sheets have been added. But, anytime I try to delete a time entry, I'm given the error that timeentry is not a valid record type (since it is a subrecord).
Any thoughts? Feeling completely at a loss here...
This is good to know since I have a direct integration with JIRA worklogs as well but no SuitePeople.
Can you cancel/reject the timesheet?
Turned out that I had to run this through a RESTlet, where SuiteScript is able to directly search and delete time entry records. Here are the important parts of that script, in case anyone runs into this as well.
var timeEntrySearch=search.create({
type:'timeentry',
columns:[{name:'employee'},{name:'hours'},{name:'internalid'},{name:'memo'}],
filters:[{name:'date',operator:'within',values:[startDate,endDate]},{name:'employee',operator:'is',values:[userID]}]
}).run().each(function(result){
log.debug('results',JSON.stringify(result));
var memoField=result.getValue({name:'memo'});
if(memoField.indexOf('JIRA Time')!=-1){responseArray.push(result);}
return true;
});
for(var el in responseArray){
try{
log.debug('Deleting',JSON.stringify(responseArray[el].id));
record.delete({type:'timeentry',id:responseArray[el].id});
}catch(deleteErr01){
log.debug('ERROR[deleteErr01]',JSON.stringify(deleteErr01));
continue;
}
}
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.
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 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.