Add Quota & Ownership Coefficient in Contact, Document Visibility Field, and Insurance Checkbox in Tickets

[paulo-rossy]

Hello team!

I would like to request the addition of the following features/improvements. Some have been partially discussed in previous issues, but I would like to clarify and replicate them here:

1. Quota & Ownership Coefficient in Contact (Resident)

   • We currently have an ownershipShare field, but it seems to be stored in the wrong numeric format. Could we switch it to a decimal type?
   • In my country, there is a concept of quota, which represents how much a resident pays (monthly or yearly) and is usually calculated as:

     annualQuota = ownershipShare * yearlyBudget
     

     However, there are scenarios where we cannot just compute one field from the other (for example, if the resident’s payment is adjusted or if the budget changes partway through the year). Therefore, we need:
     • A separate quota field, also in decimal format, to store these amounts directly.
     • The ability to handle both fields independently.
   • Related issues: [#4870 (Add Quota Field for Residents)], [#5188 (Renaming the Quota field to OwnershipShare)].

2. Document Visibility Field

   • We need a boolean field to indicate whether a document should be visible to residents (e.g., residentCanRead or similar).
   • This is partially aligned with [#5590 (Add the ability to flag documents containing private data)], but here we specifically want to control overall visibility to residents (some documents are private, some are public).

3. Insurance Checkbox in Tickets

   • Lastly, please add an “insurance” checkbox in tickets to mark cases that involve insurance.

Could you please let me know if these changes can be implemented and how best to proceed with each? Thank you!

[toplenboren]

Hi! Thanks for the issue.

We are currently building a mechanism for custom fields. It is designed to store locale specific data

It might be sufficient for some of your cases, like insurance checkbox
#5742

What do you think?

[paulo-rossy]

Hi! Thanks for the issue.

We are currently building a mechanism for custom fields. It is designed to store locale specific data

It might be sufficient for some of your cases, like insurance checkbox #5742

What do you think?

Hello! Thank you for the suggestion. I’m definitely interested in the custom fields approach, but I wanted to clarify a few points to make sure it meets all our needs:

1. Ticket Creation and Lists

   • We need to display these fields (e.g., insurance checkbox) directly in the ticket creation form and in ticket lists so that the support team can easily set and view insurance-related flags.
   • Will the custom fields mechanism let us add and show these fields in both the UI (forms/lists) and the backend (API)?

2. Contacts

   • We also need similar fields (quota, ownershipShare) to appear in the contact creation/edit forms and in the list of contacts.
   • Can the custom fields mechanism handle displaying numeric (decimal) fields in these UIs and pass them through the API?

3. Documents

   • For the document visibility field (e.g., residentCanRead), we need an API endpoint so that residents can see which documents are available to them.
   • Will custom fields integrate with the existing permissions logic (i.e., restricting or allowing document access)?

If custom fields can be displayed and edited in all these places (tickets, contacts, documents) and are accessible via the API, that would be great! If there are any limitations to using custom fields for these particular scenarios, please let me know.

Thank you again! I’d love to hear your thoughts on whether custom fields fully address these requirements or if we need separate built-in fields in some cases.

[SavelevMatthew]

Hi, I think @toplenboren will be able to tell you for sure if custom fields can solve your queries, as he has this feature in active development right now...

I think we also agreed that marking documents documents as readable for residents is a good feature, @toplenboren will update his roadmap and get back to you.

I also want to clarify the question about insurance field. Right now in the platform there is a flag isWarranty, which is used to mark tickets that involve warranty obligations (insurance). Why is this field not suitable for you?

[toplenboren]

• We currently have an ownershipShare field, but it seems to be stored in the wrong numeric format. Could we switch it to a decimal type?

Just checked the code.. noticed we already have a decimal Contact.quota field. Can you please clarify why is it stored in a wrong format and how do you want to change it?

[paulo-rossy]

• We currently have an ownershipShare field, but it seems to be stored in the wrong numeric format. Could we switch it to a decimal type?

Just checked the code.. noticed we already have a decimal Contact.quota field. Can you please clarify why is it stored in a wrong format and how do you want to change it?

@toplenboren Sorry! Yes, the 'quota' field is of type decimal—I was mistaken. We discussed that this field should be renamed to 'ownershipShare' in this issue, and you asked me if it was possible to change its type to String. However, I still believe that it should be renamed, and I don’t need to change its type; in my project, I specifically require a decimal field with the name 'ownershipShare'.
Can you rename it?

Additionally, there is a bug with this field: it currently accepts only positive values with a dot as the decimal separator, but it should also accept values with a comma.

[SavelevMatthew]

Additionally, there is a bug with this field: it currently accepts only positive values with a dot as the decimal separator, but it should also accept values with a comma.

That's expected behaviour. There's different separators in different countries... Some of them uses comma as "thousands" separator. 1,000,000.00. That's why API is strict here. The only accepted format is /-?\d+(\.\d+)?/ (123.123, -123.123)

So all commas must be only on frontend... on backend type and format is strict

[toplenboren]

So, let me just clarify this:

What we can do now:

1. Rename Contact.quota to Contact.ownershipShare

2. Add TicketDocument.residentCanRead boolean flag
   As for the API, we can extend access so that residents (users with type = resident) would be able to query TicketDocument objects using api endpoint

--

As for the Contact.quota field:

We can also add something like Conact.monthlyPayment or Contact.yearlyPayment fields, but maybe it would be more simple to just setup billing domain and create BillingReceipt objects for each resident. Can you please describe your case in more detail?

--

As for the Ticket.insurance field:

We also have open source contributors who want to use this project as jira clone, and they require new field Ticket.type: String It can be set using API by staff users (user.type = staff) with permission to modify tickets. I think you may be able to use it to cover Insurance ticket cases.

One other possible solution is just to extend the TicketClassifier so that insurance is there

@paulo-rossy what do you think?