Hi,
If we are on the topic of the Entry ID creation, I have some definite ideas.
Nowadays, entry ids can be allocated in blocks, and there might be holes
in the list when ids are skipped. The nextid for the form can be stepped
forward even when the submit fails. This is actually the default behavior
in 7.6.04.
My idea is to have a form-specific check-box to reserves the entry id
BEFORE the filter processing starts.
We could also allow admins to get the unique entry id from the server via
an ACTL by doing a set-fields RequestID = GETRESERVENEXTENTRYID($SCHEMA$).
Nothing bad can come of this, as the uniqueness of the entry id is
controlled by the database anyhow. All the safeguards are already in
place.
Best Regards - Misi, RRR AB, http://www.rrr.se (ARSList MVP 2011)
Products from RRR Scandinavia (Best R.O.I. Award at WWRUG10/11):
* RRR|License - Not enough Remedy licenses? Save money by optimizing.
* RRR|Log - Performance issues or elusive bugs? Analyze your Remedy logs.
Find these products, and many free tools and utilities, at http://rrr.se.
> Not having the Entry ID before submit is why GUIDs are used. I can't
> think
> of case where I was not able to use a GUID to work around the Entry ID not
> being available before submit.
>
> As much as I love new features and flexibility I think Misi is on to
> something here. Adding phase overriding at the action level would be
> powerful and could also be a support nightmare. Typically splitting the
> action into it's own filter does the job without adding another layer of
> complexity to all filters.
>
> Jason
>
> On Tue, Dec 13, 2011 at 11:35 AM, Joe Martin D'Souza
> <[email protected]>wrote:
>
>> I cant recall any other reasons from the past, besides the requirement
>> of
>> an entry being committed to the database, either because you need its
>> entry
>> ID available during the transaction, for the use of some other action.
>> This
>> applies to the entry ID's created from Push Fields too.. You can get
>> around
>> this 50% of the times as you pointed out by manipulating the order of
>> filters or the actions that are required post ID creation.. but at times
>> you hit a wall where its just not possible and you wished that there was
>> a
>> little more control on phasing on a particular action in a filter..
>>
>> Joe
>>
>> -----Original Message----- From: Misi Mladoniczky
>> Sent: Tuesday, December 13, 2011 3:36 AM Newsgroups:
>> public.remedy.arsystem.general
>>
>> To: [email protected]
>> Subject: Re: Commit Changes vs PERFORM ACTION APPLY
>>
>> Hi,
>>
>> Why would you want different actions to run in different phases? Do you
>> have any good user case?
>>
>> I would guess that the need arise very seldom.
>>
>> In that case I think we can split the filter into two filters instead.
>>
>> Adding granularity to what we can control, also makes the possibilities
>> for errors and mistakes much greater...
>>
>> Best Regards - Misi, RRR AB, http://www.rrr.se (ARSList MVP 2011)
>>
>> Products from RRR Scandinavia (Best R.O.I. Award at WWRUG10/11):
>> * RRR|License - Not enough Remedy licenses? Save money by optimizing.
>> * RRR|Log - Performance issues or elusive bugs? Analyze your Remedy
>> logs.
>> Find these products, and many free tools and utilities, at
>> http://rrr.se.
>>
>> While you'll brought out this idea, if at all BMC ever intends to
>> change
>>> the
>>> way this works along the lines of your ideas, it would be even cooler
>>> if
>>> they changed it in such a way that you could control the specific phase
>>> you
>>> would like each action within a filter to run after you check that
>>> check
>>> box
>>> to override default phasing.. options like Default to let the action
>>> run
>>> on
>>> the default phase, Phase 1, Phase 2 etc for every action in that Filter
>>> so
>>> you could choose what action you would like the override..
>>>
>>> That would probably add a lot more control than just saying - ok all
>>> actions
>>> run on phase 1 with the `! convention..
>>>
>>> Joe
>>>
>>> -----Original Message-----
>>> From: Grooms, Frederick W
>>> Sent: Monday, December 12, 2011 10:40 AM Newsgroups:
>>> public.remedy.arsystem.general
>>> To: [email protected]
>>> Subject: Re: Commit Changes vs PERFORM ACTION APPLY
>>>
>>> I had put in a RFE back in 2010 to change the `! into a "Phase
>>> Override"
>>> radio button, but it was closed. I had suggested the radio
>>> button/dropdown
>>> so we could override the phase in all directions (I can see times where
>>> we
>>> would want a filter to run in Phase 4, such as if we have to push to on
>>> outside system after all processing is complete on a record)
>>>
>>> Fred
>>>
>>> -----Original Message-----
>>> From: Action Request System discussion list(ARSList)
>>> [mailto:[email protected]] On Behalf Of Rod Harris
>>> Sent: Monday, December 12, 2011 7:14 AM
>>> To: [email protected]
>>> Subject: Re: Commit Changes vs PERFORM ACTION APPLY
>>>
>>> ** Yeah Misi,
>>>
>>> I'm a bit surprised that the run process commands have grown so much
>>> faster
>>> than the actions. I guess it's quicker to develop features as Run
>>> Process
>>> commands rather than have dev studio hold our hand and check the syntax
>>> and
>>> context on entry. I know that it wouldn't be practical to expect every
>>> run
>>> process to be implemented as an action but for some of the very common
>>> ones
>>> it would make a lot of sense. A business time command would be nice.
>>> The
>>> syntax on those process commands is darn tricky even for experts.
>>>
>>> The other thing that has surprised me is that the odd `! naming
>>> convention
>>> for overriding filter phasing has survived all these years. Surely it
>>> would
>>> be much nicer to have a simple check box field or something to indicate
>>> this. It would be easy enough to phase out the old method over time and
>>> just
>>> auto set the new check box if the name ended in `!
>>>
>>> I'm not a fan of the mechanics of a piece of code featuring in the
>>> name. I
>>> think it should describe what it does rather than how it does it. If
>>> you
>>> change how it does it then you have to change its name also. In Remedy
>>> since
>>> the name of an active link or filter etc. is the key you have a problem
>>> with
>>> version control if you keep changing the names of things. If you leave
>>> the
>>> name the same despite changing how things are done then your naming
>>> convention becomes compromised.
>>>
>>> There's a lot I love about Remedy and it does keep getting better but
>>> I'd
>>> like it if these couple of things were improved.
>>>
>>> Rod Harris
>>>
>>> -----Original Message-----
>>> On 12 December 2011 16:32, Misi Mladoniczky wrote:
>>> Hi,
>>>
>>> I definitely vote for Commit Changes!
>>>
>>> Why use the ugly Run-Process bla bla bla syntax, when you have an
>>> action
>>> that does the same thing?
>>>
>>> Best Regards - Misi, RRR AB, http://www.rrr.se (ARSList MVP 2011)
>>>
>>> Products from RRR Scandinavia (Best R.O.I. Award at WWRUG10/11):
>>> * RRR|License - Not enough Remedy licenses? Save money by optimizing.
>>> * RRR|Log - Performance issues or elusive bugs? Analyze your Remedy
>>> logs.
>>> Find these products, and many free tools and utilities, at
>>> http://rrr.se.
>>>
>>> -----Original Message-----
>>>
>>>> That's a good question Mark. I'm not aware of any differences that
>>>> would
>>>> make one more efficient than the other. Personally I prefer to use the
>>>> "Commit Changes" as it seems cleaner to use this rather than one of
>>>> many
>>>> run process commands.
>>>>
>>>> Rod Harris
>>>>
>>>> -----Original Message-----
>>>> On 9 December 2011 04:51, Brittain, Mark wrote:
>>>>
>>>>>
>>>>> HI All,****
>>>>>
>>>>> Commit Changes vs. PERFORM ACTION APPLY. Is one better to use than
>>>>> the
>>>>> other on ARS 6.3?****
>>>>>
>>>>> I have one active link that populates data from a SQL query and a
>>>>> second
>>>>> active link to commit the changes. These were probably created under
>>>>> ARS
>>>>> 3
>>>>> or 4. The Commit Changes does the job but always looking to smart way
>>>>> to
>>>>> do
>>>>> things.****
>>>>>
>>>>> Thanks****
>>>>> Mark ****
>>>>>
>>>>>
>>>>> *Mark Brittain*
>>>>> Remedy Developer****
>>>>> *NaviSite - **A Time Warner Cable Company*
>>>>> [email protected]****
>>>>> Office: 315-453-2912 x5335****
>>>>> Mobile: 315-317-2897****
>>>>> ** **
>>>>>
>>>>
>> ______________________________**______________________________**
>> ___________________
>> UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
>> attend wwrug12 www.wwrug12.com ARSList: "Where the Answers Are"
>>
>
> _______________________________________________________________________________
> UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
> attend wwrug12 www.wwrug12.com ARSList: "Where the Answers Are"
>
_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
attend wwrug12 www.wwrug12.com ARSList: "Where the Answers Are"
