Question
Unable to edit the case type and views with multiple operators in Pega Infinity v24.2
While a developer A is working on a case type and checked in his changes in a branch ruleset, developer B is unable to work on the case type and it is showing the case type is locked with developer A.
I have seen this behavior in 24.2.0 and I believe that is is resolved in the upcoming 24.2.1 patch release.
You can also consider the new Workspaces features in 24.2 that help to decrease the risk of Rule conflicts and overrides when multiple developers work on the same application
@Shirisha Boinapalliprior to 24.2 the experience was different, correct. However, the outcome was that Developer B changes from Branch B ended up in Branch A's version of pyDefault - so this wasn't a great outcome either, cross pollinating changes that needed to be unpicked prior to merge. This meant it was always good practice to try to find ways to avoid clashes:
- Allocation of development work: Try to split the development work in a way that avoids these clashes, where possible.
- Having one person in charge of the case lifecycle, like a BA, assembling what has been developed inside Data- or the Work- UX tab, will avoid clashes.
- Modular: These approaches have been successful in breaking up development work in to cleaner, encapsulated development – by leaning into App Studio’s focus on the “App” you can split development in your stack between apps, mitigating clashes when all developing in one application.
In addition to the above good practices there are a few other things that can help mitigate clashes.
@Shirisha Boinapalliprior to 24.2 the experience was different, correct. However, the outcome was that Developer B changes from Branch B ended up in Branch A's version of pyDefault - so this wasn't a great outcome either, cross pollinating changes that needed to be unpicked prior to merge. This meant it was always good practice to try to find ways to avoid clashes:
- Allocation of development work: Try to split the development work in a way that avoids these clashes, where possible.
- Having one person in charge of the case lifecycle, like a BA, assembling what has been developed inside Data- or the Work- UX tab, will avoid clashes.
- Modular: These approaches have been successful in breaking up development work in to cleaner, encapsulated development – by leaning into App Studio’s focus on the “App” you can split development in your stack between apps, mitigating clashes when all developing in one application.
In addition to the above good practices there are a few other things that can help mitigate clashes.
- Case Designer: "Save and run" button is a common culprit for this, as it will save a new version of pyDefault rule.
- Its common practice to do this but not necessary. Clicking Save and then using Preview can achieve the same outcome without saving a new version of pyDeafult
- Auto-save Views (Constellation): With the introduction of Constellation, assuming you're on Constellation? Modifying Views will auto-save, so this helps avoid clashes by using Save on the case type