Clarity

A different kind-of debate...

I'm currently building some functionality, this involves a custom sub-object of the project object (a kind-of monthly status report).

Every month I will automatically create a new instance of the sub-object and copy forward various details from the previous month (all this I have working OK via GEL and XOG).

But I want to "lock" the previous month's instance (prevent users from editing it anymore) and only allow the users to edit the new current month instance.

So I have two options I think;

#1 : Lock all the attributes of the previous month at the point that I create the new month

               I think I have to lock the attributes through a new process though, don't think I can affect locked attributes through a XOG update

               (I know I can just insert into the locked attribute tables, but that would be unsupported)

#2 : Control everything through instance-level access rights ; only grant instance-edit rights on the new month, replace the edit rights with view rights for the previous month

               This sounds fiddly to me, but I believe I can do this all through XOG

Any options I've missed?  Any good opinions in how I should do this?

(I'm leaning strongly towards #2 by the way, I'm also concerned by loading up thousands of entries into the locked attributes table and what impact on the application performance that might have over time)

We do weekly Status Reports with your option #1 above. It's worked flawlessly for close to 4 years now. I don't know much about the potential for performance impact from the locked attributes tables. In the world of overgrown tables, there are other, more bloated tables that keep me up at night. Let me know if you want to dive deeper into this and I'll setup a webex.

Cheers Rob - so is the locking controlled via process rather than XOG then?

We keep this one 'in process' because it's lifespan is short. As a general ethic, to avoid an excess of long running processes I architect workflows as a collection of 'mini processes' with an eye towards the change events.

   One approach you could take would be to apply an OOTB paradigm to the object at create (eg: Not Started, Started, Completed or Open, Work In Progress, Closed), set the appropriate state in a locked attribute on your On Create event (Started or Open or WIP). Create an On Change process that locks everything when the state changes to Completed/Closed and schedule your monthly xog to get all (Started, Open or WIP) created before last week and xog in the state change (xog can update the read only attribute, but read only keeps fingers out).

   Voilà - locked history, no long running processes, all managed by 2 monthly xog processes scheduled as jobs and 2 object based processes that do the locking (set & lock status on start condition, lock all attributes on change of status to complete for your 'finalize') . Schedule the next month's create at a comfortable time after this one is scheduled to run and you're off and running for the next month.

Hmmm - sounds relatively painless ; you are selling #1 to me here! 

(Gonna think about it all for a few days before I start doing anything drastic)

If you choose option #2, won't users with Edit rights be able to delete the "Locked" records? This may or may not be desirable.

Well I think that the user would be able to delete (aka edit) the current month's instance, but not the previous months (since they would only have view access by then).

I'd have to consider that with #1 though also ; its no use me locking all the attributes on an instance if the user could then go and delete the whole thing

Sorry I wrote that wrong. I meant that with option 1, not 2. 

No one in our organization has create or edit delete permissions on our Status Reports using approach #1 above. Create is handled by the xoguser. We have a pretty tight box around what the fingers can do.

So your users don't edit their own status reports in the application?

Actually, everyone can edit all open Status Reports (Global Edit). The value is in getting data in - we allow teams to work together, delegate, back each other up, etc. No one can Create or Delete instances or change the historic data after it 'goes to the bank' either by being approved by the Portfolio Manager or late Friday night when the process times out, whichever comes first.

I think this is the object and data control that you're looking for, yes? Who or what populates your data and how is up to your business process. Edit is thankfully a separate permission.

Yeah think I'm confusing edit and delete and create ; create will be by a xoguser only.

Option #1 is clearly winning right now, the control you are describing is what I want  - thanks!

If no one can edit the records, why do you have to lock the attributes? Edit: Now I understand

Sorry for the confusion. I see my sloppy use of the word 'edit' above - my bad. I'll fix it.

Dave - also consider future generations. I'd have to be Dave Smart to understand all the instance level permission jockeying in option #2. Option #1 is easy code to understand and leverages supported, out of the box functionality (although I am intrigued by 'Padlocking'). Note: my Admin user can Create and Delete. When we got off the ground there was a little whining when things got missed and I had to go manually create an instance. People soon got their act together. We're well over 30,000 now and I can count on one hand how many times I had to manually create an instance, and only twice have I had to drop to the database to reword something. Outside of this this runs like clockwork and is 100% managed & executed by the users. 30,000 and counting and it requires no work or cat herding out of me? - that's what success looks like to me.

Go Green!

Great to see something good coming out of OSU.      Hey, I cheered for OSU over Oregon - my cheer order is Michigan Tech, MichSU, UofMich, Big 10.

Seriously, nice presentation.  Since you've published it here, may I share within my company (TRW/ZF)?

Thanks.

Go for it Dale. I've presented this at a couple events now - this has really worked for us. Let me know if you want to dive deeper. Go Green! I knew you were a Tech Alum. I have a very similar cheering order - only mine starts a little bit farther south here in the Buckeye State.

I think Paul Maxwell still follows this forum - talk to him about 'Padlocking'. It neatly gives you the access you want without cluttering up the Lock table.

You seem to have found a solution that you like, but, for what it's worth, I'll share an alternative approach that we've found works well for us.

Currently we have a relatively small number of fields that we capture as part of this status tracking effort.  We’re looking to expand in the near future, but the underlying concept should remain largely the same.  The architecture is relatively straightforward (a staging subpage of the project object, a status subobject of the
project object, and a Gel process that connects them). 

The setup works as follows:

1. A user navigates to a staging subpage of the project object that contains all the fields necessary for status tracking (i.e., things like status color, status comments, specific area to which the status relates if more than one are active on a project).  The user enters all relevant information and saves. 
2. The save event triggers a process that snapshots the entries in the fields on the project and, depending on a handful of factors, either creates a new instance of the status subobject, or updates the existing instance.  The factors we evaluate include how long it has been since the last status update, whether the status
   color has changed, and whether the status is area-specific or generic to the project, but you could certainly customize your own.  In some cases we even wipe the slate on the staging fields to make it easier for the next user that comes along.
3. Users have access to view all the historical status snapshots of the project status, but can only edit the staging fields on the project object itself.  Create, edit,
   and, by extension, delete on the subobject are all reserved for the admin account that is used by the Gel script to XOG in the updates.

No instance rights to worry about, the subpage can be security controlled, and you can customize nearly any set of criteria for evaluating how and when to update versus create new.  The whole process has worked for us for roughly 3 years at this point.  You can even, if so inclined, create an object portlet to allow mass access to the subobjects across all projects if you want to do data mining.

dhoover3.3 wrote:

 

I'll share an alternative approach that we've found works well for us....

 

Thanks - yes I do like that design as well ; can see how that would work and solve a lot of my issues.

I'm quite far down my sub-object route by now but definitely adding that "design" to my mental toolbox.