These appear to be "today" values. Not sure if these will include dashes.

IdentifierTypes are system wide.

Identifiers decorate Identifier Types and are effective dated.

Case Type Configuration decorates (Node, Case Category, CaseType) and is effective dated.

Disclaimer Configuration decorates (Node, Disclaimer) and is effective dated.

Filing Code Configuration decorates (Node, FilingCode) and is effective dated.

Optional Service Configuration decorates (Node, OptionalService) and is effective dated.

Party Type Configuration decorates (PartyType, CaseType) and are effective dated.

Similar to location in ECF. These are hierarchical and effective dated.

This looks to be a date and time with time zone. Values in the example are GMT.

This is the internationalization (i18n) mechanism. Displayable strings exist in one or more culture codes for a specific language.

Configurable. ECF5. Illinois.

ECF5.

Probably just a change to MEF to display the new information.

I believe that we are already doing TLS 1.3.

Core. May be required for authentication-related micro-services.

Bug 8224 - Add support for new authentication header

Configurable feature. This is not likely to be used in Indiana as long as Qwest is around. Will be useful in any state that has a single CMS (not sure which ones that would be).

This affects primarily the search widget.

We need to implement this in the code fetcher. See Bug 8219 - Add new columns and tables for codes to support EFM 2022.1.2.

Configurable feature. Not sure if this will be used in Indiana. STAGE is currently configured for PDF only.

filing_component_code.allowed_file_types

We need to implement this in the code fetcher. See Bug 8219 - Add new columns and tables for codes to support EFM 2022.1.2.

Core feature.

Minor changes to User Preferences. Bug 8223 - Add support for locked accounts to E-filing User Settings

Configurable. Not sure if this will be implemented in Indiana. Seems like Indiana would be keenly interested, but this is not currently configured in STAGE.

We need to implement this in the code fetcher. See Bug 8219 - Add new columns and tables for codes to support EFM 2022.1.2.

Core functionality (ECF5).

We need to implement famde_refund_reason_code as a new table in the code fetcher. See Bug 8219 - Add new columns and tables for codes to support EFM 2022.1.2.

Configurable. Not sure if this will be implemented in Indiana.

We need to implement this in the code fetcher. See Bug 8219 - Add new columns and tables for codes to support EFM 2022.1.2.

Configurable. Not sure if Indiana will be using this, but Indiana does not currently use them.

If implemented, there is an array of locations codes for which the drawdown account may be used.

Configurable. Not sure if Indiana will be using this.

If this is being used, we'll need to display it in initial and subsequent filing.

Core functionality. Not sure if Indiana will be using this.

There is a new status "Correction" in the filing status codes, but we don't see a "Return for Correction" option in the clerk review module.

Implementation of this may be straightforward if we can make this available through MEF and adding famde_envelope_id (or efm_envelope_id) as a new parameter to the intiail and subsequent filing pages.

Not required at this time.

Not required at this time.

Not required at this time.

Not required at this time.

GetPolicy has a URL for the court website.

Bug 7833 - 2022.0 GetPolicy now has a court specific URL

Bug 7879 - 2022.0 Add UI support for location-specific court URL

Similar to the envelope comments. CasetTypeCode (CaseStreetAddress). Available, Not available, Required. (See EFPS Guide).

Bug 7832 - 2022.0 Add support for case level address

Bug 7878 - 2022.0 Add UI support for Case Level Address

Bug 7831 - 2022.0 Optional services can now be required

We already do this.

A small change is needed to cache the value. More changes are needed to MEF. We need to alter the conditions under which we call GetFilingDetails so that we can display this rejection comment. We are not sure how to test this, perhaps by a PDF that submits but fails before the clerk can process.

We do not currently display the rejection comments.

We will need to modify the logic of MEF to fetch and display the comment when the status is in one of the applicable states (e.g., ERROR, FAILED, REJECTED).

We may want to add rejection_comment as a new column to famde_filing_details. This value would be placed there by GetFilingDetails under these new circumstances. We may also want to add a flag field to indicate that this row has been checked for a rejection_comment (i.e., checked while in a terminal status).

Note that NFRC and Financial report will not affect these rows (since they only care about ACCEPTED filings).

Bug 7829 - 2022.0 Submission failure now creates rejection comments

Bug 7877 - 2022.0 Add UI support for submission failure now creates rejection comments

We believe this is specific to Washington State.

This needs to be added in the back end, and the UI. In the UI, we need to drive its behavior off DFCC. This affects Initial and subsequent Filing.

Bug 7828 - 2022.0 Add envelope comment Bug 7876 - 2022.0 Add UI support for envelope comment

Now that the judge assigned to the case is available in GetFilingList, we could make it available in the application via the webapp (e.g., MEF, and FinancialReport).

Bug 7827 - 2022.0 Add judge to GetFilingList Bug 7875 - 2022.0 Add judge assigned to the case to MEF

Note that this may help our future possible interface with CourtCall.

At the very least, we need to modify the GetXxx calls to return the IsUndeliverable value in all these cases.

We may also want to modify the webapp to provide a visual indicator that an email address is undeliverable. This will affect Initial and Subsequent filing in the areas related to public and private service contacts, also in the firm admin areas related to the list of service contacts, and users.

Bug 7826 - 2022.0 Add support for IsUndeliverable flag for blacklisted email addresses

Bug 7874 - 2022 Add UI support for IsUndeliverable flag for blacklisted email addresses

This means, of course, that we can't allow the use of DbD services if the account type is not CC.

Bug 7873 - 2022.0 Modify Initial and Subsequent Filing to only allow DbD services for CC payment account code

These additional payment account types do not seem to be used in IN STAGE. We should probably update our code, including the web app, to reference payment account types by code id instead of code words.

This will certainly affect: * GetPaymentAccountTypeList * GetPaymentAccountList * CreatePaymentAccount * UpdatePaymentAccount * CreateGlobalPaymentAccount

Bug 7872 - 2022.0 Add UI support for new payment account types

Bug 7825 - 2022.0 Add support for new payment account types

There are two org chart attributes that work together somewhat:

AllowServiceOnInitial – This enables the EFileAndServe option in the Filing Type section.

AllowAddServiceContactsOnInitial – This gives the ability to add service contacts on initial filings, regardless of the Filing Type that’s selected.

Indiana has these currently configured like below:

AllowServiceOnInitial = True

AllowAddServiceContactsOnInitial = False

As it’s currently configured, as long as the EFileAndServe Filing Type is selected, the ability to add service contacts is available. However, if the EFile Filing Type is selected, service contacts cannot be added to the case or parties.

So, if AllowAddServiceContactsOnInitial is set to True, that would give the ability to add Service Contacts on initial filings for any Filing Type, not just EFileAndServe.

See comment on allowserviceoninitial.

AllowServiceOnInitial – This enables the EFileAndServe option in the Filing Type section.

This bug's for us.

2 hours http://bugzilla.doxpop.com/show_bug.cgi?id=6726

0 hours

This fixes a bug submitted by David. The code may now work correctly. Needs to be tested to verify that this is fixed.

Some work on the front end is required for this. Now that the data field is available from the EFM, we now need to make it visible in the application.

Not us.

Not us.

Not us.

Not us.

Not us.

Not us.

Not us.

Fixed for code fetcher. This does not seem to apply to Indiana at this time.

Not for us. We now allow attaching at the party level and prefer attaching at that level.

Not us.

Ours works correctly.

Ours works correctly.

"omit" is correct. "emit" was suggested as a possible correction, but this was clarified to be "omit", as stated.

Add support for AdministrativeCopy in GetServiceInformation and GetServiceInformationHistory and GetPublicList.

Add support for mail fee amount to GetFilingDetails.

Add support for OrganizationIdentificationID to GetFilingList.

Add support for case security questions. I believe that this is a data-driven version of the checkboxes that we currently provide prior to a filing.

Add support for these new field configs in Subsequent Filing and Initial Filing.

Add support for AdDamnum amount in GetCase (and famde_case_detail).

Add to list of fields in response message.

We should verify that this doesn't break our code.

New column in CaseTypeCodes.xml

New column in PartyTypeCodes.xml

New field in statutecodes.xml

New field in Locations.xml

New fields in datafieldconfigs.xml.

New configuration field in Locations.xml

New configuration field in Locations.xml

New configuration field in Locations.xml

New configuration file, Answercodes.xml

New configuration file, Questioncodes.xml

Hello, world!

Note: this documentation is incorrect. It was copied and pasted, incorrectly, from the CMS Guide. It is not possible to pass content to the EFM via URL. All content must be passed via BinaryBase64Object, either as a base64-encoded string, or using an MTOM/XOP reference.

Note: does NOT permit sending documents via URL. All document content must be included in the filing. It may be base64 encoded, or, it may be attached as a MTOM/XOP attachment using the BinaryBase64Objecty element.

Is this really global?