Fellow Engineers of the Roundtable, Greetings.
I have a situation where developers and leads break our rules established as best practices in code development; they code crap we don't want to go to production much less ever be used as a basis for future development.
Problem: How do we keep this stuff out of our workspaces?
Answer: Assign Blocking
Design: In my rtc db (a mirror of rtb but filled with all the cool stuff missing from rtb) I added the field assignBlocked (logical), userid (character), assignBlockNote (character).
Application: Any time the application architect finds code that he/she never wants to see again they simply right click on the version as it appears in the workspace desktop, and chooses Assign Block. This will cause a dialog box to pop up to accept the assign note (why it is to never be assigned again in any workspace) and then you click the [Block] button.
Result: The version will have the assignBlock flag set in rtc_ver and the previous version will roll back into workspace just like when you click the delete button.
The hook is make in the rtb_events.p "assignObjectBefore"event. It is as simple as checking the rtc_ver.assignBlocked flag and if it is set then reset pok and return a cerror value.
If you have this issue with your development team and if you are interested in this solution please give me a shout out.
That sounds pretty cool Richard. We had a feature a while back to allow Orphans to be hid forever with a note attached. This reminds me of that. Perhaps we should resurrect that feature but make it optional for any version..
Yeah not an original idea but one that solves a problem. I thought I would just throw that one out there and see how the community responded.
Sounds like you made schema changes to the RTB database. How do you preserve those changes across RTB upgrades ?
We have a system we call "task quality" to check versions before they get checked in not 100% fool proof but it helps.
Preventing an object version from getting assigned seems interesting, but we'd need it more in a context where a certain version may not be assigned to a particular workspace e.g. because it depends on database schema changes that are not present in that release.
This is often detected in workspace import but we currently cannot permanently mark a version as excluded, it will re-appear with the next import.
Looks like Richard is using a separate databases for this. Isn't that also what you are doing Carl?
We have also done that with other customizations we have done, using an "rtbext" database where we store data that is related to RTB and the custom solutions we have built - without making schema changes to the repository itself.