I think this a bug. When the element is restangulazied, it will set the id to the field id whatever happen which is called from here. Problem is that here, there is a custom getIdFromElem. So when trying to get the id, it will read the custom field and find nothing.

I'm not sure what would be the best way to solve it, probably reading both fields (the custom one and id) if we don't want users to have to defined a custom setter for ids (but that might break stuff if there is actually an id for whatever strange reason).

I will let @mgonto take a look at that.

Hi,

I have looked into this issue, I have been able to manage to get it working but changing a bit of code in rectangular and a bit in the implementation but I think the change would be worth it (please validate and if you like this solution I will implement it). Check the plunkr.

The idea is that to replace:

    config.setIdToElem = function(elem, id /*, route */) {
      config.setFieldToElem(config.restangularFields.id, elem, id);
      return this;
    };

    config.getIdFromElem = function(elem) {
      return config.getFieldFromElem(config.restangularFields.id, elem);
    };

with

            config.getFieldId = function(elem) {
              return config.restangularFields.id;
            }

            config.setIdToElem = function(elem, id) {
              config.setFieldToElem(config.getFieldId(elem), elem, id);
              return this;
            };

            config.getIdFromElem = function(elem) {
              return config.getFieldFromElem(config.getFieldId(elem), elem);
            };

This way you don't need to overwrite "getIdFromElem" to allow customize id names, but instead you overwrite (most likely with exactly same code) the new method "getFieldId". Because this method is used in get and set, restangularize it works ok in both cases.

As said, if you like this solution, I will implement it and add the pull request.

This would work for my use case, but I'm not sure if that's inline with the restangular architecture. As a consumer, determining what the difference between getIdFromElem and getFieldId might be quite non-obvious, but maybe not. I can't really say.

There is a mistake in my explanation, about no requiring changes to the code in the overriden method, as getFieldId should return the name of the id property instead of a value, so if someone has override getIdFromElem and overrides now getFieldId it would need to change to return just the name of the id instead of the value of the id.
Also, with this implementation behaviour is not changed at all (all code should work exactly the same as before the change) but you have the option to fix this issue.
Finally, I don't see a reason to override getIdFromElem anymore, so I would update the documentation to point that the use of custom ids is achieved by overriding getFieldId (hopefully easing the process to users).