To find out the objectid of your place, go to the place in Jive, go to the actions widget and click Feeds. You will see a number in the url.
The nice simple answer I was looking for!!
Unfortunately the solution provided does not work. The number in the URLs in the feeds page represents the objectID and not the placeID.
To this point I have not been able to find an easy way to get the placeID of a place other that querying though the REST API.
Worked for me.
Have you seen this thread? What table does placeID come from?
Providing you have access to to Admin Console and Database queries:
select * from jivebrowsecntr where containertype = 700
or, to have the dates formatted
select jivebrowsecntr.browseid, jivebrowsecntr.objecttype, jivebrowsecntr.objectid,
jivebrowsecntr.status, jivebrowsecntr.containertype, jivebrowsecntr.containerid,
to_char(to_timestamp(jivebrowsecntr.creationdate/1000), 'yyyy-mm-dd') as createddate,
to_char(to_timestamp(jivebrowsecntr.modificationdate/1000), 'yyyy-mm-dd') as moddate,
to_char(to_timestamp(jivebrowsecntr.lastactivitydate/1000), 'yyyy-mm-dd') as lastactdate
The resulting list will be all the social groups. Copy the results to your clipboard and paste in an Excel file.
Providing your instance is relatively static (new groups not popping up every day) you'll have a complete ready reference.
From your screenshot, the number which repeats on almost every line. Whether it technically is the placeID or not ......for me it works in my forms to post to that container when the form is completed by a user.
Sent from my iPhone
It is good that what you needed was not the placeID and that your form works. The placeID is sort of a globalID in jive, no other object in jive will have the same ID. Internally it is called a browsable object id and in the case of places they opted to call it placeID, in the case of pieces of content it is called contentID. The project ID, social group ID, document ID etc are only unique in the realm of the object they represent, that is, you can have docID=15 and projectID=15 but never placeID=15 and contentID=15.
When using the rest API all IDs refer to browsable object id; be it contentID or placeID. The object ID as in projectID or documentID is used mainly from the web UI.
Erick's note is almost, but not quite, completely accurate.
It turns out that placeIDs are unique across places, and contentIDs are unique across content objects, but you can indeed have a place with a placeID=15, and a content object with a contentID=15. The objects that are so identified are exactly the ones that can be manipulated via the unified places API (/api/core/v3/places) or unified contents API (/api/core/v3/contents) respectively.
If you've already retrieved the object in question (say, as a result of a search operation), the most reliable way to get the URI for an individual object is to look at the resources['self'].ref value in the returned JSON - that will always return the Core API URI to use to manipulate this particular object. As an added bonus, the verb names in the resources['self'].allowed array tell you what you can do with it (for example, if "PUT" is not in this list, then for your username this object is read only, so you could perhaps display a dimmed "Edit" link in a UI, or remove it completely). This is exactly the approach that applications like Jive Mobile use for determining what actions to show the user.
The other resources objects give you URIs for various other related things you might want to do (such as liking something, or enumerating the members of a social group) -- check out the API docs for the resources returned for any particular object type like Document or Group for more details.