Don't require process patterns

[fosterlynn]

Make it so any page if there is not a pattern associated with the exchange or process or order or whatever, the page will function OK by loading resource types not filtered according to the pattern facet values.

Also don't require a pattern on creation.

(Note some of this might be done already.)

(Note: don't do anything associated with exchanges, I'll do that as part of exchange type work.)

[gcassel]

I may be wading in over my head, but this seems to make sense to me. I assume that each page should have viable default behaviors for handling inputs which it accepts--i.e., resources with one or more target attributes-- which have empty fields for one or more target attributes. (Some combination of target attributes may be mandatory, and other target attributes may be optional, right?)

Am I basically correct in thinking that resources with empty fields for one or more target attributes can be viably handled, with robust page design, by either:

1. not displaying them
2. arbitrarily arranging them
3. filtering and arranging them according to filters which may be either predetermined or selected by users' inputs
4. displaying them according to their role(s) in defined pattern facet values.

[bhaugen]

@gcassel the reason these patterns were created was because Sensorica had so many items on selection lists that they were overwhelming. So the patterns are a way of configuring what should appear on selection lists in different use cases.

The problem with patterns is that new networks now need to configure them even when they have short selection lists and don't need them.

And Sensorica complains about them, too, because they find the configuration to be difficult and error prone.

The reason for this issue to help new networks get going without requiring patterns. How to help Sensorica understand them is a different issue. We await alternative designs to handle the same problem.

[gcassel]

Thanks @bhaugen . I didn't realize that this issue was closely aligned with challenges in Sensorica's currently used value network software, and that specific context for 'pattern'. I lack capacity to orient properly at this time, so I defer to any and all involved parties.

[sqykly]

@TiberiusB This seems to be a usability issue as we scale. One solution would be a "default pattern" where anything goes, no configuration necessary. Another way to look at it would be merging the pattern editing UI into the process editing UI so that, while patterns exist, there is no setting them up separately; the upside is that you never have to go fiddling with them, the downside is that you can never re-use them, and I think ultimately as the system scales this will balloon your list boxes or become at least equally painful as you reconfigure the facet filter for every operation on the process.

In any case I say we fix at most one of this or #460 since they both target the same woes. Let me know what you decide.

[bhaugen]

@fosterlynn and @ivanminutillo have some ideas for how to do this. We want to do it in the other forks as well.

See this other issue for a discussion: https://github.com/django-rea/rea-app/issues/48