Restrict Lock by Node Type or Format

Well that sounds like a great feature. Thank you for the contribution, i will have a look at the patch ASAP

I have tried to address the following problems with my revision of this patch:

• The line which sets nodes to be lockable by default:
  

  $lockable[$node->format][$node->nid] = TRUE;
  

  was misplaced in the first patch. I moved it to its proper location. In its original state, that line prevents this patch from doing what it claims to do ;-).

• I also renamed content_lock_is_lockable_node() to _content_lock_is_lockable_node(). I'm not sure if this change was necessary or makes sense, but _content_lock_is_lockable_node() is not intended for use by other modules and isn't passed around as a callback function. Thus I think it deserves the ``private function namespace''.
• I also found that the checkboxes for $form['content_lock_allowed_formats'] and $form['content_lock_allowed_node_types'] had $form_state['values'] arrays that looked like this:

  $form_state['values']['content_lock_allowed_node_types'] = array('page', 0, 0, 0);
  $form_state['values']['content_lock_allowed_formats'] = array(0, 0, 0, 0, 0);
  

  This broke the logic for when no checkboxes are checked. The logic expected an empty array when no formats were selected instead of array(0, 0, 0, 0, 0). For example, with the above values, the original patch would not lock non-page nodes with any content type.

  I hope that my method of hijacking $form['#submit'] and relying on my submit function, content_lock_admin_settings_submit(), being called first is acceptable.

• Now for the most controversial change:
  The original patch would enable node locking if either the allowed_formats OR allowed_node_types checks were satisfied. For my specific case, it makes more sent to check if both allowed_formats AND allowed_node_types are satisfied. I think that it could be argued that the user should be able to choose between OR and AND; however, I have not made this configurable for sake of simplicity (and fewer bugs ;-)).

  I will argue here for the using a hardcoded AND. The use case of this patch would more often be to disable any side effects from using content_lock. Such side effects would either:

  1. be caused by a conflict with a special input type
  2. or be caused by conflicts with a certain node type, such as a node type that does radical things with hook_form() and hook_form_alter().

  Thus, one would most likely want to disable all uses of content_lock with the special input type or conflicting node type. In the original patch using OR, this is practically impossible without creating crazy numbers of input formats and node types.

Grayside: this is a very useful patch :-)
EugenMayer: and your useful content_lock module could be very much more useful with this patch applied :-D (after the due process of review and further fixes if necessary ;-)).

ohnobinki you seem to have quiet some insight in content_lock already. Iam really busy since some time, keeping up the other modules i maintain. This module kind of lacks of "love and care". Are you interested in co-maintaining and helping directly? You patch looks good - your ideas and thoughs are perfectly fine. I did not yet look into the patch i admit, i have to take my time for this, iam sorry.

I have created a github project: http://github.com/EugenMayer/content_lock

I recently cleaned up the code a bit, fixing some smaller bugs. Are you familiar with github? If you like, i can give you access and you could add a branch for your changes. I think we can work much smoother together that way. you can fork ofcourse and make a pull request, but iam willing to give you access. The only rule i have, never push into the master alone. Always double check with me, so we always have the stable branch.

Are you interested in co-maintaining and helping directly?

I haven't done anything like this before and I don't have too much time myself, but I'd like to try :-).

Are you familiar with github? If you like, i can give you access and you could add a branch for your changes.

Yes, my github account is http://github.com/ohnobinki . I'm willing to follow your rules for branch creation and I understand the desire for a stable repository.

Thanks.

I have added you as contributor on github - you can create and push branches now. I have added you as co-author @content_lock, welcome on board!

Some rules for co-maintainers:
- Be kindly is possible :)
- Dont release without double-checking with me
- Dont remove releases without double-checking with me

You can freely work on issues set their status and work as you wish. You can accept or denie patches and so forth. Iam glad for every minute you help, so dont worry about how much time you have :)

thank you!

// Edit: You need to apply for a co-maintainer CVS account. Just read up how to apply for CVS. In addtion, open a new issue on this module and write down the CVS appliance issue link. I will comment there that iam glad you will co-maintain and this should be it :)

Good, much cleaner than my submit handler. :-) And thanks for catching my parentheses error, it went against my whole argument ;-).

Good work guys. Ohnobnki will you apply this on your branch?

EugenMayer: already pushed to the git repo, http://github.com/EugenMayer/content_lock/commit/1a2568045f63faf2f8b8c64...

I yet did not get it full. Does the input filter change remove the lock or what is actually the effect?

Grayside: I'm working on it... or was today, I can continue Monday ;-).

Grayside: OK, I think that this patch finally addresses your concerns about the input format changing. I was unable to decipher what you were trying to point out in the wysiwig module -- that module acts at a form element level, not at either the hook_form_alter() level or node (hook_nodeapi()) levels ;-). I think that the method of using a hidden form input is the only way to make sure the correct functions see the original input, or is there a better way?

I also fixed another content_lock bug where previewing a node resulted in the onUnload javascript stuff not loading and locking not being managed.

This is all committed to the github content_types branch already: http://github.com/EugenMayer/content_lock/tree/content_types

EugenMayer: what's the next step of getting this into CVS or whatnot?

Hey Nathan,

great work there!!

Iam currently cleaning up the code a bit ( older cruft mainly, not your implementation ) and mergin it into our dev branch. Then we actually only need some testing and if it all works, we will merge it with tha master, tag it with 1.1.

As 99% of all commits were done by you, your the one doing the commits into CVS as all credits go to you. Just right after it, i create a release and we are done :)

Is that ok?

OK :-).

merged into dev now

released in 6.2.0 rather then in 1.1. 1.0 will be discontinued