There are some PR (purchase requestion's) that are showing hisoryflag='N'
While I'm executing select * from PR where historyflag='N',but I need to change it to 'Y' by force to close all related records to those PR's
Please tell how to force close all the related PR's
Hi Please Provide More Details...
You Want Database query or any Operation UI Level.
By Default in Maximo PR Application out-of box.
History Flag sets 'N' in appBean in "initializeApp()" Method.
In PR application when status change to 'CANCEL'/'CLOSE' the History Flag sets to 'Y'.
.
.
that way cancel/ closed status related PR do not appear in the PR List Tab.
Related
I want to understand Github Checks API so that I can use them to retrieve data. On following Github documentation https://docs.github.com/en/rest/guides/getting-started-with-the-checks-api I am able to derive that check runs are associated with the sha of the change and at each commit on branch check suite is created. Checks API helps in getting all this information. But I want more clarity on three of them in terms of differences. Can anyone please explain these three terms using simple example and terms?
So, first of all, the GitHub Commit Statuses API is separate from the GitHub
Checks API (includes suites & runs), so let's look at them individually first then I'll explain the differences.
Before we get into it, I want to differentiate a PR Check from a Check Run, to avoid confusion. A PR Check describes the current state (trying not to say status here 😉) of a given job or task running in CI or elsewhere on a specific PR commit. These can be created via either a Commit Status or a Check Run. All the items in the pink box below are PR Checks, notice the Hide all checks button.
GitHub statuses - API
I see this as the simple, all-purpose API for reporting PR Checks for a given commit. It's easy and doesn't require jumping through hoops to just display a simple result of a PR Check for a given commit. This API also came before the check API so it's a little less powerful.
Pros
Simple and easy API
Simple relation with context as the identifier.
Can have a fully customizable text description on the PR Checks UI.
You can create statuses as a user with a Personal Access Token (aka PAT) without needing to create a GitHub App, though does work with GitHub Apps too!
Cons
Limited status options, only allow error, failure, pending, success, no conclusion subset option to define completed jobs like Check Runs.
No concept of job timing or duration.
No grouping of statuses, like Check Runs are grouped into Check Suites by their GitHub App
No annotations
No detailed output logs. This is not too important as you could just link to the URL where the actual PR Check was run such as in CircleCI, Jenkins, etc. But the user is not always authorized to view these runs so the output could be helpful for open source repos that have non-public CI.
GitHub Checks - API
The Checks API is the latest and greatest tool for displaying task results on commits, which can essentially do everything the Commit Statuses API can do and more. Check Runs belong to one Check Suite, one Check Suite can have many Check Runs. You can only have one Check suite per commit (i.e. head_sha) per GitHub App, attempting to create another for a given App will just return the previously created Check Suite. Thus, a new Check Run is automatically assigned to the Check Suite based on the authenticated GitHub App, you cannot manually assign Run to Suites.
Contrary to statuses, Check runs are identified by an auto-generated check_run_id and not a context string.
I haven't touched too much on the Check Suites API because they are really just a grouping of Check Runs which is pretty self-explanatory and they don't affect any of the PR Checks UI, only the grouping of Check Runs in the checks tab. One thing to note is that by default you can create a Check Run without having to first create a Check suite and GitHub will just create a new Check Suite for you.
Pros
Greater granularity of status/conclusion for a run.
A lot of power to display the result of a PR Check.
Can provide run context via output summary in Markdown.
Can create annotations for specific lines of code to add information about the analysis performed, like linting error for a given line of code. These will show up in the PR files tab UI similar to PR code comments as well as in the PR Checks tab with any other Check Run output.
Has time awareness to report on durations automatically with little effort.
Cons
A little more complicated API and relationships to manage.
Part of the description in the PR UI is auto-generated based on the status conclusion and duration of the check run task.
Cannot be created via a user PAT, must be created from an authenticated GitHub App. Read access to this API does not require authenticating as a GitHub App.
One edge case you likely won't come across but is good to know: If you are creating a new Check Run with the exact same name of an existing check run under the same authenticated app. The resulting behavior is a little strange but doing this will create the new Check Run under the same name, but will not delete the existing Check Run. However, the Check Suite will not see or link to the existing Check Run, even in the PR UI. BUT!! If you change the name of either such that the runs now have unique names, it will be linked up again. It seems GitHub just does a sort by date and then filters by unique names when looking up Check Runs in a Check Suite. This does not apply with identical names from different authenticated apps.
Comparisons
Below is a mapping of sorts to compare similar options between the Commit Statuses API and the Check Runs API. They are not exactly 1:1 but similar.
Commit Status
Check Run
Option Desciption
sha
head_sha
These are equivalent with the minor exception that the Commit Status is linked to the sha directly, whereas the head_sha is linked to the Check Suite that the Check Run belongs to.
context
name
The context is used as an identifier but both define the title of the PR Check in the PR UI. Because Check Runs are tracked by the check_run_id the name option may change without creating a new Check Run. This is not the case for context, changing the context will always create a new Commit Status. You may not have duplicate names for Check Runs created with the same GitHub App, see note above.
context*
external_id
The external_id is meant for keeping track of Check Runs without having to store ids or always keep the name constant. This is only somewhat similar to the context option but only for the purpose of identifying the Check Run.
description
output.title
The main difference here is that description gives you the full space to work with, where output.title will be displayed after the auto-generated status string.
target_url
details_url
These are somewhat equivalent, the first difference is that target_url will not show unless defined whereas details_url will default to the check run URL in the PR UI. The other difference is the Check Runs Details button on the PR Checks UI will always link the the Checks page which will present a link to the details_url if defined.
state
status
These are very similar but have slightly different allowed values but effectively appear the same in the PR UI.
N/A
conclusion
This just shows the increased power of the PR Checks API where you have more granular control over the PR Check status, though not a big difference in the UI, see example variations below.
N/A
started_at
No comparable option for Commit Statuses.
N/A
completed_at
No comparable option for Commit Statuses.
N/A
actions
No comparable option for Commit Statuses.
N/A
output
No comparable option for Commit Statuses.
N/A
output.annotations
No comparable option for Commit Statuses.
* Only somewhat similar, not a direct equivalent.
PR Checks UI Component mappings
I've taken a simple PR Check and highlighted the differences between the elements of the UI between the Commit Status API and the Check Runs API. Very similar but slight differences.
Below are example variations to relate the options to their impact on the
PR Checks UI.
Commit status variations
Check Run variations
If a check run is in an incomplete state for more than 14 days, then the Check Run's conclusion becomes stale. Only GitHub can mark Check Runs as stale.
Checks Tab in PR UI
The Checks Tab in the PR UI will display all created Check Suites and their child Check Runs and allows you to set the output option to control the content of this page. This page would also show images and annotations if you defined those too.
One final note: You cannot DELETE any Commit Status, Check Run or Check Suite once created, only updating is allowed. With these statuses being so ephemeral this is not that big of a deal but in case you were wondering.
Update (6/21/2022)
I found two more quirks to explain. First, the details_url for Check Runs does not set the value of the Details button, instead the Details button actually always redirects to the Checks page which has a link to the details_url if defined.
Second, once a Check Run status is set to 'completed', there is not way to un-complete the Check run. But you can get around this by creating a new Check Run with the same name and set that status to something other than 'completed'. See this edge case with duplicate-named Check Runs explained above in detail.
Update (6/29/2022)
As mentioned above, the Check Runs API keeps track of the duration of the run. It is important to note that the started_at time is set only once whenever a check run is created, regardless of the defined status. For example, if I trigger a CI build and set all jobs status to queued, the jobs run duration will be inaccurate. A good way to fix this is to always set the started_at time whenever you set the status to in_progress. Something as simple as const started_at = new Date().toISOString() (javascript) will do the trick.
I want to get details about deleted records from inline-editing. Taken logs of all the fields for the same. An aftersubmit user-event script works for this where,
if(context.type == context.UserEventType.DELETE) the context type is delete.
When I go to that record, click edit and then in the Actions menu click delete, then logs are printed. But this thing is not happening when deleted from inline-editing mode.
Do I have to do this in XEDIT mode? Is there any other solution? please suggest.
No need to use XEDIT , Use DELETE and Try with User Event before submit , as after submit will error out to record not found
I am using J Developer 12 c. I want to create form but without any data fetched in.I want user to enter detail in form for submission.I have tried all online solution but they are for J Developer 11.I am not able to fetch an empty form.
When I run my form it automatically fetch record from the table.I have tried use create insert but i want form to be automatically fetched with new record every time page is run.
Add a CreateInsert action in your task flow on the way into you page. This will clear the fields for data entry. Look here.
You need to understand the difference between commit and submit. You want to submit the pages - clicking a submit button - and then the page is processed and the EO/VOs are updated in memory.
The Commit operation writes the in-memory changes to the datasource (database). So, you can submit pages 1-3 then using the same data control the fields will be populated with the entered data on page 4. Now the user can commit the changes. The Commit action is located in the operations for the AppModule-DataControl.
This is the power of the ADF Data Control. Changes to fields are cached in memory and are available to any page and then those changes can be committed when you choose. Note, the Task Flow can control the transaction itself.
Sounds like you need to learn the basics of ADF. I suggest this book and this set of resources I maintain for my students and these.
And, if you will be doing a lot of ADF development, it is well worth your time to take our ADF course.
(It also seems you are unaware of how stack overflow works. When you get an response that answers you question, you up-vote the answer, so it encourages those of us taking our time to answer you question for free to continue doing so. Please note that I answered your original question and Shay reinforced that answer.
And I have now answered your second question, and provided links to resources to help you go further.
I already marked the correct answer however my second question where i was unable to commit on review page which fetch data from 3 vo i got solution thanks to http://www.baigzeeshan.com/2010/11/avoiding-jbo-26048-during-commit-in.html.Actually the first Eo is master for rest 2 Eo so it would ideally allow me to commit detail data only after i commit the master.Now i found the blog and it suggested me to do changes in association and add behaviour for composite association and cascade update for key attribute.Now i can directly commit on my last review page and navigate through task flow easily without using commit on eac individual page.thanks all who helped me.
I am trying to update an existing activity stream entry e.g. the title of the entry.
Here I found the code for the creation of the new entry:
Link
But I could not find any reference how do I update an existing entry?
Additional information:
I use IBM Connections 4.5 and the IBM SBT
I create the entries with a system user to other users with the flag
'actionable'
Here my questions:
Which URL?
Which Method (PUT?)?
Which Json?
And another question about the actionable flag:
How can I change the actionable flag for an entry of another user? The description for my own entries is described on slide 37 here: Link
Thank you so much !
Markus
Ok, I think I fully understand the issue now. As suggested this is not supported, but there is a way you can achieve the same result.
First of all why isn't it supported . . .
Events are a point in time (and they were accurate at that point in time)
A new event on the same object supersedes it (as it's now the most interesting) but
doesn't invalidate it (it can still be seen in history)
The Actionable view does not show a rolled up view, instead it shows all events that are marked actionable (and there may be multiple actions related to any given Object)
What you can do . . .
If you want to replace an entry in the Actionable view, you can remove the event from the actionable view (it is just removed from that view and could still be seen in event history)
You can then add another event to the actionable view (which as the latest event will also supersede events in other rolled up views)
Removing the actionable flag is here ->http://www-10.lotus.com/ldd/appdevwiki.nsf/xpDocViewer.xsp?lookupName=IBM+Connections+4.5+API+Documentation#action=openDocument&res_title=Support_for_Saved_and_Actionable_events&content=pdcontent
an activity stream object is treated an an immutable object in IBM Connections.
you can Create Delete and Read.
You can use a rollup-id in IBM Connections.
In order to address the scenario where a user posts a file and 200 people 'like' it, filling up their Activity Stream, rollup needs to be performed. This means:
Only the latest event on any given object is shown
The 2 most recent comments are returned.
http://www-10.lotus.com/ldd/appdevwiki.nsf/xpAPIViewer.xsp?lookupName=IBM+Connections+4.0+API+Documentation#action=openDocument&res_title=Support_for_Rollup&content=apicontent
Just to extend the last answer, delete is not directly supported in the Activity Stream in IBM Connections, though a means of propagating delete based on deletion of an Object was introduced in IBM Connections 4.5.
However it does seem like submitting a new event with an appropriate rollup id is what you're looking for. That way users will see the latest, but the history remains and can be seen if desired.
I build a plugin that runs in account update message that makes some validation not to duplicate the record. But if I try to disable that account or merge with another one it triggers the plugin.
How can I tell if the plugin was triggered by an activate/deactivate/merge action, or event mode like the one in CRM Dynamics 2011 Save Event Arguments Reference?
To add to Pete Oakey's answer, you can actually tell your plugin to fire only when certain fields are changed at the registration phase, in addition to testing this in actual code # runtime, by changing the "Filtering Attributes" of the plugin step. So unless your validation logic specifically needs the StateCode/StatusCode attributes to correctly process, you can filter those two attributes out, or just include the attributes your validation logic needs.
Original answer:
I believe you can reference the IExecutionContext.Depth Property of the IPluginExecutionContext object.
Every time a running plug-in or Workflow issues a message request to
the Web services that triggers another plug-in or Workflow to execute,
the Depth property of the execution context is increased. If the depth
property increments to its maximum value within the configured time
limit, the platform considers this behavior an infinite loop and
further plug-in or Workflow execution is aborted. The maximum depth
(8) and time limit (one hour) are configurable by the Microsoft
Dynamics CRM administrator.
So you can use an if statement to check if Depth > 1.
One way would be to compare the before and after values of what's changed on the account entity in the plugin. For example if you have only have active (if that's the right property name) in the values - you can look at the after value to see what's happened.
Another way would be to add a specific plugin for these messages and set some property/flag which you can check in the update plugin. Obviously this would have to run before the update plugin.