Adding records via 'ADD'

[tazzmaxx]

Hi,

I have a reference object and when I click on the ADD button a list of availble records is presented. In my example I have 45 records in the list so what is presented to me is a system generated grid with the first 20 available records and the additional 25 records on 2 separate pages. If I select the top check box and highlight all of the records and click ok then only the records on the 1st page are added to the reference object. I then have to go back 2 more times to assign all of the records to the reference object. I can't imagine what a pain this would be if there were 100+ records.

My first questions is "am I doing this right"? and my next question is "is there a way around this?" It would be great if the system generated grid had a button that said "Assign All" and I could assign all of the records. Also, if I want a record on page 1 and 2 records on page 2 if I select the record on page 1 and then go to page 2 and click ok then only the records from page 2 display (it is like the page 1 selection is ignored). I hope that I am making sense. I'm sure that this is not the way that it should work.

[tazzmaxx]

Does anyone else see this as a big limitation?

[rocketman]

Question - do you need to physically pick from a list or can you be certain to hit the records you need using a query such as find refitems where refitems.x = y

If the latter, you could create a process and include it in the form layout.

The process would have 2 rules

1)The find statement
2) INSERT refitems in item.refattribute

If the button is on a form, the "Item" will be in context so the insert rule will be triggered for each refitem found by teh query in 1)

Hope this makes sense.

[tazzmaxx]

My simple example is assigning regions:

If I have a BO for States and a BO for Regions and I want to assign states to a Region then the user will only see 20 available selections. There is no way for them to filter the states to get exactly what they need because the states for each region can be completey different (BTW this is just an example).

If I select 3 states on the first page and don't commit them then when I page over and select states on the second page I will only get the states on that page committed.

Maybe this is not the way it is supposed to work? I never heard anything on this from anyone so I am assuming that this is the way the system is designed to function.

I am always open to suggestions that will make me better at using this system.

[rocketman]

Hi Tazz,

I suspect there is no way round this since it probably isn't an Aware limitation- more the way the web server/browser relationship works. I suspect the only way round the problem is either a) create ridiculously large pages size of say 200 records and accept you'll have to scroll OR
create a set of custom buttons which commits the ones you've already selected and then requests the next page

[e5n_devildog]

I am running into the same issue.

I understand that this is most likely a limitation of Ajax and web browser applications in general. Unfortunately writting this up for a user guide or explaining it to the end user is not that great of an experience.

Is it possible to add the ability for the configurator to be able to specify the action of the next button. If for example you could pick between just a standard next button or a next button that submits the page prior to moving to the next page.

I believe this would be a great enhancement to an already outstanding tool.

[aware_support]

This is Aware IM limitation, not AJAX. It was too tedious for us to implement persistable selection and we didn't see too much practical value in it.

If you need to assign all records, you can just write a process as rocketman suggested. Otherwise, I think the suggestion for a big page with scroll is better than getting the user to switch between pages (did I forget to mark that record? Oh, I have to go back next pages to check and then go back...)

[e5n_devildog]

Would the 'sumit page + next' be an option for consideration later. That seems to be much less tedious than implementing persistable selection. Basically just give the option for setting the button up as either a simple next button or a button that submits the page prior to moving to the next page.

[aware_support]

Possibly. We'll have to think about it.

[rocketman]

To Aware support. I do take your point about the way users act/think. Perhaps a better solution might be to provide a mechanism for dynamically setting the page length based on the number of BO's returned by the FIND or the COUNT. Maybe an accessible system variable for the "Number of records in the list" - or an "ALL" option when setting the list page size

..... Speaking of scrolling. There appears to be a bug in the "search Objects" when called from the Standard menu. When using "New Query" and finally arriving at the page which allows the user to select the attributes to be used, there is no scroll bar on the page which makes selection difficult. It is possible to use the arrow keys to move down but this requires you to select at least 1 attrib in the initially visible list before even being allowed to arrow down.

Might we not also have options to save/load queries. This would be a very handy user feature

[tford]

Build 1188 has a new feature which should help in certain cases when selecting references to add:

"Form-based queries and queries with prompts are supported in 'add references' operation"