We’ve purchased Classifieds and are now evaluating/configuring it for BladeForums.
After reviewing the 1.1.0 package more closely, there are several issues we need to resolve before we could put it into production.
1. Category View / Make Offer permissions do not appear to be fully enforced
BladeForums has an important WTB permission model:
- Registered users may create WTB listings.
- Only paid subscribers may view or respond to WTB listings.
Classifieds defines category-level
View,
Create, and
Make Offer permissions, but from reviewing the current code it appears that category-level View and Make Offer permissions are not consistently checked.
In particular, Listing::canView() appears to check the global Classifieds view permission without also checking the listing category's View permission, and several listing/search/profile paths appear to rely on that method.
Similarly, the Offer path appears to check the global makeOffer permission rather than the category-specific Make Offer permission.
Could you please confirm this?
For our use case, category-level View and response/offer restrictions need to be reliably enforced throughout:
- category browsing
- direct listing URLs
- search results
- seller profiles/listing summaries
- attachments
- offers/contact actions
This is a production requirement for us.
2. "Wanted to Buy or Trade" appears to require only WTB permission
BladeForums allows Registered members to create
WTB listings, but they are not permitted to create Trade listings.
From the current permission mapping, wanted_trade appears to be authorized using createWanted alone.
That would appear to allow a member with:
- Create WTB: Yes
- Create Trade: No
to create a
Wanted to Buy or Trade listing.
Could the mixed type either require both permissions or receive its own permission?
3. General seller reviews can apparently be submitted without a completed transaction
BladeForums transaction feedback requires an actual completed transaction.
The deal-specific feedback workflow looks good: accepted offers and manually closed sales with an identified buyer can both generate buyer/seller feedback.
However, the seller profile also appears to contain a general
Rate this seller form that allows anyone with the rate permission to submit a review without an associated completed transaction.
Those reviews then appear to contribute to the seller's overall rating/review count, including the reputation shown under normal forum posts.
For BladeForums we need the ability to enforce:
No completed transaction = no transaction feedback.
Could you add an ACP option to disable general/non-transaction seller reviews while leaving transaction-linked feedback enabled?
Ideally something like:
Allow general seller reviews: Yes / No
We would set that to No.
4. Package/version metadata appears inconsistent
The package identifies itself as Classifieds
1.1.0, but a number of templates/phrases/XML entries inside the package appear to carry version IDs corresponding to 1.2.0 through 1.5.0.
Is this expected?
I mainly want to make sure this is the intended production 1.1.0 package and that upgrading from it to future releases will behave normally.
Two additional questions / suggestions
Sold price
When a seller marks a listing sold, Final Price is optional. From the code it appears that if Final Price is left blank, the listing's asking price is stored as the sale price.
Would you consider allowing the completed sale price to remain genuinely
unknown/not recorded instead?
An optional
keep sold price private control may also be useful. We are still evaluating how BladeForums will handle public sold-price history.
Contact Seller and Conversation permissions
BladeForums currently allows Registered users to receive/reply to Conversations but not initiate ordinary Conversations.
Classifieds' Contact Seller / Offer workflow appears to create the Conversation itself.
Is it intentional that this can provide a listing-specific private contact path even when the buyer lacks XenForo's normal permission to initiate a Conversation?
If so, that may actually work very well for our use case; we just want to understand the intended behavior before configuring it.
Overall, Classifieds is looking very promising for us. Bumping can be completely disabled, the sold-listing locking is useful, and the built-in Classifieds reputation display under normal forum posts addresses another requirement we had.
The first three items above are the main issues we need resolved before production use.
Thank you for going through it at this level of detail. I checked all four points in the code rather than answering from memory, and you are right on all four. On one of them you are being generous.
1. Category View and Make Offer are not enforced
Confirmed, and the honest version is worse than "not consistently checked".
Per-category permissions shipped in 1.1.0, after your earlier request. The permission system itself is real: it is built on XenForo's own content permission framework, the ACP interface works, the values are stored and cached correctly, and Create is genuinely enforced when a listing is posted. What is missing is the enforcement layer for View and Make Offer. The repository even carries a ready-made "categories this visitor may view" method, and nothing in the add-on calls it. The plumbing was built and never connected.
So today the category View permission is applied on no surface at all:
- Browse and category pages: the listing query filters on status, never on permissions.
- Direct listing URLs: only the moderation check runs. The global view permission is enforced by the controller, the category one is not enforced anywhere.
- Search: the permission constraint checks the global view permission only.
- Attachments: they inherit from the listing's canView(), which is the method missing the category check, so a photo stays reachable.
- Seller profiles, widgets and member stats: unfiltered.
And Make Offer is read as a global permission in both the offer form and the offer service, never as the category one.
Your WTB model is exactly the case this has to serve, so it is being fixed as a whole rather than surface by surface: the category check goes into canView() itself, so everything that asks that question gets the right answer, including attachments; the browse, profile and widget queries are filtered; and search gets a category constraint. That last one is cheap, because the category is already indexed as search metadata, so it costs you no reindex.
One thing I want to flag while I am in there. Contact Seller currently checks no permission at all beyond being logged in. In your model, "may not respond to WTB listings" has to cover the contact button as much as the offer button, so it is getting its own permission, settable per category.
2. Wanted to Buy or Trade
Confirmed, and the same defect exists in the other direction: For Sale or Trade is authorised by Create Sale alone, so a member allowed to sell but not to trade can post one of those.
Both mixed types will require both permissions. That is the behaviour you asked for, and it is also the only reading that makes the Trade permission mean anything.
3. General seller reviews
Confirmed. The general form on the seller profile needs only the Rate permission, with no transaction behind it, and those reviews do count towards the average rating and the review total, including the reputation shown under forum posts.
You will get the option you described,
Allow general seller reviews: Yes / No. With it set to No, the form disappears from seller profiles and the endpoint refuses the submission, while accepted offers and hand-closed sales with a named buyer keep producing feedback exactly as they do now.
4. Version metadata
Expected, and cosmetic. Also untidy, and I will clean it up.
Those records are genuine Classifieds phrases and templates. Their version stamps date from development, when the internal numbering ran ahead of the release numbering, and the export preserved them. Nothing in XenForo reads those stamps when upgrading: phrases are matched by title, templates by type and title, and the stamp is simply overwritten by whatever the incoming package carries. There is no version comparison and no record is ever skipped because of one.
So yes, this is the intended production 1.1.0 package, and upgrading from it to future releases will behave normally. I will renumber the stamps anyway, so the ACP stops telling you a 1.1.0 add-on last changed a phrase in 1.5.0.
Sold price
You read it correctly: a blank Final Price stores the asking price. That is wrong, because it manufactures data that nobody entered, and on a board with your history it would quietly corrupt the price record.
A blank field will mean the sale price was not recorded. The price history already ignores sales without a recorded price, so unknown sales will not distort your averages instead of inventing a figure for them.
A per-listing "do not publish the sale price" control is a good idea and I will add it alongside. Worth knowing in the meantime: you already have a board-level lever, since viewing sold prices is a permission of its own, and the seller and the buyer always see their own transaction regardless of it. So you can keep the entire public price history behind a paid group, or behind nobody at all, while you decide.
Contact Seller and conversations
It is deliberate, and here is exactly how far it goes, because a behaviour that suits you should not rest on a surprise.
The contact and offer flows create the conversation as a trusted recipient operation. That skips four things: your Registered group not having the permission to start conversations, the recipient's permission to receive them, the recipient's privacy setting for who may message them, and whether the recipient is banned or disabled.
The first of those is the behaviour you want, and I would keep it: a marketplace where the contact button silently fails is not a marketplace. The other three are more than you asked for. In particular, a seller who has deliberately closed their inbox still receives a contact message. That is the second reason this path is getting its own permission: the listing-specific channel becomes something you grant, rather than something that happens to bypass your configuration. The default will keep today's behaviour, so nothing changes for boards already relying on it.
Where that leaves us
Points 1, 2 and 3 are defects rather than feature requests, so they go into the next release together with the version cleanup. I would rather tell you when it is out than guess at a date now. The sold price change and the contact permission follow it.
One change of behaviour to expect from the first fix, since you are configuring rather than already live. Once category View is enforced, any category permission you have already set starts taking effect on all the surfaces listed above. On a board being set up that is exactly what you want, but I would rather you hear it from me than find it.
Nothing here needs anything from you. If you want to keep configuring in the meantime, the Create permission per category already behaves as documented, and so does the transaction-linked feedback flow, so the WTB posting side of your model can be set up and tested today.
