Andrew Steele
My feedback
87 results found
-
21 votes
An error occurred while saving the comment An error occurred while saving the comment Andrew Steele
commented
Thank you for your response Oleg. The key part of what you mentioned is "It's not intended for working with multiple contacts, though." This is precisely what I need it for. Otherwise I'd have to enter a payment and then go into literally thousands of individual accounts to settle the open invoices on them.
I still think a bulk "mark as paid" feature could be implemented and keep the accounting accurate. Perhaps be able to run a search to find the desired outstanding invoices, have a checkbox in each row, and have an option to bulk mark as paid. You would then enter the payment details once, e.g. Fully Paid and Tender Type. This would also be helpful if a large number of people renew their membership by cash or check, as you could mark them all at once as fully paid.
An error occurred while saving the comment Andrew Steele
commented
It would be useful to have this option for multiple persons' invoices. Many of our members pay their dues through a type of payroll deduction, so we get a lump sum and notification of payment for all of them once per month. Currently we have their membership level as "free" in WA because there's no good way to track this kind of payment in the system; we don't want to have to open thousands of accounts to mark them as paid each month, and exporting and re-importing would be a messy business. It would be nice to have the accounting in WA be accurate. Allowing the quick bulk marking of many invoices under different member accounts as paid would solve this issue.
Andrew Steele
supported this idea
·
-
16 votes
An error occurred while saving the comment Andrew Steele
commented
I agree that the setup of Common vs Membership Fields needs to be simplified. Fields such as address, phone, phone type, and a few that are unique to our organization such as department, need to be applicable to all contacts. They need to be read-only in the contacts' profiles...something that can only be done with Member Fields. But these fields also need to be included in event registrations...something that can only be done with Common Fields. There's no winning here.
We're already entering everyone - even our contacts - as WA members with a member level of "Non-Member Contact." It's confusing to our Admins, but is the only way that I can see to give all of our business and professional contacts the full capabilities needed (e.g. group participation, access to restricted event registration, view-only fields in their accounts, etc.). But then some info is on a separate tab from all their other info in the admin side of things. Member Fields also can't currently be sorted in with Common Fields on the signup form.
I truly wish Contacts and Members were merged, such that everyone is a contact and they can optionally have a Membership Level assigned. If they don't have a level assigned, then you know they're only a contact. All the fields for Contacts and Members would be the same, with the option to make each individually a Common Field as suggested by this Wishlist item. This would be so much simpler!
Andrew Steele
supported this idea
·
-
50 votesAndrew Steele
supported this idea
·
-
50 votesAndrew Steele
supported this idea
·
-
5 votesAndrew Steele
supported this idea
·
An error occurred while saving the comment Andrew Steele
commented
We currently register everyone for our events manually. We typically only have one ticket type. This would save a lot of clicks! Or alternatively, it would be nice to be able to set a default registration type. So even if there are multiple options, you can choose which it should select by default by which type is most commonly used.
-
89 votes
Evgeny Zaritovskiy
responded
I’m making this not just about events, but other lists too – this is a common usability problem.
Andrew Steele
supported this idea
·
-
3 votes
An error occurred while saving the comment Andrew Steele
commented
I'm assuming you want to fix the horizontal scroll issue? Wild Apricot uses iFrames to embed content on other websites. Think of it as a window on your website that you look through to see a different website - in this case, a Wild Apricot page. Because the Wild Apricot page is wider than your window, you end up with a horizontal scroll bar. You would need to use CSS within Wild Apricot to change the width of the actual content, such that it never expands past your desired width for your website. The Wild Apricot support team may be able to assist you in coming up with the custom CSS (i.e. which selector(s) to target) to reduce the width of the event display area. You will likely always have a vertical scroll bar, since the height of the content varies from event to event. You could make the iFrame very tall, but then you may have a lot of white space on events that are shorter. I hope this helps!
-
47 votesEvgeny Zaritovskiy
responded
I have merged several similar suggestion together – they all about previewing various site functions from members perspective. For example, wen pages, registration and application forms, etc.
Andrew Steele
supported this idea
·
-
3 votes
An error occurred while saving the comment Andrew Steele
commented
I concur that the Notes field needs to be listed as a System Field on the Common Fields page. This would ensure it would appear at least on the manual Add Member form for administrators to use as they're adding a member. It would also give the ability, like any other field, to be reordered within the Common Fields.
Andrew Steele
supported this idea
·
-
490 votes
Team Husky
responded
Sorry for the late update.
The first step was finished and emails can now be carbon copied to contact’s alternative emails. To do so the contact fields which store the alternative emails must be explicitly marked on the email setting page.
Unsubscribing will unsubscribe all alternative emails simultaneously because they all belong to the very same account. The person clicking “unsubscribe” is warned about this on the unsubscribe page.
For now we paused the development of this feature. but not for good. :) So I’m changing this wish status back to “collecting comments”.
Thank you everyone for a valuable feedback.
Andrew Steele
supported this idea
·
-
65 votesAndrew Steele
supported this idea
·
-
104 votesEvgeny Zaritovskiy
responded
We’re looking into this request in much broader context – we want to simplify overall management of contacts, lists, saved searches. Saved search should be perceived as smart lists and provide quick access to various contact and member groups.
An error occurred while saving the comment Andrew Steele
commented
I agree with combining the Contact and Member tabs. We track many people that are not members of ours - local company contacts, government contacts, other association contacts, etc. - and in order to group them, we had to create a Member Level called Non-Member Contact, and then create Member Groups to sort them into. This is really confusing for our admins, but is the only way I can see to get that extra functionality for these contacts. Splitting the fields and the saved searches between contacts and members only further complicates matters, as admins may unwittingly end up in the wrong place. If you navigate from the Member List to an individual account, it automatically switches you to the Contact tab in the main menu (even while on the Membership tab in the user's individual account), making it confusing to get back to the Member List. Ideally, a Contact should simply be a lowest-permission, $0, endless-until-changed "Member Level." Then the Contact and Member tabs could be merged. People in the specific Member Level of "Contact" would not count toward the total number of members for WA billing purposes.
Andrew Steele
supported this idea
·
-
103 votesAndrew Steele
supported this idea
·
An error occurred while saving the comment Andrew Steele
commented
Field validation is important to our organization to keep our data clean and organized. Common fields (e.g. phone, zip code) would be a great start, but I agree with Evgeny - giving the administrator a way to input custom validation via regular expressions or js is the way to go. Then a help page could be created that shows a list of common expressions/code snippets that Admins can enter. And if an Admin needs a validation that's not on the list, they can ask the community for assistance creating the code they need. This way the WA coders aren't baking in every possible validation to all instances of WA.
-
138 votesAndrew Steele
supported this idea
·
-
218 votesAndrew Steele
supported this idea
·
-
93 votesAndrew Steele
supported this idea
·
-
122 votesAndrew Steele
supported this idea
·
-
249 votesAndrew Steele
supported this idea
·
-
127 votesAndrew Steele
supported this idea
·
-
58 votes
Team Events
responded
WORKAROUND: it is possible to set different colors using custom javascript. See section “Color coding events using event tags” at
https://help.wildapricot.com/display/DOC/Event+tags#Eventtags-colorcodingColorcodingeventsusingeventtagsAn error occurred while saving the comment Andrew Steele
commented
This would be immensely helpful, as our organization lists many community events in addition to our own.
The tag information is already stored in the back end. Based on this info, the system could theoretically apply a CSS class to the div that sets the background color for the event in the calendar. E.g. <div valign="top" style="height:9;overflow:hidden;" class="event-custom-tag"> Then admins could at least adjust the CSS manually for each event tag to suit their needs (e.g. color, font size/style, etc.).
I'm not sure which HTML tag it would need to be applied to in the list view, but it looks like it should be <li class="boxesListItem" id="idUpcomingEvent_#######">. Again, this would just need an extra class that is the custom event tag so that the CSS can be controlled on a per-tag basis.
It would also be nice to display a key underneath the calendar, so that the members see the different color-coded "tag" categories. Ideally they would also be able to click on/off these categories to filter what shows in the calendar (instead of having multiple pages with different calendars showing different categories/tags). But I know this would be more difficult to implement.
Andrew Steele
supported this idea
·
Hi Oleg,
I think it would be more useful to have this on an invoice level, ideally being able to do a more "advanced" search of invoices, e.g. those with an open balance AND only member renewals. This way if a member also has an open invoice for an event, it's not necessarily applying it to that (and vice versa if you're entering a lot of payments for an event). Although I still think the checkboxes would help in case you needed to exclude any from the search results. The bulk payment would fully settle the selected invoices.
Thanks,
Liz