After prepoulating fields (new) content can not be saved if it was edited before

This is actually a bit of a design conundrum.

In order to respect access controls that might be set by other modules Prepopulate operates on fields in an #after-build which means that in fact the user has no way to override what is in the values. The challenge is that any other way of doing it would allow users to potentially circumvent access controls. One possible solution is to allow the site administrator to specify which fields they want to allow pre-populating on which forms and allow that to bypass security. That will be a major project but would be an interesting idea to pursue.

I have written a patch that solves this and other problems, you are welcome to test it and provide your feedback if you can. It applies to 7.x-2.x branch.
You can find it attached to this issue:
#1489526: Improve prepopulate behavior

jbrauer: Hmm...can we start with a simple permission that allows privileged roles to change values in any form? This would solve my immediate issue (and maybe that of others), and then a more elegant solution could be worked out after that. If this sounds feasible, I'll create a separate issue.

I suppose this permission would use #process for privileged user roles and #after_build for the rest. I'd need a bit of guidance on the "playing nice with other modules" part of this, but we could work that out in the patch review phase.

Updating version, as it is basically the applicable version now anyway.

...Nah, don't really understand how to go about this. If I can catch you in #drupal-contribute some time jbrauer maybe we could chat about it. For now, I'll remove the value that sometimes needs modification till there's a workable way to do this. Good luck Norberto Ostallo - thanks for your efforts to see this through!

Here is a question - bear with me - I might not understand the form API that well...

Why does the code of the Prepopulate module need to run again on form submit, thus overwriting the values?
Doesn't it make more sense to only run once, when the form is initially rendered?

Just to test, I modified the line #43 like this:

if (isset($_REQUEST['edit']) && !$form_state['submitted'] && !$form_state['process_input']) {

The _prepopulate_request_walk function runs only the first time, the values are pre-populated and from then on - I am on my own. Validation works too.

Please let me know what am I missing?

It works for me too! is it really that simple or am i missing something?

It needs to be later because something else might have altered a user's permissions to access those fields. Absent this later check there is no way to be certain that the user has access to those fields, that they are editable etc. It definitely does limit the general usefulness of the module.

Yes but shouldn't permissions be checked after the form is submitted, independently of prepopulate? In any case, if this is something that cannot be done in another way, can there at least be an option for the people who want to take the security risk in order to have the functionality?

Finally I want to point out that from a UI perspective, the prepopulated fields should be disabled on the form, if it is pointless to change their value as is the case now.

Agreed being disabled would be a good change for the UI.

The options for sites that want to handle forms on a one-off basis include rolling this sort of module for individual forms where they choose to have this option. Another option goes back to #252053-5: Allow admins to hide prepopulated fields which in comment 5 notes that this module had gone in a different direction allowing it to work on all forms rather than allowing administrators to select which forms it works on. Ideally I'd like to see the module work more like mollom and present a list of forms available and the site administrator to say which forms can be prepopulated.

Marking this as postponed as it really can't be securely changed until a means of selecting forms is provided to administrators.

Even better, this should be handled by field instance, like entityreference_prepopulate does it.

That form, and relatedly making this something that works only with Fields would be a positive change.

Either I don't understand this bug, or I am not able to reproduce it -- for me it only occurs on node preview.

I have a node type 'article' with a text field field_test_text_1 on it.

I go to the URL node/add/article?edit[title]=foo&edit[field_test_text_1][und][0][value]=foo

The node title and the field are both prepopulated with 'foo', as expected.

I change the content of both fields to 'bar', and save.

The node is created with the title and the text field set to 'bar', as expected.

The problem DOES occur if I preview the node before saving.

The simplest and universal fix is to say that when a form has 'rebuild' = TRUE, ie, it's on a later step in a multistep form, we don't prepopulate. This makes sense, because the prepopulation work has already been done: the values have been put into the form elements, and they can now just behave as normal form values.

Thanks this looks good in my testing. Committed.

After some tests I noticed that, for some reason, this patch not work with float type fields.

So, i incremented the solution of joachim and made this new patch. It worked for me.

We would need this for Drupal.org, some of our custom prepopulation is meant to be used as a template.

The problem is due to float field widgets having an #element_validate callback set on their form element; indeed, this will affect anything that has an #element_validate callback where the callback puts a new value into the form

All the documentation and usage examples for #element_validate say to do this:

function number_field_widget_validate($element, &$form_state) {
  // ...
  $value = $element['#value'];

Unfortunately, that's where prepopulate put its value, and the user-input value is nowhere to be found in $element.

If the callback then goes on to process that value in some way and then put it back, like this:

      form_set_value($element, $value, $form_state);

-- then the user input value is zapped, and the prepopulate value gets put into the form state.

The patch in #18 is not fixing this for me.

#18 almost work for me, but need to add this code to prepopulate_after_build function:

<?php
  if (!empty($form_state['input'])) {
    return $form;
  }
?>

I was looking at this when a user submit a form with validation errors the fields are overwritten.

I created a fix for this like #22

So here's a patch for that. Not sure if this fixes the preview issue but this will fix the error submitted form.