Form doesn't allow Submission, but create/update permissions set to "true"?

[JezC]

Hi, in line with some of my other mistakes, I've stumbled into
something else I clearly haven't understood. I now have a model where,
in desperation, I have declared:

...
belongs_to :owner, :class_name => "User", :creator => true
...
def create_permitted?
true
end

def update_permitted?
true
end
...

Yet still I can't get the "Create" button to show for either an
ordinary user or administrator for a "/model-name/new". What other
access controls or permissions might affect the display of the Submit
button for a new action?

I'm building an example app to demonstrate the problem, without giving
away any business logic, partially as a way to explore what's
happening, and partially so I can offer it to you guys if it helps
troubleshoot!

But I'm secretly hoping that one of you will just click their fingers
and tell me of either something I've overlooked, or a technique to
debug the permissions on a form...

[Ignacio Huerta]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

The model looks fine, I would check the controller (is the create
action available?) and then the Dryml. Can you paste some code?

Regards,
Ignacio

El 16/01/12 10:57, JezC escribi�:

- --
Ignacio Huerta Arteche
http://www.ihuerta.net
Tel�fono: 0034 645 70 77 35
Email realizado con software libre
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk8UMR8ACgkQBPlUJ6RHaOQCDwCbBQ/SD3VYxjWDQwUkSt+AdRGH
DxoAnAl59eURI7N4fPMnjiMh0UV2B6h0
=C+5P
-----END PGP SIGNATURE-----

[kevinpfromnm]

what's the view permission?  for create or update to be checked, the view has to be permitted first.

[JezC]

On Jan 16, Ignacio Huerta wrote:
> The model looks fine, I would check the controller (is the create
> action available?) and then the Dryml. Can you paste some code?

On Jan 16, 4:53 pm, kevinpfromnm <kevinpfro...@gmail.com> wrote:
> what's the view permission?  for create or update to be checked, the view
> has to be permitted first.

In the model that won't let me submit a form for creation (note that
it does show me fields, all of them that are defined in the DRYML, but
omits a few fields in the model definition - which makes me suspect
that something I've done is upsetting the field generation, provoking
a problem before the submit button code is yielded?):

The model:

fields do
primus :string, :required
secundus :string, :required
tertius :string, :required
quartius :boolean, :default => false
timestamps
end


# --- Permissions --- #

def create_permitted?
true
# acting_user.signed_up?

end

def update_permitted?
true
end

def destroy_permitted?
true
end

def view_permitted?(field)
true
end

From the controller:

hobo_model_controller

auto_actions :all

end

From the form.dryml:

<def tag="form" for="Troublesome">
<form merge param="default">
<error-messages param/>
<field-list fields="primus, secundus, tertius" param/>
<div param="actions">
<submit label="#{ht
'troublesome.actions.save', :default=>['Save']}" param/><or-cancel
param="cancel"/>
</div>
</form>
</def>

I have changed the field names to protect some business logic. Happy
to share a private GitHub repository with someone who observes a basic
NDA, while I try to reproduce with a sanitised app. The "submit" line
has only had the model name changed. It's not a name likely to be a
reserved word (think "airline_ticket" or "project_office" type names
rather than "model", "return", etc).

I'm completely stumped. But if you've read some of my previous posts,
that may be no surprise. :(

This same model exhibits some other oddities, BTW. One of the fields
is a boolean, and doesn't appear in the DRYML (quartius), and tertius
is in a "has many/belongs to" relationship, like primus and secundus -
but where they offer a selection dropdown, tertius offers a string
input. I offer that info in case it triggers recollection of some
other problem where possibly some way in which fields work may cause a
failure to show the submit button?

Thanks for your pointers!

[kevinpfromnm]

only things that come to mind are some small stuff: restart the web server, make sure the migrations are up to date with hobo g migration, double check your taglibs/views that there isn't a custom form defined

[JezC]

Thanks for the pointers of things to check.

Web server not just restarted, but changed. This is development
environment, so I kill and restart the server quite a lot. However, in
pursuing another problem, I changed the server from webrick to
unicorn. That solved a crash that I had with nested accessible models.
Doesn't fix this, though.

MIgrations - Pretty much any time I change a model, I run "hobo g
migration", just in case. Just done it again - still a problem.

Custom form modification was defined, though. I specified the fields I
wanted to show - but I didn't have the submit button. I thought I was
using a "form merge" to replace the fields, not the fields and the
submit button.

I think the real problem is that I put the form modification in
application.dryml - should I have put it in views/(model-name)/
form.dryml to make it more obvious for maintenance?

Thanks very much for your time helping me.

Regards, JeremyC.

[Matt Jones]

It wouldn't get loaded from there, unfortunately, unless you included it somehow. application.dryml is the typical place that such things go.

There is one important gotcha to note, however, between a param tag and a regular tag. For instance, this:

<def tag="form" for="SomeModel">
<form merge>
<field-list fields="foo, bar, baz />
</form>
</def>

will produce a form with fields foo, bar and baz but without a submit button, whereas this:

<def tag="form" for="SomeModel">
<form merge>
<field-list: fields="foo, bar, baz />
</form>
</def>

will produce a form with fields foo, bar, and baz *and* the default submit button. Note the : after field-list.

In the first case, you're replacing the entire content of the form tag with what you're passing. In the latter, you're passing the field-list parameter to form leaving the remainder of the contents unchanged.

--Matt Jones

[JezC]

On Jan 18, 3:47 am, Matt Jones <al2o...@gmail.com> wrote:
> On Jan 17, 2012, at 4:28 PM, JezC wrote:

...

> > Custom form modification was defined, though. I specified the fields I
> > wanted to show - but I didn't have the submit button. I thought I was
> > using a "form merge" to replace the fields, not the fields and the
> > submit button.
>
> > I think the real problem is that I put the form modification in
> > application.dryml - should I have put it in views/(model-name)/
> > form.dryml to make it more obvious for maintenance?
>
> It wouldn't get loaded from there, unfortunately, unless you included it somehow. application.dryml is the typical place that such things go.
>
> There is one important gotcha to note, however, between a param tag and a regular tag. For instance, this:
>
> <def tag="form" for="SomeModel">
>   <form merge>
>     <field-list fields="foo, bar, baz />
>   </form>
> </def>
>
> will produce a form with fields foo, bar and baz but without a submit button, whereas this:
>
> <def tag="form" for="SomeModel">
>   <form merge>
>     <field-list: fields="foo, bar, baz />
>   </form>
> </def>
>
> will produce a form with fields foo, bar, and baz *and* the default submit button. Note the : after field-list.
>
> In the first case, you're replacing the entire content of the form tag with what you're passing. In the latter, you're passing the field-list parameter to form leaving the remainder of the contents unchanged.
>
> --Matt Jones

Bingo. That was the missing bit. A single colon in the right place.

I guess I'll get used to looking in views/taglibs/application.dryml
when tracking down these sorts of problems. I was convinced, during
some of the debugging, that I'd not modified the form at all, because
there was nothing in the views for that model, other than a customised
index.dryml file. I'd added Bryan's paperclip and jQuery bits from his
cookbooks, in there - and was thinking of that file as a application-
wide resource, not one that held model specific code.

Obvious in retrospect - as most of these things are. :(

Thanks for your help, again.