Hi all,
There is an open PR https://github.com/theforeman/foreman/pull/1714 to add location_ids and organization_ids to the API v2 docs for the objects that can be associated with locations and organizations.
If we add these, then should we add all the other associations available on each object (i.e. domain_ids, subnet_ids, hostgroup_ids, compute_resource_ids, etc)?
Note, this is a documentation question and doesn't affect the code. Without strong_parameters (which is the current case), a lot can work in the API that is not documented. Another way to look at it is if we have strong parameters, would we then add *_ids as POST/PUT parameters or would we require the child node as defined in our current documentation regarding many-to-many associations is Foreman :: Manual .
Btw, I'm OK with adding location_ids and organization_ids as in PR #1714, but I just wanted to bring up the other issues for consistency.
Regards,
Joseph
I think we need to, though am concerned about maintaining it manually.
···
On 01/09/14 14:59, Joseph Magen wrote:
> There is an open PR https://github.com/theforeman/foreman/pull/1714 to add location_ids and organization_ids to the API v2 docs for the objects that can be associated with locations and organizations.
>
> If we add these, then should we add all the other associations available on each object (i.e. domain_ids, subnet_ids, hostgroup_ids, compute_resource_ids, etc)?
–
Dominic Cleal
Red Hat Engineering
I prefer to have the feature documented if it's accessible. It's
currently also the only way of associating resources if I'm not wrong.
+1 for being consistent and document other *_ids setters.
Regarding the manual maintenance - it's a common problem in apipie. I'd
love to see a way of sharing field definitions with models but I'm
afraid it's a deep future.
T.
···
On 09/01/2014 04:14 PM, Dominic Cleal wrote:
> On 01/09/14 14:59, Joseph Magen wrote:
>> There is an open PR https://github.com/theforeman/foreman/pull/1714 to add location_ids and organization_ids to the API v2 docs for the objects that can be associated with locations and organizations.
>>
>> If we add these, then should we add all the other associations available on each object (i.e. domain_ids, subnet_ids, hostgroup_ids, compute_resource_ids, etc)?
>
> I think we need to, though am concerned about maintaining it manually.
>