I just started to work with org-mode and I really like it. I've come across this question how to archive the done task in a more automated way. My question is now: Once the done tasks are move to another archive-file do they still contribute to the % completed? Is there a way to make them still contributing to the overall status? Otherwise, as there won't be any done task the completion status will always be 0.
Related
We have a service hook created for one of our projects in ADO. It was going fine until last weekend. Suddenly few webhooks started queued and I am not sure how to force it to get processed. Can someone help me if there is a way to force those items to get processed.
Thanks,
Venu
I am afraid that you cannot get that you want during process.
Under the process, the queued service hooks will not be picked again and will not be processed again.
When the main thread, such as a work item, is running, you cannot forcefully intervene or exit the content that is already queued.
And there is a similar issue also discussing about this situation.
And waiting service hooks are actually coupled, which also depends on your memory, because they actually run in memory. If there are occasional memory loss and other problems during execution, this cannot ensure that all service hooks can be executed as expected.
Or you should interrupt the current process and reduce the service hooks for it. But it is not a good solution.
So it is the best way to add a function that can handle the queued service hooks in the process. But currently there is no such function. Therefore we recommend you submit the suggestion ticket to the Team to suggest them add that feature.
I use Alfresco Community 5.2 and my need is to perform some work when one of the default Alfresco's workflow is started.
I could override all the workflows definitions, but I wonder if there is a better and quicker way to do that. The perfect would be a behavior which triggers when a workflow is started.
Is there something like that ?
Any other approach is accepted. Thanks.
There isn't anything similar to a behavior for workflows that I know of, although if your workflows will always have documents attached you could consider binding a behavior to the workflow package type (I don't recall off-hand what that type is--it might just be cm:folder which wouldn't be that useful).
This is kind of a hack suggestion, but you could implement a quartz job that would run every 30 seconds or every minute or so that would use the workflow service to check to see if any new workflows have started since the last check. If so, your code could be notified and passed the workflow ID, process ID, etc.
The straightforward solution is as you suggested in your original post--just modify the out-of-the-box processes with a task listener that fires when the workflow starts.
Following Jeff suggestion, and this tutorial, I managed to implement a task creation/completion listener and do my logic inside those blocks, resolving the problem.
I have a question regarding workflow in Kanban. Can I have two activities in my name in the "in progress" column? For example, I started the activity 'A' but not concluded and will continue at another time, then I get the activity 'B.' Makes sense to have activities A and B in the "in progress," but I'm doing only one.
I am a certified Kanban Coaching Professional, and this would be my advice:
Sure you can. Kanban itself won't say whether you can or not, it depends on how you use Kanban. The WIP limits might prevent you from starting another task, in which case you should do some or any of the following:
Discuss the issue with the team, perhaps it is ok to raise the WIP limit (or even temporarily breach it)? Perhaps you can solve the impediments together and continue working on the original task.
Perhaps you can "swarm" or help someone else with something else on the board. I usually like to start from the right-hand-side of the board and see if I can help some other item move closer to done.
You can also treat this as "slack" time, and work on improving the process, learning a new skill, or checking emails, or some of the other tasks that everyone has to do that are not directly related to the value stream. "Preparing for working on the item" is what a lot of people consider doing, but is usually just cheating against the WIP limits.
I have to move an SAP background job (ABAP report for A/P) into Cronacle and can't figure out how to stop the job in SAP so I can start running it with the Cronacle schedule.
The job runs in SAP from user SAPSYS every morning at 7:15am, but if you look it up with sm37 there is no time scheduled for it and it's not triggered by an event; also, it's status is SCHEDULED.
I had our Cronacle team search by job number but they couldn't find any scripts pointing to that job. If you look at the finished job it shows that it's scheduled daily for 7:15am. Also, there is no predecessor or successor jobs listed. Is it possible it's being started from another job? How do I find out without deleting this one?
Some suggestion.
If you don't want to delete the scheduled job. try to rename it, and see if it still runs.
Make sure that the users you are using for sm37 has full authorization for the backround administration.
A previous job can schedule and release and create and whatever a new job. Look at what is running before the problematic job.
Look deeply at the dev traces. They somtimes hints about what is going on in the system.
In addtion to a previous job creating the new job explicitly it is also possible that the job is created manually by an ABAP program that is scheduled in another job. Doing a where-used on the function module OPEN_JOB and looking for Z* or Y* programs may give you a hint.
Another thing: Is this scheduled job ever actually excecuted (i.e. are there any previous "FINISHED" jobs with the same name). A Scheduled job will not run unless it is first released. So if it never runs it may be obsolete.
Thanks for the responses! It turned out to be a case of "newbie ignorance." When using SM37 to view the job I neglected to extend the search date to the next day. I don't know why it doesn't show the released job for the current day, but extending it to the next day showed it. That's a lesson I won't forget!
In my current environment, we have a "clean" build machine, which has an exact copy of all committed changes, nothing more, nothing less.
And of course I have my own machine, with dozens of files in an "in-progress" state.
Often I need to build my application with only one change in place. For example, I've finished task ABC, and I want to build an EXE with only that change.
But of course I can't commit the change to the repository until it's tested.
Branching seems like overkill for this. What do you do in your environment to isolate changes for test builds and releases?
#Matt b: So while you wait for feedback on your change, what do you do? Are you always working on exactly one thing?
So you are asking how to handle working on multiple "tasks" at once, right? Except branching.
You can have multiple checkouts of the source on the local machine, suffixing the directory name with the name of the ticket you are working on. Just make sure to make changes in the right directory, depending on the task...
Mixing multiple tasks in one working copy / commit can get very confusing, especially if somebody needs to review your work later.
I prefer to make and test builds on my local machine/environment before committing or promoting any changes.
For your specific example, I would have checked out a clean copy of the source before starting task ABC, and after implementing ABC, created a build locally with that in it.
Something like that: git stash && ./bootstrap.sh && make tests :)
I try hard to make each "commit" operation represent a single, cohesive change. Sometimes it's a whole bug fix or whole feature, and sometimes it's a single small refactoring on the way to something bigger. There's no simple way to decide what a unit is here, just by gut feel. I also ask (beg!) my teammates to do the same.
When this is done well, you get a number of benefits:
You can write a high quality, detailed description for the change.
Reading the first line of the description of each change gives you a sense of the flow of the code.
The diffs of a change are easy to read & understand.
If a change introduces a bug / build break / other problem, it's easy to isolate, understand, and back out if necessary.
If I'm half-way through a change and decide to abort, I don't lose much.
If I'm not sure how to proceed next, I can spend a few minutes on each of several approaches, and then pick the one I like, discarding the others.
My coworkers pick up most of my changes sooner, dramatically simplifying the merge problem.
When I'm feeling stuck about a big problem, I can take a few small steps that I'm confident in, checking them in as I go, thereby making the big problem a little smaller.
Working like this can help reduce the need for small branches, since you take a small, confident step, validate it, and commit it, then repeat. I've talked about how to make the step small & confident, but for this to work, you also need to make validation phase go quickly. Having a strong battery of fast, fine-grained unit tests + high quality, fast application tests is key.
Teams that I have worked on before required code reviews before checking in; that adds latency, which interferes with my small-step work style. Making code reviews a high-urgency interrupt works; so does switching to pair programming.
Still, my brain seems to like heavy multitasking. To make that work, I still want multiple in-progress changes. I've used multiple branches, multiple local copies, multiple computers, and tools that make backups of pending changes. All of them can work. (And all of them are equivalent, implemented in different ways.) I think that multiple branches is my favorite, although you need a source control system that is good at spinning up new branches quickly & easily, without being a burden on the server. I've heard BitKeeper is good at this, but I haven't had a chance to check it out yet.