Mappings between p4v interface and form-in triggers in P4

Question

We have agreed on certain rules in our repository, but I want to make sure that those rules are being followed. Some of those rules are:

• When attaching a job to CL, either when originally submitting it, or by editing it later, state of the job must remain the same
• Similarly, when editing jobs themselves, to add CLs to them, the state of the job must remain the same
• When submitting a CL, on submit parameter must never be Submit all selected files
• When creating a workspace, on submit parameter must never be Submit all selected files and line endings parameter must be set to unix

The last one, about the workspace, I've managed to enforce fairly easily, by using a form-in trigger that applies only to workspace forms, and doing a search-replace. I've also figured that p4 calls p4 fixes to attach CLs to jobs and transition them, although I'm not sure if that is something I can intercept and control.

For the last one I've tried manually entering p4 submit and p4 changelist to see what the forms look like, but which submit rule to use when submitting the changelist were not present in either. Those parameters are present when you access these functionalities through P4V gui when submitting a changelist.

Does anyone know what does p4v does in the background? How do I intercept this changes and how do I make sure they aren't "illegal"? Can I make sure that the job is not transitioned in another state (for the curious ones, we have p4dtg and the issue tracker is the authority for that field).

Answer 1

To see what P4V does in the background you should be able to enable logging of p4 commands and inspect what it's running via the log pane. P4V's interactions with P4D all happen via the same P4 commands that you can run from the CLI (the CLI is the thinnest possible wrapper around P4D's API, so if you become familiar with the CLI you'll have a thorough understanding of what can be done from any other client).

If you want fine-grained control over these workflows it'll be important to have a solid understanding of the data model, the API, and where you can insert hooks.

There are three different entities at play here:

1. Jobs (which you modify via p4 job and query via p4 jobs)
2. Changelists (which you modify via p4 change and query via p4 changes)
3. Fixes (which you modify via p4 fix and query via p4 fixes)

In addition to the commands that are primarily used to modify these entities, some commands will modify multiple entities at once; p4 submit is the most relevant example here, because at the time of submit you can create a fix for a job and transition the status of the fixed job (usually from open to closed) along with the status of the changelist (which goes from pending to submitted).

It's important to understand the details of how fixes work if you want to enforce rules around them: a fix is its own entity (see the documentation for db.fix) and neither creating a fix nor the job status change that happens as a side effect of a submit with an associated fix will cause a form trigger to fire on the job.

So the triggers you'll want to be looking at (and you will need multiple triggers operating in concert to lock things down as strongly as you describe) would be:

1. form-in (or form-save) triggers on the change and job forms
2. a change-submit trigger
3. a fix-add trigger
4. possibly command triggers on commands like p4 fix (e.g. to ban the -s status flag)