›
Welcome to the SRP Forum! Please refer to the SRP Forum FAQ post if you have any questions regarding how the forum works.

Preventing program deletion

MichaelMichael
in OpenInsight
Hola all,

My client just had an issue where a beginner programmer accidentally deleted a program from the main OI screen. The OI checkin/checkout is not used. I don't think the repository keeps a backup copy?

Two questions:
1. Is there a good system/repository setting to prevent deletion of programs (source and object)
2. Is there any other option to prevent deletion on SYSPROCS/SYSOBJ?

I'm about to write an MFS. Just checking before I take the plunge.

Gracias!

Michael

Comments

  • DonBakkeDonBakke
    If this is a beginner programmer perhaps you can change their access level from System Administrator to just Administrator. I think that should disable the Entity menu and avoid accidental deletes.
  • MichaelMichael
    Got it. But the authorities want to lock it down.

    Do I need to just write an MFS to block deletes?
  • DonBakkeDonBakke
    That is a solution. Not sure if it is the best solution.
  • MichaelMichael
    I'm definitely open to better!
  • DonBakkeDonBakke
    I can't offer better because you are obviously under constraints from "powers that be", and I don't know enough to offer alternatives that would satisfy their expectations. Otherwise this would be playing 20 questions and nobody got time for that. ;)
  • MichaelMichael
    Thanks anyway, sir
  • MichaelMichael
    So I wrote the MFS and it works to prevent deletion in SYSPROCS. But if someone deletes from the OI main window, it leave the SYSPROCS record but deletes the rest and it's no longer considered a "stored procedure." To make it work again, one would need to edit the SYSPROCS record, copy and then paste into a new stored procedure and recompile.

    Is there a better way to handle? Ideally I'd like to completely block the all the deletes associated with the program in question. Do I need to put the MFS on SYSREPOS or SYSOBJ or ?

    Thanks again!
  • DonBakkeDonBakke
    Putting an MFS on SYSREPOS is doable but I consider it to be too risky. I suggest creating a hook for the Repository function and adding logic that bypasses the DELETE request for certain conditions.
  • MichaelMichael
    I agree about the risky part.

    So I put the MFS on the SYSPROCS table, and it mostly works. The delete is blocked, and the source and object code are still there. The program will still run. All good. If the user happens to delete the entity from the main OI screen, it all still works, but the program is no longer registered as a stored procedure. One has to edit the SYSPROCS record, copy and paste into a new SP and recompile. It's doable but complicated for a novice (like the one who facilitated this to begin with.)

    I've tried using the RECOMPILE_PROC routine, as well as calling Repository with the COMPILE method. No joy. If there a good way to re-register a Repository entity that's been deleted when everything else is there?

    Gratzi!
  • DonBakkeDonBakke
    Most of what you wrote is a duplicate of your prior post. You didn't comment at all on my suggestion, so I'm curious as to why that route didn't work.
  • MichaelMichael
    I would have thought that simple recompiling would have set up the SYREPOS pointers and such. Just trying it before I get further down the rabbit hole.
  • DonBakkeDonBakke
    Do any of the comments (especially the end) of this thread help?
  • MichaelMichael
    Not really but it's ok. Doing something else. Thanks for the help!
  • MichaelMichael
    The plot thickens a little more. I put an MFS on SYSPROCS to prevent a delete, and it works pretty much as intended. The only problem now is that the SRP Search from the SRP Editor doesn't work any more. It's not returning the search results as before.

    Is there some config item or such that I need to tweak the make it work again?

    Thanks!
  • DonBakkeDonBakke
    Can you give me an example? Do you mean searching in general (i.e., any table), or searches against the SYSPROCS table specifically?
  • KevinFournierKevinFournier
    The SRP Table Search just uses the Open/Select/ReadNext statements. It does also use Yield so users can cancel the search.
  • MichaelMichael
    I have the SYSPROCS_MFS installed on the SYSPROCS table. If someone tries to delete a source code record, from TCL or the Repository, it is blocked successfully.

    I never use the SRP editor. Those who do, and are using the Table Search, can no longer search for anything, either in SYSPROCS or any other table. No results are returned.
  • DonBakkeDonBakke
    Don't know what the problem is. Nothing you described should have an impact, especially with the way Kevin noted the tool works. I might have imagined your MFS creating interference with SYSPROCS searches. But since you said it applies to all tables then something else went awry.

    Just curious, does Ctrl+R and Ctrl+O still work? That is, can you list keys in tables and stored procedures and open them?
  • MichaelMichael
    Again, the MFS is Only on the SYSPROCS table, so I have no idea why it's doing this for other table searches.

    The other weird thing is that the identical MFS is on SYSPROCS in a test environments, and we're not seeing any problems.

    Trying the Ctrl+R and Ctrl+O
  • MichaelMichael
    Ctrl-R and Ctrl-O both work fine.
  • DonBakkeDonBakke
    Does removing your MFS restore functionality?
  • MichaelMichael
    Haven't done that yet. Guess I'll have to.

    Weird that it's ok in other environments tho.

    Thanks.
  • MichaelMichael
    Removed and it works. As expected.
  • DonBakkeDonBakke
    I suppose you could add it back and debug to see if the search tool is hitting the MFS.
Sign In or Register to comment.