I agree... We have had the same difficulty.
In our situation we had a CMDB for which we needed rollback capability for updating CI/Child records. For each table field we built a transaction storage form that stored all the Child Record transactions until the Parent record was committed. Once the Parent Record was committed - the child updates were then sent to their respective tables and the temporary record(s) deleted. Probably another way to do it under the 7.x paradigm - would be to take advantage of the "Audit" feature for rollback (depending on the amount of fields involved). As for when multiple people are editing a single Parent record - I thought there was a Remedy error trapping mechanism that let you know when you tried to commit that there were new changes to the record that you were editing - then it asks you if you want to save anyway??? On May 26, 12:13 pm, Robert Halstead <[email protected]> wrote: > As I understand it, Remedy doesn't provide a check on who is looking/editing > a record. The only check Remedy does is a last modified time check. We are > running into this same issue when multiple people edit the same record. We > plan to implement a read/read-write locking feature in our own system though > I wish remedy had the ability to lock records down. > > On Fri, Feb 6, 2009 at 12:17 PM, Michael Drew > <[email protected]>wrote: > > > > > Depending on the nature of the data, you could perhaps use the table field > > as your temporary storage (I.e. Set field local action to place your various > > values into the currently selected row in the table) and do a table walk to > > send the table values back to the actual child entry's records when you hit > > save on the parent. > > Michael. > > > ------Original Message------ > > From: Brien Dieterle > > Sender: Action Request System discussion list(ARSList) > > To: [email protected] > > ReplyTo: [email protected] > > Sent: Feb 6, 2009 3:34 PM > > Subject: transaction for parent/child changes > > > ** We've designed a form that has child requests displayed in a table list > > field. You can interact with these child requests through this form and > > update them via display only fields and push-fields activelink buttons etc. > > So the problem is you can update some things on the main form, and update > > some children requests, close the main request and say "yes, lose changes". > > A user might expect that the changes to the children would be reverted back > > to what they were. > > > Is there any way to encapsulate the whole process of editing the primary > > requests and N children requests into a single transaction that gets > > committed only upon saving of the primary request? > > > Thanks! > > > Brien Dieterle > > __Platinum Sponsor: RMI Solutions ARSlist: "Where the Answers Are" html___ > > -- > "A fool acts, regardless; knowing well that he is wrong. The ignoramus acts > on only what he knows, but all that he knows. > The ignoramus may be saved, but the fool knows that he is doomed." > > Robert Halstead > > _______________________________________________________________________________ > UNSUBSCRIBE or access ARSlist Archives atwww.arslist.org > Platinum Sponsor:[email protected] ARSlist: "Where the Answers Are" _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor:[email protected] ARSlist: "Where the Answers Are"
