FEU Binding when not logged in

[uptoeleven]

Hi,

In CMSMS administrator(s) are able to create Front End Users.

A convenient way to implement data records for a site (for example account details for clients, where each client might have more than one account) is to use FormBuilder - the data can be browsed in the backend by a FormBrowser.

That doesn't work though:

1.) Users (Front End Users) cannot log in and see their details. I can't bind a FormBuilder record to a FrontEndUser unless I am logged in as that FEU. That's fine for me but trying to document the steps for my 10 administrators and make sure they do it right every time is difficult. And if they get it wrong, user accounts go missing or worse, users can see each others confidential account information.

2.) Users (Front End Users) can't have more than one account. What if I want an account for me and ALSO an account for my cat / band / alter-ego / etc? If a FrontEndUser has more than one instance of a particular form bound to them, FormBuilder only displays the first form with that binding. What about where a FEU has two forms bound to them? Do I have to give up my cat for adoption? What about if his new owner also wanted to register?

Any answers gratefully received

Thanks

Simon

[uptoeleven]

FEU Binding is a blind alley in this case - here's how I'm resolving this:

In FEU I have a field called Client Reference (with the alias clientref) - it's the unique reference used to identify the client.

In the Contracts (for that is what they are) in FormBuilder I have a field called Client Reference, in the back end I make sure that this field matches what's in the FEU Client Refence. This is important.

I then use FormBrowser and in the User List Template:

Code: Select all

{foreach from=$list item=entry}
	{if isset($entry->fields[0]) && isset($client_ref) && $entry->fields[0]==$client_ref }
...
	{/if}
{/foreach}

Now: This is enforcing an anti-pattern which is why it's a terrible way to do this. We're massively overloading the database here because we get ALL the data, rather than just the data where clientref = whichever user we're looking for.

Unfortunately that's just the way fbrBrowser->BrowserShowList is written.

Additionally, the FormBrowser outputs fully formed HTML instead of urls for the CRUD functionality - and doesn't even give the option to access a "viewurl" as well as "viewlink", "deleteurl" as well as "deletelink" etc. Another anti-pattern - HTML hard coded into the class rather than a separation of display and functionality.

If I wanted to rewrite this and push it back to git, who do I talk to about forking and so on?