problem with '+add' button not populating id

[skyrun]

go to http://www.skyrun.com/skyforce/leads and click on +add under related data column activity. the lead id should be filled in but it's not.

same if you click on an item that has activities (like act(6)) to bring up an activity list filtered for that lead, and then click the +add button on the activity table itself.

on both, it looks like the sf_activity___lead_id_raw=1 which should set the proper lead it is included on the url, but the proper lead id is not showing on the add/new activity form... in fact if i change the url to addd another field like the 'from' field, it fills it in... like http://www.skyrun.com/skyforce/lead...ivity___lead_id_raw=7&sf_activity___from=test but the 7 doesn't go into the lead id, so the add doesn't work.

fyi, the lead_id form access on the element is set to 'nobody' so that it's read-only, but even if if change it to 'public', it doesn't work.

 

[rob]

This works ok on my test page. As long as the element is editable in the form, if I set the elements' form access level to nobody then the value is not filled in.

I think we recently decided that you can't edit the value of an un-editable element via the query string - which does make sense to my mind.

Seems like you have some debug stuff in there at the moment as all I see when I click on the related data add link is 'NO ID SENT!!!' ?

 

[skyrun]

oh.. i keep forgetting that in order for the id to be passed along on the add, that the element with the id hard coded (ie the user can't change it and doesn't have to assign it), then it needs to be 'public'ly editable but hidden.

to debug, i put it on the form (read only) to try to figure out why it wasn't being filled in which is precisely the wrong thing to do since that causes it to not work. i could see when it would be nice to display the id but not allow it to be changed though so the user has a visual clue as to what larger item that they are adding an sub-item to (which activity they are adding a lead to in this case).

 

[rob]

I agree, but we don't currently have a mechanism for that. Something like a 'disabled' property would be needed. So a field can show non-editable data that is not recorded to the db.