data entry extras and autoload #3764
Comments
|
I vote for extras entered in data entry to have a status of autoload,
because really they are no different than any other data we are entering
through that form - supposedly whoever is dong data entry has all the data
in front of them at that time. The only reason they are using extras and
not the original form has to do with limitations on the number of
attributes and parts allowed via the bulkloader, and is not related to some
"special" quality of the data being entered. This would simplify an already
complex process to allow one time entry of all associated data using the
Data Entry form, removing the requirement for someone (usually not the
person who entered the data) to go back and mark to load after the fact
and without all the resources in front of them.
…On Fri, Jul 23, 2021 at 1:48 PM dustymc ***@***.***> wrote:
* [EXTERNAL]*
From #3763 <#3763>, but it comes
up fairly often.
Currently data entry/add more ("extras") go to individual loaders, and
someone has to flag them to load. This mostly makes sense to me - they
should be reviewed in the same way as everything else that goes through the
bulkloader.
Alternatively, "extras" could be created with status autoload, in which
case they'll load themselves shortly after the catalog record is created.
This would be less opportunity for review, and probably more chance that
orphaned extras end up causing confusion and such - I think this would rely
on very good procedures and communication.
Maybe there's some middle ground, where some collection or user or
whatever could get autoload and everyone else gets 'linked to bulkloader,'
but I'm not sure how that would work, nor am I thrilled with the idea of
more complexity in an already complex situation.
Or perhaps this is best considered as part of #3691
<#3691> - eg we could (maybe,
somehow) make "extras" more unavoidable, which might make autoloading them
a little more approachable.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#3764>, or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ADQ7JBAVKB32YJMK57ECBHTTZHBPRANCNFSM5A4S6ARQ>
.
|
That is an argument NOT to autoload. Anything entered via data entry goes to the "Browse and edit" stage for review before final load. |
|
This will just cam back the opposite answer when some student enters all the wrong parts to 100 records and they autoload. |
|
That is what I mean - they should autoload as soon as their linked records
in Browse and Edit are loaded, without requiring operators to go back in to
the component loaders and mark them to autoload.
…On Fri, Jul 23, 2021 at 2:53 PM Teresa Mayfield-Meyer < ***@***.***> wrote:
* [EXTERNAL]*
really they are no different than any other data we are entering through
that form
That is an argument NOT to autoload. Anything entered via data entry goes
to the "Browse and edit" stage for review before final load.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#3764 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ADQ7JBBEDAVX2VH23O3MPSTTZHJFVANCNFSM5A4S6ARQ>
.
|
|
If a student enters 100 wrong parts now, that is still a problem even if
they don't use the extras. It is much harder to track all that if some of
the data are in limbo in the component loader while the rest of the data
are loaded.
On Fri, Jul 23, 2021 at 2:59 PM Mariel Campbell ***@***.***>
wrote:
… That is what I mean - they should autoload as soon as their linked records
in Browse and Edit are loaded, without requiring operators to go back in to
the component loaders and mark them to autoload.
On Fri, Jul 23, 2021 at 2:53 PM Teresa Mayfield-Meyer <
***@***.***> wrote:
> * [EXTERNAL]*
>
> really they are no different than any other data we are entering through
> that form
>
> That is an argument NOT to autoload. Anything entered via data entry goes
> to the "Browse and edit" stage for review before final load.
>
> —
> You are receiving this because you commented.
> Reply to this email directly, view it on GitHub
> <#3764 (comment)>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/ADQ7JBBEDAVX2VH23O3MPSTTZHJFVANCNFSM5A4S6ARQ>
> .
>
|
I think that's "when" not "if" but...
I'm swinging around to the idea that autoloading can't be a default - if we go there at all, it should be some sort of assigned privilege. |
|
While I may have proposed this - I really don't like the idea. We should be taking the review and load idea more seriously than we do and if stuff is getting loaded without ever being reviewed, you better trust the person who entered it (including yourself). The reality is that we need to somehow make the review part easier and I probably need to sleep on it for a few days before I offer anything up. |
|
Maybe this needs its own issue, but I think I should only be able to see stuff in the component loader that I have the ability to load. For example, in the Part Bulkload tool, I can see (and apparently edit, load, delete) stuff that @acdoll loaded. I have zero access to DMNS collections but now I sorta do?
I feel like this is not good.. |
|
Well, nevermind? I kinda tested this out with Itzue at Lingnan and she couldn't see any of this. Still, I'm curios why I can see DMNS stuff.... |
|
Access is pretty open for users with sufficient rights. I'm up for better ideas, but whatever happens you should be able to find things that aren't (yet) linked to any record/collection (many ways to do that in several loaders), and you should be able to deal with things that got left behind by former employees and such. I think this is a case where the The Community just has to act as such. |
I think we need to document exactly what the permissions are. |
|
Suggestion that during the AWG Issues meeting -> put more Add More Buttons around the Data Entry screen. Put one at the attributes, put one at the parts, put one at the identifiers, etc. |
|
AWG Issue Group discussed and suggested the following:
So that way people have the option to load the core data without autoloading the Parts Bulkloader extras, Is this possible? |
|
Resolved via AWG meeting and #3436 (comment) |
From #3763, but it comes up fairly often.
Currently data entry/add more ("extras") go to individual loaders, and someone has to flag them to load. This mostly makes sense to me - they should be reviewed in the same way as everything else that goes through the bulkloader.
Alternatively, "extras" could be created with status autoload, in which case they'll load themselves shortly after the catalog record is created. This would be less opportunity for review, and probably more chance that orphaned extras end up causing confusion and such - I think this would rely on very good procedures and communication.
Maybe there's some middle ground, where some collection or user or whatever could get autoload and everyone else gets 'linked to bulkloader,' but I'm not sure how that would work, nor am I thrilled with the idea of more complexity in an already complex situation.
Or perhaps this is best considered as part of #3691 - eg we could (maybe, somehow) make "extras" more unavoidable, which might make autoloading them a little more approachable.
The text was updated successfully, but these errors were encountered: