Bug 809286

As a follow on possibility, where there is an "assigned writer" tag, maybe it could default to the kerberos id of the writer who creates a topic.

This should be captured by envers when a topic is created or edited.

Added in 1.4-SNAPSHOT build 201401151219

There are now two additional query fields in the Topic and Content Spec search REST api: "createdBy" and "editedBy". Each field will do an exact match as doing a like query cannot be optimized enough to actually be efficient.

Example call:

http://localhost:8080/pressgang-ccms/rest/1/topic/get/query;createdBy=lnewson;

Additionally these fields are exposed in the UI on the respective "fields" page under the "Edited By" and "Created By" text boxes.

Note: This will only do a search where the user details were supplied to the REST api. As such since the UI always sends the "Unknown" user this may not be of much help until that information is accurately captured using Authentication mechanisms.

Note 2: This version is currently live on the test/development server.

Did various searches with editedBy and createdBy (using lnewson and the Unknown user), and the results came back as expected.

We should have the option to negate these searches (i.e. not created by lnewson).

What would be the use case for the above, as I didn't implement it because I couldn't see why anyone could ever require that information. The other reason, is that it is going to return a lot of topics (depending on the database size and number of users).

<mcasperson> the use case is to find all topics that someone else edited. perhaps an author has let some developers contribute to the guide and needs to find all topics that were edited by someone other than themsleves
<mcasperson> as opposed to doing multiple searches against usernames, or having to know all the people who might have contributed
<mcasperson> it would almost always be used in conjunction with "topics in spec" or something like that

Added the ability to negate the searches using the notEditedBy and notCreatedBy (so that they follow our normal negating variables).

This version is currently deployed on the development/test server.

Note: We may need to handle null/blank usernames differently.

Additional Note:

I've removed the fields from the UI as at the moment they are more than likely going to confuse users until Auth is implemented.

Removing the target release flag until this bug can be completed.